Open Stack

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.

Cheers,
Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150601/ff9baa8b/attachment.pgp>