Re: [openstack-dev] [cinder][nova] modeling connection_info with a versioned object in os-brick
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
[openstack-dev] [cinder][nova] modeling connection_info with a versioned object in os-brick
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 __ 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
Re: [openstack-dev] [cinder][nova] modeling connection_info with a versioned object in os-brick
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 __ 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
