On Mon, Jun 1, 2015 at 6:11 AM, Flavio Percoco <fla...@redhat.com> wrote:
> On 01/06/15 13:30 +0100, John Garbutt wrote: > >> 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 don't have an answer myself right now. > > >> 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. >> > > So, unless the library is proposed and some magic happens, is it safe > to assume that the above spec is still valid and that folks can work > on it? > > >> 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. >> > > IIRC, the patch wasn't far from being ready. The latest patch-sets > relied on the gate to run some tests and the biggest issue I had - > still have - is that this script[0] didn't even use glanceclient but > direct http calls. The issue, to be precises, is that I didn't have > ways to test it locally, which made the work painful. > > If there's a way to do it - something that has already being asked - > it'd be great. > > This said, I'm not sure how much time I'll have for this but I'm > trying to find someone that could help out. > > > https://review.openstack.org/#/c/144875/30/plugins/xenserver/xenapi/etc/xapi.d/plugins/glance,cm > > >> 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. >> > > Regardless, I think we should enable people to run on a v2 only > deployment. Not a crazy thought, I think. We'll have to think this > through a bit more. > > This sounds like a more pressing issue, talking about working on yet another major API change (V3) before V1 is deprecated sounds premature to me. Otherwise we end up in a situation where operators need to run all 3 glance APIs. Glance V2 appears to have been finalized in Grizzly, and over 2 years later, it isn't really used. So I am skeptical at the notion of working on yet another major API overhaul before the V1 can finally be deprecated. > Cheers, > > Flavio > > -- > @flaper87 > Flavio Percoco > > __________________________________________________________________________ > 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
