On Tue, Feb 27, 2018 at 9:34 AM, Walter Boring <wabor...@hemna.com> wrote:
> I think you might be able to get away with just calling os-brick's > connect_volume again without the need to call disconnect_volume first. > calling disconnect_volume wouldn't be good for volumes that are being > used, just to refresh the connection_info on that volume. > Hmm... but then you'd have an orphaned connection left hanging around for the old connection no? > > On Tue, Feb 27, 2018 at 2:56 PM, Matt Riedemann <mriede...@gmail.com> > wrote: > >> On 2/27/2018 10:02 AM, Matthew Booth wrote: >> >>> Sounds like the work Nova will have to do is identical to volume update >>> (swap volume). i.e. Change where a disk's backing store is without actually >>> changing the disk. >>> >> >> That's not what I'm hearing. I'm hearing disconnect/reconnect. Only the >> libvirt driver supports swap volume, but I assume all other virt drivers >> could support this generically. >> >> >>> Multi-attach! There might be more than 1 instance per volume, and we >>> can't currently support volume update for multi-attached volumes. >>> >> Not sure I follow... why not? It's just refreshing connections, only difference is you might have to do this "n" times instead of once? > >> Good point - cinder would likely need to reject a request to replicate an >> in-use multiattach volume if the volume has more than one attachment. > > So replication is set on create of the volume, you could have a rule that keeps the two features mutually exclusive, but I'm still not quite sure why that would be a requirement here. > >> >> -- >> >> Thanks, >> >> Matt >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev