[openstack-dev] [nova] [glance] Getting the ball rolling on glance v2 in nova in newton cycle

Sean Dague sean at dague.net
Tue Apr 12 19:52:48 UTC 2016


On 04/12/2016 03:37 PM, Matt Riedemann wrote:
> 
> 
> On 4/1/2016 8: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.
>>
>> 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.
> 
> How are we planning on deleting the v1 image API? That would also mean
> deleting Nova's images API which is a proxy for glance v1. I didn't
> think we deleted Nova APIs? We can certainly deprecate it once we have
> glance v2 support.

This is pretty specific here in reference to xenserver plugin as listed
in that patch. After some point we'll just delete all the things that
talk glance v1 in it, and you have to have glance v2 to work. That will
drop a bunch of untested code.

That being said, in general I think this still holds. The Glance team
wants to delete their v1 API entirely. We should be thinking about how
the Nova code ends up such that it's easy to delete all the v1
interfacing code in our tree the cycle when Glance does that to get rid
of the debt. So abstraction models are way less interesting than a very
high level v1 / v2 branch, and all the code being distinct and clean for
each path.

	-Sean

>> That will put some infrastructure in place so we can just call the v2
>> actions based on decision from higher up the stack.
>>
>> #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.
>>
>> #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:
>>     ...
>>
>>
>> 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
>>
> 


-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list