Open Stack

On Mon, Jun 1, 2015 at 6:11 AM, Flavio Percoco <flavio at redhat.com> wrote:

> On 01/06/15 13:30 +0100, John Garbutt wrote:
>
>> On 1 June 2015 at 13:10, Flavio Percoco <flavio at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150604/72eaca7d/attachment.html>