Open Stack

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

-- 

Thanks,

Matt Riedemann