On 1 June 2015 at 13:10, Flavio Percoco <fla...@redhat.com> wrote: > On 01/06/15 11:57 +0100, John Garbutt wrote: >>> >>> On 26/05/15 13:54 -0400, Nikhil Komawar wrote: >>>> >>>> On 5/26/15 12:57 PM, Jesse Cook wrote: >>>> We also had some hallway talk about putting the v1 and v2 APIs on top >>>> of >>>> the v3 API. This forces faster adoption, verifies supportability via >>>> v1 >>>> and >>>> v2 tests, increases supportability of v1 and v2 APIs, and pushes out >>>> the >>>> need to kill v1 API. >>>> >>>> Let's discuss more as time and development progresses on that >>>> possibility. >>>> v3 >>>> API should stay EXPERIMENTAL for now as that would help us understand >>>> use-cases >>>> across programs as it gets adopted by various code-bases. Putting v1/v2 >>>> on >>>> top >>>> of v3 would be tricky for now as we may have breaking changes with code >>>> being >>>> relatively-less stable due to narrow review domain. >>> >>> >>> >>> I actually think we'd benefit more from having V2 on top of V3 than >>> not doing it. I'd probably advocate to make this M material rather >>> than L but I think it'd be good. >>> >>> I think regardless of what we do, I'd like to kill v1 as it has a >>> sharing model that is not secure. >> >> >> Given v1 has lots of users, killing it will be hard. >> >> If you maintained v1 support as v1 on top of v3 (or v2 I guess), could >> you not do something like permanently disable the "bad bits" of the >> API? > > I agree it'll be hard but, at least for v1, I believe it should > happen. It has some security issues (mostly related to image sharing) > that are not going to be fixed there.
OK, I guess you mean this one: https://wiki.openstack.org/wiki/OSSN/1226078 >> The idea being, users listing their images, and updating image >> metadata via v1, don't get broken during the evolution? > > The feedback we got at the summit (even from OPs) was that we could go > ahead, mark it as deprecated, give a deprecation period and then turn > it off. I am surprised by that reply, but OK. >> FWIW, moving Nova from glance v1 to glance v2, without breaking Nova's >> public API, will require someone getting a big chunk of glance v1 on >> top of glance v2. > > AFAIK, the biggest issue right now is "changed-since" which is > something Glance doesn't have in v2 but it's exposed throught Nova's > image API. Thats the big unanswered question that needs fixing in any spec we would approve around this effort. > I'm happy you brought this up. What are Nova's plans to adopt Glance's > v2 ? I heard there was a discussion and something along the lines of > creating a library that wraps both APIs came up. We don't have anyone who has stepped up to work on it at his point. I think the push you made around this effort in kilo is the latest updated on this: http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/remove-glanceclient-wrapper.html It would be great if we could find a glance/nova CPL to drive this effort. > Where can I find more info about this? I suspect it will be included on our liberty priority TODO list, that I am yet to write, but I expect to appear here: http://specs.openstack.org/openstack/nova-specs/ > I really think nova should put some more effort on helping this > happen. The work I did[0] - all red now, I swear it wasn't - during > Kilo didn't get enough attention even before we decided to push it > back. Not a complain, really. However, I'd love to see some > cross-project efforts on making this happen. > [0] https://review.openstack.org/#/c/144875/ As there is no one to work on the effort, we haven't made it a priority for liberty. If someone is able to step up to help complete the work, I can do my best to help get that effort reviewed, by raising its priority, just as we did in Kilo. I suspect looking at how to slowly move towards v2, rather than going for a "big bang" approach, will make this easier to land. That and solving how we implement "changed-since", if thats not available in the newer glance APIs. Honestly, part of me wonders about skipping v2, and going straight to v3. Thanks, John __________________________________________________________________________ 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
