Open Stack

> On Sep 25, 2015, at 6:59 AM, Doug Hellmann <doug at doughellmann.com> wrote:
> 
> Excerpts from Mark Voelker's message of 2015-09-25 01:20:04 +0000:
>>> 
>>> On Sep 24, 2015, at 5:55 PM, Sabari Murugesan <sabari.bits at gmail.com> wrote:
>>> 
>>> Hi Melanie
>>> 
>>> In general, images created by glance v1 API should be accessible using v2 and
>>> vice-versa. We fixed some bugs [1] [2] [3] where metadata associated with an image was
>>> causing incompatibility. These fixes were back-ported to stable/kilo.
>>> 
>>> Thanks
>>> Sabari
>>> 
>>> [1] - https://bugs.launchpad.net/glance/+bug/1447215
>>> [2] - https://bugs.launchpad.net/bugs/1419823 
>>> [3] - https://bugs.launchpad.net/python-glanceclient/+bug/1447193 
>>> 
>>> 
>>> On Thu, Sep 24, 2015 at 2:17 PM, melanie witt <melwittt at gmail.com> wrote:
>>> Hi All,
>>> 
>>> I have been looking and haven't yet located documentation about how to upgrade from glance v1 to glance v2.
>>> 
>>> From what I understand, images and snapshots created with v1 can't be listed/accessed through the v2 api. Are there instructions about how to migrate images and snapshots from v1 to v2? Are there other incompatibilities between v1 and v2?
>>> 
>>> I'm asking because I have read that glance v1 isn't defcore compliant and so we need all projects to move to v2, but the incompatibility from v1 to v2 is preventing that in nova. Is there anything else preventing v2 adoption? Could we move to glance v2 if there's a migration path from v1 to v2 that operators can run through before upgrading to a version that uses v2 as the default?
>> 
>> Just to clarify the DefCore situation a bit here: 
>> 
>> The DefCore Committee is considering adding some Glance v2
> capabilities [1] as “advisory” (e.g. not required now but might be
> in the future unless folks provide feedback as to why it shouldn’t
> be) in it’s next Guideline, which is due to go the Board of Directors
> in January and will cover Juno, Kilo, and Liberty [2].	The Nova image
> API’s are already required [3][4].  As discussion began about which
> Glance capabilities to include and whether or not to keep the Nova
> image API’s as required, it was pointed out that the many ways images
> can currently be created in OpenStack is problematic from an
> interoperability point of view in that some clouds use one and some use
> others.  To be included in a DefCore Guideline, capabilities are scored
> against twelve Criteria [5], and need to achieve a certain total to be
> included.  Having a bunch of different ways to deal with images
> actually hurts the chances of any one of them meeting the bar because
> it makes it less likely that they’ll achieve several criteria.  For
> example:
>> 
>> One of the criteria is “widely deployed” [6].  In the case of images, both the Nova image-create API and Glance v2 are both pretty widely deployed [7]; Glance v1 isn’t, and at least one uses none of those but instead uses the import task API.
>> 
>> Another criteria is “atomic” [8] which basically means the capability is unique and can’t be built out of other required capabilities.  Since the Nova image-create API is already required and effectively does the same thing as glance v1 and v2’s image create API’s, the latter lose points.
> 
> This seems backwards. The Nova API doesn't "do the same thing" as
> the Glance API, it is a *proxy* for the Glance API. We should not
> be requiring proxy APIs for interop. DefCore should only be using
> tests that talk directly to the service that owns the feature being
> tested.

I agree in general, at the time the standard was approved the
only api we had available to us (because only nova code was
being considered for inclusion) was the proxy.

We’re looking at v2 as the required api going forward, but
as has been mentioned before, the nova proxy requires that
v1 be present as a non-public api. Not the best situation in
the world, and I’m personally looking forward to Glance,
Cinder, and Neutron becoming explicitly required APIs in
DefCore.


> Doug
> 
>> 
>> Another criteria is “future direction” [9].  Glance v1 gets no points here since v2 is the current API, has been for a while, and there’s even been some work on v3 already.
>> 
>> There are also criteria for  “used by clients” [11].  Unfortunately both Glance v1 and v2 fall down pretty hard here as it turns out that of all the client libraries users reported in the last user survey, it appears the only one other than the OpenStack clients supports Glance v2 and one supports Glance v1 while the rest all rely on the Nova API's.  Even within OpenStack we don’t necessarily have good adoption since Nova still uses the v1 API to talk to Glance and OpenStackClient didn’t support image creation with v2 until this week’s 1.7.0 release. [13]
>> 
>> So, it’s a bit problematic that v1 is still being used even within the project (though it did get slightly better this week).  It’s highly unlikely at this point that it makes any sense for DefCore to require OpenStack Powered products to expose v1 to end users.  Even if DefCore does end up requiring Glance v2 to be exposed to end users, that doesn’t necessarily mean Nova couldn’t continue to use v1: OpenStack Powered products wouldn’t be required to expose v1 to end users, but if the nova image-create API remains required then they’d have to expose it at least internally to the cloud.  But….really?  That’s still sort of an ugly position to be in, because at the end of the day that’s still a lot more moving parts than are really necessary and that’s not particularly good for operators, end users, developers who want interoperable ways of doing things, or pretty much anybody else.  
>> 
>> So basically: yes, it would be *lovely* if we could all get behind fewer ways of dealing with images. [10]  
>> 
>> [1] https://review.openstack.org/#/c/213353/
>> [2] http://git.openstack.org/cgit/openstack/defcore/tree/2016.next.json#n8
>> [3] http://git.openstack.org/cgit/openstack/defcore/tree/2015.07.json#n23
>> [4] http://git.openstack.org/cgit/openstack/defcore/tree/2015.05.json#n20
>> [5] http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/CoreCriteria.rst
>> [6] http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/CoreCriteria.rst#n40
>> [7] http://lists.openstack.org/pipermail/openstack-dev/2015-September/074540.html
>> [8] http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/CoreCriteria.rst#n87
>> [9] http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/CoreCriteria.rst#n60
>> [10] Meh, entirely too many footnotes here so why not put one out of order for fun: https://www.youtube.com/watch?v=oHg5SJYRHA0
>> [11] http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/CoreCriteria.rst#n48
>> [12] See comments in https://review.openstack.org/#/c/213353/7/working_materials/scoring.txt
>> [13] http://docs.openstack.org/developer/python-openstackclient/releases.html#sep-2015
>> 
>> At Your Service,
>> 
>> Mark T. Voelker
>> 
>>> 
>>> Thanks,
>>> -melanie (irc: melwitt)
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> 
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev