<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 10, 2015 at 7:54 AM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br>
<br>
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].<br>
<br>
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.<br>
<br>
The problem I have right now is knowing what can all be in there, since there are a ton of vendor drivers in Cinder.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
[1] <a href="https://bugs.launchpad.net/cinder/+bug/1463525" target="_blank">https://bugs.launchpad.net/cinder/+bug/1463525</a><br>
[2] <a href="https://bugs.launchpad.net/nova/+bug/1321785" target="_blank">https://bugs.launchpad.net/nova/+bug/1321785</a><span class=""><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:monospace,monospace">Hi Matt,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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].</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I think each of the unique items have their own libvirt connection class, so that kinda helps organize it a bit.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Also there the provider_* fields in the model update that come in (best place to see those is in the DB model).</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Thanks,</div><div class="gmail_default" style="font-family:monospace,monospace">John</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">[1]: <a href="https://github.com/openstack/cinder/blob/master/cinder/volume/targets/iscsi.py#L278">https://github.com/openstack/cinder/blob/master/cinder/volume/targets/iscsi.py#L278</a></div><div class="gmail_default" style="font-family:monospace,monospace">[2]: <a href="https://github.com/openstack/cinder/blob/master/cinder/volume/targets/iscsi.py#L53">https://github.com/openstack/cinder/blob/master/cinder/volume/targets/iscsi.py#L53</a></div><br></div></div>