On Wed, Oct 30, 2013 at 9:04 AM, Eddie Sheffield < eddie.sheffi...@rackspace.com> wrote:
> > > "Mark Washenberger" <mark.washenber...@markwash.net> said: > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
