Open Stack

> > 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/039f3f35/attachment.html>