Re: [openstack-dev] [cinder][nova] Update attachments on replication failover

On 2/27/2018 6:34 PM, John Griffith wrote: ​ 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.  ​ Yeah I didn't think of that either, the attachment record has

Re: [openstack-dev] [cinder][nova] Update attachments on replication failover

On Tue, Feb 27, 2018 at 9:34 AM, Walter Boring 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,

Re: [openstack-dev] [cinder][nova] Update attachments on replication failover

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. On Tue, Feb 27, 2018 at 2:56

Re: [openstack-dev] [cinder][nova] Update attachments on replication failover

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

Re: [openstack-dev] [cinder][nova] Update attachments on replication failover

Couple of thoughts: 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. Multi-attach! There might be more than 1 instance per volume, and we can't currently support volume update

Re: [openstack-dev] [cinder][nova] Update attachments on replication failover

On 2/26/2018 9:52 PM, John Griffith wrote: ​Yeah, it seems like this would be pretty handy with what's there.  So are folks good with that?  Wanted to make sure there's nothing contentious there before I propose a spec on the Nova and Cinder sides. If you think it seems at least worth

Re: [openstack-dev] [cinder][nova] Update attachments on replication failover

On Mon, Feb 26, 2018 at 2:47 PM, Matt Riedemann wrote: > On 2/26/2018 9:28 PM, John Griffith wrote: > >> I'm also wondering how much of the extend actions we can leverage here, >> but I haven't looked through all of that yet.​ >> > > The os-server-external-events API in nova

Re: [openstack-dev] [cinder][nova] Update attachments on replication failover

On 2/26/2018 9:28 PM, John Griffith wrote: I'm also wondering how much of the extend actions we can leverage here, but I haven't looked through all of that yet.​ The os-server-external-events API in nova is generic. We'd just add a new microversion to register a new tag for this event. Like

Re: [openstack-dev] [cinder][nova] Update attachments on replication failover

On Mon, Feb 26, 2018 at 2:13 PM, Matt Riedemann wrote: > On 2/26/2018 8:09 PM, John Griffith wrote: > >> I'm interested in looking at creating a mechanism to "refresh" all of the >> existing/current attachments as part of the Cinder Failover process. >> > > What would be

Re: [openstack-dev] [cinder][nova] Update attachments on replication failover

On 2/26/2018 8:09 PM, John Griffith wrote: I'm interested in looking at creating a mechanism to "refresh" all of the existing/current attachments as part of the Cinder Failover process. What would be involved on the nova side for the refresh? I'm guessing disconnect/connect the volume via

[openstack-dev] [cinder][nova] Update attachments on replication failover

Hey Everyone, Something I've been looking at with Cinder's replication (sort of the next step in the evolution if you will) is the ability to refresh/renew in-use volumes that were part of a migration event. We do something similar with extend-volume on the Nova side through the use of Instance