Open Stack

On Wed, Jun 10, 2015 at 10:40:02AM -0500, 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.

Yes, I think experiance with the VIF drivers in Neutron/Nova has shown
that we should try to have an N:1 mapping between the vendor drivers
and the Nova side plugin. This avoids the need to lock-step upgrade
the Nova code every time a new plugin appears on the cinder side,
and avoids re-inventing the same code over & over for each vendor.

> 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?

Agree, that it does seem like we could be sharing the object definitions
between Nova & Cinder, instead of re-creating them in both projects.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|