On Sep 25, 2015, at 12:00 PM, Chris Hoge <ch...@openstack.org> wrote: > >> >> On Sep 25, 2015, at 6:59 AM, Doug Hellmann <d...@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.b...@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 <melwi...@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. >
Also worth pointing out here: when we talk about “doing the same thing” from a DefCore perspective, we’re essentially talking about what’s exposed to the end user, not how that’s implemented in OpenStack’s source code. So from an end user’s perspective: If I call nova image-create, I get an image in my cloud. If I call the Glance v2 API to create an image, I also get an image in my cloud. I neither see nor care that Nova is actually talking to Glance in the background, because if I’m writing code that uses the OpenStack API’s, I need to pick which one of those two API’s to make my code call upon to put an image in my cloud. Or, in the worst case, I have to write a bunch of if/else loops into my code because some clouds I want to use only allow one way and some allow only the other. So from that end-user perspective, the Nova image-create API indeed does “do the same thing" as the Glance API. 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=95BssXyE_6OT7evZ9w9sdss0Ab4W_rrmwSdBc4Y8QVk&s=AGxMjguGSO6Doyo-BHeGpHAad085e62KrJYqOXX0rZ0&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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
