Open Stack

Hello Zhi Yan,
The multi-attach-volume BP refers to attaching a volume (FC/iSCSI) to multiple hosts. This is required when a nova compute is actually a *cluster* of many hosts. Once the volume is presented to the hosts, then enabling attach of a volume to multiple instances is IMO what your blueprint addresses.

Thanks,
Kiran

> -----Original Message-----
> From: lzy.dev at gmail.com [mailto:lzy.dev at gmail.com]
> Sent: Tuesday, May 14, 2013 2:45 PM
> To: Vaddi, Kiran Kumar
> Cc: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] BP discussion: Attach a single volume to a
> cluster (multiple hosts)
> 
> Kiran,
> 
> Not sure you have see this
> "https://blueprints.launchpad.net/cinder/+spec/shared-volume" before?
> I'm not sure what's the different between it and your
> "https://blueprints.launchpad.net/cinder/+spec/multi-attach-volume"
> proposal. Can you clear that?
> 
> Thanks,
> Zhi Yan
> 
> On Mon, May 13, 2013 at 5:20 PM, lzy.dev at gmail.com <lzy.dev at gmail.com>
> wrote:
> > Hi Kiran,
> >
> > I have a question about R/O volume support for Cinder, I have also
> > added it into  https://blueprints.launchpad.net/cinder/+spec/multi-
> attach-volume.
> >
> > I saw one comment be wrote there is: "Summit feedback: Not doing R/O
> > volumes due to the limited hypervisor that can support setting the
> > volume to R/O, currently only KVM has this capability".
> > But I consider the R/O volumes support is valueable and can be
> > implemented gracefully. I have a plan to implement a Cinder driver
> for
> > Glance (https://blueprints.launchpad.net/glance/+spec/glance-cinder-
> driver),
> > under that case the R/O volume whitin Cinder backend will be created
> > and stored as an image. And base on the particular COW mechanism
> > (depend on Cinder backend store driver) on Nova side, the R/W image
> > (R/O volume based image + delta) can be used for the instance
> > normally.
> >
> > IMO, it's related with your this idea/design, any input?
> >
> > Thanks,
> > Zhi Yan
> >
> > On Mon, May 13, 2013 at 1:50 PM, Vaddi, Kiran Kumar
> > <kiran-kumar.vaddi at hp.com> wrote:
> >>  Hello All,
> >>
> >>  For the use case of attaching a volume created using cinder to an
> >>  instance that is created in a compute node that represents a
> *cluster*
> >>  requires
> >>
> >>  1.       The volume to be presented to all the hosts in the cluster
> >>
> >>  2.       The nova driver to be aware of the target LUN information
> as
> >>  seen for each host and make the volume attach to the instance.
> >>
> >>
> >>   In today's implementation of nova and cinder interfaces for
> attaching a
> >>  volume using the /nova volume-attach/, the control/data flow
> between the
> >>  two components is done based on the assumption that the compute
> node
> >>  consists of only one host. However, some changes need to be done to
> >>  handle clusters represented as a compute node. The problem was
> brought
> >>  up for discussion in the Havana summit with the Cinder team and
> they
> >>  were of the opinion that the problem can be resolved by the
> following
> >>  approach
> >>
> >>  1.       The nova manager will call the driver's
> get_volume_connector
> >>  method to obtain the connector information consisting of the
> compute
> >>  node's HBA information.
> >>
> >>  2.       The driver that manages the cluster will now return the
> details
> >>  of all the hosts in the cluster. This is returned in an additional
> key
> >>  of the dict called clustered_hosts. The value will have the
> connector
> >>  information for each host.
> >>
> >>  3.       /[CHANGE proposed]/The nova manager will now be changed to
> be
> >>  aware of the new key clustered_hosts and then iterate through each
> one
> >>  and call the cinder APIs initialize_connection. Cinder drivers
> response
> >>  to this will remain as it is today, i.e present the volume to the
> host
> >>  and return the target information for the volume.
> >>
> >>  4.       The nova manager will pass the collected target
> information
> >>  back to the nova driver to attach the volume to the instance as a
> new
> >>  key. The driver will now be aware of the new key and perform the
> volume
> >>  attach to the instance.
> >>
> >>
> >>
> >>  Let me know if the above approach is acceptable? Please add the
> >>  necessary nova core team members for reviewing this approach so
> that we
> >>  can discuss and finalize on the approach.
> >>
> >>
> >>  The blueprint link that has additional details. Here is the link:
> >>  https://blueprints.launchpad.net/cinder/+spec/multi-attach-volume
> >>
> >>
> >>  The initial approach that was discussed in the Havana summit was
> with
> >>  cinder doing the looping for each host (steps below). However,
> cinder
> >>  team favored the solution where there would be minimal/no change in
> >>  cinder but yet achieve the same result with the existing
> interfaces/data.
> >>
> >>
> >>  1.       The nova manager will call the driver's
> get_volume_connector
> >>  method to obtain the connector information consisting of the
> compute
> >>  node's HBA information.
> >>
> >>  2.       The driver that manages the cluster will now return the
> details
> >>  of all the hosts in the cluster. This is returned in an additional
> key
> >>  of the dict called clustered_hosts. The value will have the
> connector
> >>  information for each host.
> >>
> >>  3.       The nova manager will call the cinder APIs
> initialize_connection.
> >>
> >>  4.       /[CHANGE proposed initially]/Cinder drivers will be aware
> of
> >>  the new key clustered_hosts and cinder will perform the loop for
> each
> >>  host and
> >>
> >>  a.       present the volume to the host and collect the target
> >>  information for the volume.
> >>
> >>  b.      Collect target information of all hosts and send it back to
> nova
> >>  in a new key
> >>
> >>  5.       The nova manager will pass the collected target
> information
> >>  back to the nova driver to attach the volume to the instance as a
> new
> >>  key. The driver will now be aware of the new key and perform the
> volume
> >>  attach to the instance.
> >>
> >>
> >>  Thanks,
> >>  Kiran
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev