Define an API to manage Artifacts

As the design for this is still on-going, let's hold off on targeting the milestone, though it still seems the plan of Juno is reasonable. I'll also put this blueprint in the needs-information queue so that we can remember to check on its status periodically.
markwash more-info 2014-02-17

I'm curious if you think this use case [1] might be able to be met sensibly with images as artifacts?
[1] https://blueprints.launchpad.net/glance/+spec/glance-image-aliases
--markwash

Yes, in some sense. Artifacts - at least in my understanding - should be identified not only by their name, but by the combination of name and version. So, the API call to retrieve a particular artifact by its name will always return the latest version of this artifact (to support this, the version should follow some order-defining semantics, SemVer should be fine), unless an optional parameter is specified to include a particular version or all of them.
So, if images will become artifacts, this approach will solve this use case: there will be an API which always return the latest image having the given name. However, this will not be a true alias, as the artifacts with the same name but different versions will definitely will have different IDs.
--ativelkov

Yeah, I think this will handle what I was trying to do. I was trying to build this functionality externally but it would be even better to just have glance support it. I'm thinking both glance and nova would need to support it. An image could be uploaded with a name and version (or timestamp). The default image fetch behaviour by nova would still work allowing the request of just the image by name and would get the default newest (or maybe a flag on the image name saying what the default was in glance) but also, glance would have to return the version back to nova as well so that nova would be query-able as to which version a vm it was actually running. This would allow cleaning out old, non used versions at some point. It would also allow scripts to determine which vm's needed rebuilding to get to a newer version.
--kfox1111

I would like you to consider the following use cases while you are desiging this feature:
1. an OVF descriptor and its disks
2. different versions of an image
3. different formats of an image
I think these three cases should be covered natively by the artifact api, but I want to make sure this is
actually the case.
We can discuss more about the specific requirements on irc if you like:
For 1., the artifact should translate a one to many relationship between the OVF and its disks
For 2., it should translate a chain of 1to1 relationships between different versions of a file
For 3, it should translate a group of files without any relationship
--arnaud