F expose openstack image

[jcejohnson]

Adds image_info_file and image_info_content configuration options to the Openstack builder so that post-processors have access to the image id (e.g. -- via the artifice post-processor).

Relates to #2678

[jcejohnson]

Is there anything I need to do on this?

[rickard-von-essen]

I'm not sure this is a good way forward.

I think fixing the shell-local post-processor to run once per artifact expose Artifact.Id to it is a better way forward.

[jcejohnson]

I took this route so that any post-processor would have access to the image id.
Would Artifact.Id be the actual Openstack image ID or a packer ID?

[rickard-von-essen]

OpenStack image ID

[jcejohnson]

Perfect! Point me in the right direction and I'll see what I can do.

[rickard-von-essen]

Point me in the right direction and I'll see what I can do.

See #3671

[jcejohnson]

I've updated the PR based on your suggestion.
This change doesn't attempt to address the full scope of #3671. Instead, it simply uses artifact.Id() as the template .Artifact value when artifact.Files() returns nil. This maintains backward compatibility when a builder produces files while behaving reasonably when it doesn't and removes the need for fake artifacts.
I have also backed out my original changes to builder/openstack/*

[gkuchta]

Any movement on this? It'd be very, very useful, as packer currently uses the nova API for creating images, which doesn't allow you to control whether an image is public/private. This is problematic when used with something like Spinnaker.

[rickard-von-essen]

@gkuchta It would be better if someone PR'ed #2678

[gkuchta]

@rickard-von-essen agreed. our team is looking at either PR'ing the base builder to use the image api or writing an openstack post-processor longer term.

[rickard-von-essen]

@gkuchta Sounds great, the problem have being getting in Glance support into gophercloud, see rackspace/gophercloud#213 (comment) and we probably need to migrate to gophercloud org before getting Glance support.

[mwhooker]

We're planning to rewrite the shell-local post-processor, so this change is unnecessary.

Will also be happy to take a look at a PR of #2678 since it looks like the upstream changes have been merged.

[mwhooker]

see also #4113 for possible glance support