Open Stack

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" <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150610/f421dc47/attachment.html>