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