Open Stack

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'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