[openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova

Mark Washenberger mark.washenberger at markwash.net
Wed Oct 30 22:50:54 UTC 2013


On Wed, Oct 30, 2013 at 9:04 AM, Eddie Sheffield <
eddie.sheffield at rackspace.com> wrote:

>
>
> "Mark Washenberger" <mark.washenberger at markwash.net> said:
>
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> > I am not a fan of all the specific talk to glance code we have in
> >> > nova, moving more of that into glanceclient can only be a good thing.
> >> > For the XenServer itegration, for efficiency reasons, we need glance
> >> > to talk from dom0, so it has dom0 making the final HTTP call. So we
> >> > would need a way of extracting that info from the glance client. But
> >> > that seems better than having that code in nova.
> >>
> >> I know in Glance we've largely taken the view that the client should be
> as
> >> thin and lightweight as possible so users of the client can make use of
> it
> >> however they best see fit. There was an earlier patch that would have
> moved
> >> the whole image service layer into glanceclient that was rejected. So I
> >> think there is a division in philosophies here as well.
> >
> >
> >
> > Indeed, I think I was being a bit of a stinker on this issue. Mea culpa.
> >
> > I've had some time to think and I realized that there is a bit of
> > complexity here that needs to be untangled. Historically, the glance
> client
> > (and I think *most* openstack clients) have had versioned directories
> that
> > attempt to be as faithful a representation of the given version of an API
> > as possible. That was a history I was trying to maintain for continuity's
> > sake in the past.
> >
> > However, with some more thought, this historical objective seems
> literally
> > insane to me. In fact, it makes it basically impossible to publish a
> useful
> > client library because such a library has no control to smooth over
> > backwards incompatibility from one major version to the next.
> >
> > At this point I'm a lot more interested in Ghe's patch (
> > https://review.openstack.org/#/c/33327/)
> >
> > I'm a bit concerned that we might need to make the image client interface
> > even more stripped down in order to focus support on the intersection of
> v1
> > and v2 of the image api. In particular, I'm not sure how well the old
> nova
> > image service api will deal with invalid property values (v2 has property
> > schemas). And there's no support AFAICT for image sharing, and image
> > sharing should not be used in v1 for security reasons.
> >
> > On the other hand, maybe we don't really want to move forward based on
> how
> > nova viewed the image repository in the past. There might be a better
> image
> > client api waiting to be discovered by some intrepid openstacker. This
> > could make sense as well if there is some traction for eventually
> > deprecating the v1 api. But in any case, it does sound like we need an
> > image client with its own proper api that can be ported from version to
> > version.
> >
> > </ramble>
>
> Hmmm, pretty big turnaround but one I mostly agree with. I would like to
> see more discussion on what this unified interface would look like rather
> than just pulling in what's in Nova (tho we might converge on that anyway.)
> I do worry about what to do about unique functionality in the various API
> versions. It might be that the most common functionality is exposed in the
> service interface, and if you need some of the more API specific
> functionality you can use the lower-level client interfaces. Alternatively
> the interface might contain everything possible; and where it can, smooth
> over the differences and where it can't, raise NotImplemented exceptions.
>
> Mark, can we get some discussion of this in our Glance meeting tomorrow
> (10/31)?
>

Definitely, adding it to the agenda now.



>
> Eddie
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20131030/521ed285/attachment.html>


More information about the OpenStack-dev mailing list