Open Stack

"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)?

Eddie