Re: [openstack-dev] [cinder][nova] Is volume connection_info modeled/documented anywhere?
I don't think you need an entry per driver, you need an entry per connection type - iSCSI, FC, DRDB, CEPH being the ones I can think of off the top of my head On 10 Jun 2015 16:57, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: While investigating/discussing bug 1463525 [1] I remembered how little I know about what can actually come out of the connection_info dict returned from the os-initialize_connection cinder API call. So we added some debug logging in nova and I remembered that there are potentially credentials (auth_password) stored in connection_info, so we have a bug to clean that up in Nova [2]. The plan is to model connection_info using objects where we have a parent object BdmConnectionInfo containing the common keys, like 'driver_volume_type' and 'data', and then child objects for the vendor-specific connection_info objects, like RbdBdmConnectionInfo, ISCSIBdmConnectionInfo, etc. The problem I have right now is knowing what can all be in there, since there are a ton of vendor drivers in Cinder. Is anyone aware of a wiki page or devref or anything that documents what can be in that wild west connection_info dict? If not, the first thing I was going to do was start documenting that - but where? It seems it should really be modeled in Cinder since it is part of the API contract and if a vendor driver were to say rename or drop a key from the connection_info they were returning in os-initialize_connection it would be a backwards incompatible change. Is devref best for this with a listing for each vendor driver? At least then it would be versioned with the code and updates could be made as new keys are added to connection_info or new drivers are added to Cinder. I'm looking for any advice here in how to get started since I don't primarily work on Cinder and don't have a full history here. [1] https://bugs.launchpad.net/cinder/+bug/1463525 [2] https://bugs.launchpad.net/nova/+bug/1321785 -- 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 __ 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] Is volume connection_info modeled/documented anywhere?
While investigating/discussing bug 1463525 [1] I remembered how little I know about what can actually come out of the connection_info dict returned from the os-initialize_connection cinder API call. So we added some debug logging in nova and I remembered that there are potentially credentials (auth_password) stored in connection_info, so we have a bug to clean that up in Nova [2]. The plan is to model connection_info using objects where we have a parent object BdmConnectionInfo containing the common keys, like 'driver_volume_type' and 'data', and then child objects for the vendor-specific connection_info objects, like RbdBdmConnectionInfo, ISCSIBdmConnectionInfo, etc. The problem I have right now is knowing what can all be in there, since there are a ton of vendor drivers in Cinder. Is anyone aware of a wiki page or devref or anything that documents what can be in that wild west connection_info dict? If not, the first thing I was going to do was start documenting that - but where? It seems it should really be modeled in Cinder since it is part of the API contract and if a vendor driver were to say rename or drop a key from the connection_info they were returning in os-initialize_connection it would be a backwards incompatible change. Is devref best for this with a listing for each vendor driver? At least then it would be versioned with the code and updates could be made as new keys are added to connection_info or new drivers are added to Cinder. I'm looking for any advice here in how to get started since I don't primarily work on Cinder and don't have a full history here. [1] https://bugs.launchpad.net/cinder/+bug/1463525 [2] https://bugs.launchpad.net/nova/+bug/1321785 -- 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] Is volume connection_info modeled/documented anywhere?
On Wed, Jun 10, 2015 at 7:54 AM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: While investigating/discussing bug 1463525 [1] I remembered how little I know about what can actually come out of the connection_info dict returned from the os-initialize_connection cinder API call. So we added some debug logging in nova and I remembered that there are potentially credentials (auth_password) stored in connection_info, so we have a bug to clean that up in Nova [2]. The plan is to model connection_info using objects where we have a parent object BdmConnectionInfo containing the common keys, like 'driver_volume_type' and 'data', and then child objects for the vendor-specific connection_info objects, like RbdBdmConnectionInfo, ISCSIBdmConnectionInfo, etc. The problem I have right now is knowing what can all be in there, since there are a ton of vendor drivers in Cinder. Is anyone aware of a wiki page or devref or anything that documents what can be in that wild west connection_info dict? If not, the first thing I was going to do was start documenting that - but where? It seems it should really be modeled in Cinder since it is part of the API contract and if a vendor driver were to say rename or drop a key from the connection_info they were returning in os-initialize_connection it would be a backwards incompatible change. Is devref best for this with a listing for each vendor driver? At least then it would be versioned with the code and updates could be made as new keys are added to connection_info or new drivers are added to Cinder. I'm looking for any advice here in how to get started since I don't primarily work on Cinder and don't have a full history here. [1] https://bugs.launchpad.net/cinder/+bug/1463525 [2] https://bugs.launchpad.net/nova/+bug/1321785 -- 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 Hi Matt, This used to be much simpler than it is now, so I think documenting it in the cinder dev docs is a great idea. The basics of initialize_connection are documented via a comment (a not so great one) in the code here [1] which will point you to here [2]. The challenge is as you've noticed things like RBD and now FC and all of the other crazy transport layers that are getting thrown in. I don't have good info on the non-iscsi items, but sounds like you found the RBD stuff the hard way, maybe the FC stuff is in the code somewhere as well. I think each of the unique items have their own libvirt connection class, so that kinda helps organize it a bit. Also there the provider_* fields in the model update that come in (best place to see those is in the DB model). Anyway, I think this is would be great for us to have; I'm happy to help as much or as little as you like, just hit me up on IRC if you want. Thanks, John [1]: https://github.com/openstack/cinder/blob/master/cinder/volume/targets/iscsi.py#L278 [2]: https://github.com/openstack/cinder/blob/master/cinder/volume/targets/iscsi.py#L53 __ 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
