Hi Sean and everyone else, As promised trying to get a sync on direction on this asap :) Please find comments inline.
On 4/1/16 9:45 AM, Sean Dague wrote: > The glance v2 work is currently blocked as there is no active spec, > would be great if someone from the glance team could get that rolling again. (for everyone's awareness) Newton spec for Glance v2 support https://review.openstack.org/#/c/301741/ > I started digging back through the patches in detail to figure out if > there are some infrastructure bits we could get in early regardless. > > #1 - new methods for glance xenserver plugin > > Let's take a simplified approach on this patch - > https://review.openstack.org/#/c/266933 and only change the > xenapi/etc/xapi.d/plugins/ content in the following ways. > > - add upload/download_vhd_glance2 methods. Don't add an api parameter. > Add these methods mostly via copy/paste as we're optimizing for deleting > v1 not for fixing v1. > > That will put some infrastructure in place so we can just call the v2 > actions based on decision from higher up the stack. I think, Mike and I can collaborate on getting this closer to expected. > #2 - move discover major version back to glanceclient - > https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L108 > > I don't understand why this was ever in nova. This really should be > > glanceclient.discover... something. It uses internal methods from > glanceclient and internal structures of the content returned. > > Catching, if desired, should also be on the glanceclient side. > glanceclient.reset_version() could exist to clear any caching. I will have to sync with Monty to see what and where he plans to propose a patch (#action nikhil: sync with mordred on #2). But in general, I agree with your proposal. I did notice in the spec there were a few other comments regarding working with v1, v2 quirks. May be we can do these together if they come up as necessary. > #3 - Ideally we'd also have a > > client = glanceclient.AutoClient(endpoint, ... ) which basically does > glanceclient.discover and returns us the right client automatically. > client.version provides access to the version information if you need to > figure out what version of a client you have. > > > This starts to get to a point where the parts of versioning that > glanceclient should know about are in glanceclient, and when nova still > needs to know things it can as for client.version. > > For instance make _extract_query_params - > https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L448 > become and instance method that can > > if self._client.version >= 2: > ... > else: > ... > I see, I'm not totally against this even if we want to keep it as a part of this spec. Although, it seems like we want to improve the code readability and do some refactor -- something I DO was hoping we would do as a next step to this v2 adoption work. Would be okay to have another smaller spec for such client support instead? Also, would love to know what mordred is thinking about this. > This isn't the whole story to get us home, however chunking up some of > these pieces I think makes getting the rest of the story in much > simpler. In nearly every case (except for the alt link in the image > view) we can easily have access to a real glance client. And the code > will be a ton easier to understand with some of the glanceclient > specific details behind the glanceclient interface. > > -Sean > > > In a gist: To fully understand the pain points, are we blocked on some ugly pieces of code or code that is making stuff uglier or may be both :-) I was hoping to get a relief checkpoint for completing a v2 adoption and then working in smaller specs to improve the code pieces therein. mordred: unfortunately, had to reference your comments from follow up emails in these inline ones. sorry 0:-) -- Thanks, Nikhil __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
