Open Stack

On Wed, Jun 10, 2015 at 7:54 AM, Matt Riedemann <mriedem at 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-request at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150610/5ad7d135/attachment.html>