Open Stack

On 04/06/15 12:19 +0900, Joe Gordon wrote:
>
>
>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.

I'll just say that V2 not being widely used is mostly Glance team's
fault. The details are long and not useful for this convo but I
believe the team has learned from this experience.

That said, I don't think we can just put v3 on hold but it won't be
supported until this v1/v2 thing is cleared out (this means it'll be
turned off by default).

It'll take a couple of cycles to get this all done.

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/20150604/0630d4f9/attachment.pgp>