[openstack-dev] [cinder][nova] modeling connection_info with a versioned object in os-brick
Walter A. Boring IV
walter.boring at hp.com
Wed Jun 10 18:37:41 UTC 2015
On 06/10/2015 08:40 AM, Matt Riedemann wrote:
> This is a follow-on to the thread [1] asking about modeling the
> connection_info dict returned from the os-initialize_connection API.
>
> The more I think about modeling that in Nova, the more I think it
> should really be modeled in Cinder with an oslo.versionedobject since
> it is an API contract with the caller (Nova in this case) and any
> changes to the connection_info should require a version change
> (new/renamed/dropped fields).
>
> That got me thinking that if both Cinder and Nova are going to use
> this model, it needs to live in a library, so that would be os-brick
> now, right?
>
> In terms of modeling, I don't think we want an object for each vendor
> specific backend since (1) there are a ton of them so it'd be like
> herding cats and (2) most are probably sharing common attributes. So
> I was thinking something more along the lines of classes or types of
> backends, like local vs shared storage, fibre channel, etc.
>
> I'm definitely not a storage guy so I don't know the best way to
> delineate all of these, but here is a rough idea so far. [2] This is
> roughly based on how I see things modeled in the
> nova.virt.libvirt.volume module today, but there isn't a hierarchy there.
>
> os-brick could contain the translation shim for converting the
> serialized connection_info dict into a hydrated ConnectionInfo object
> based on the type (have some kind of factory pattern in os-brick that
> does the translation based on driver_volume_type maybe given some
> mapping).
>
> Then when Nova gets the connection_info back from Cinder
> os-initialize_connection, it can send that into os-brick's translator
> utility and get back the ConnectionInfo object and access the
> attributes from that.
>
> Thoughts?
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-June/066450.html
> [2]
> https://docs.google.com/drawings/d/1geSKQXz4SqfXllq1Pk5o2YVCycZVf_i6ThY88r9YF4A/edit?usp=sharing
>
The same can be said about the connector dict that Nova is sending to
Cinder that's needed by drivers at initialize_connection time. This is
also a 'contract' that Cinder drivers need to do the export of the volumes.
I'm currently working on the initial patch for Nova to import os-brick
and use the os-brick initiator connector objects for doing the
attach/detach calls.
So, until that patch lands, Nova doesn't have access to os-brick. Cinder
is already using os-brick, so we could add a BP and a patch against
os-brick to pull in the oslo versioned objects and create the connection
info (target information) object as well as the connector (initiator
information) object.
Walt
More information about the OpenStack-dev
mailing list