[openstack-dev] [cinder][nova] modeling connection_info with a versioned object in os-brick
mriedem at linux.vnet.ibm.com
Wed Jun 10 15:40:02 UTC 2015
This is a follow-on to the thread  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
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.  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
More information about the OpenStack-dev