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 :| __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
