Open Stack

On 09/25/15 at 03:09pm, Mark Voelker wrote:
>On Sep 25, 2015, at 10:42 AM, Andrew Laski <andrew at lascii.com> wrote:
>>
>> On 09/25/15 at 09:59am, Doug Hellmann 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 completely agree with this.  I will admit to having some confusion as to why Glance capabilities have been tested through Nova and I know others have raised this same thought within the process.
>
>Because it turns out that’s how most of the world is dealing with images.
>
>Generally speaking, the nova image API and glance v2 API’s have roughly equal adoption among public and private cloud products, but among the client SDK’s people are using to interact with OpenStack the nova image API’s have much better adoption (see notes in previous message for details).  So we gave the world lots of different ways to do the same thing and the world has strongly adopted two of them (with reasonable evidence that the Nova image API is actually the most-adopted of the lot).  If you’re looking for the most interoperable way to create an image across lots of different OpenStack clouds today, it’s actually through Nova.

I understand that reasoning, but still am unsure on a few things.

The direction seems to be moving towards having a requirement that the 
same functionality is offered in two places, Nova API and Glance V2 API.  
That seems like it would fragment adoption rather than unify it.

Also after digging in on image-create I feel that there may be a mixup.  
The image-create in Glance and image-create in Nova are two different 
things.  In Glance you create an image and send the disk image data in 
the request, in Nova an image-create takes a snapshot of the instance 
provided in the request.  But it seems like DefCore is treating them as 
equivalent unless I'm misunderstanding.

>
>At Your Service,
>
>Mark T. Voelker
>
>>
>>>
>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3DoHg5SJYRHA0&d=BQIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc&m=7GN2Z6neK-F2gi0ByCirYmqR6sCFjhWPEfaNmlQtUp4&s=y1hzWonwPHabYRZrdKG5X8PNnkHpQ2SNeOuLc489B1s&e= [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
>>
>> __________________________________________________________________________
>> 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