[openstack-dev] [cinder][nova] Is volume connection_info modeled/documented anywhere?
john.griffith8 at gmail.com
Wed Jun 10 14:35:57 UTC 2015
On Wed, Jun 10, 2015 at 7:54 AM, Matt Riedemann <mriedem at linux.vnet.ibm.com>
> While investigating/discussing bug 1463525  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 .
> 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.
>  https://bugs.launchpad.net/cinder/+bug/1463525
>  https://bugs.launchpad.net/nova/+bug/1321785
> Matt Riedemann
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
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 
which will point you to here .
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev