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
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, just to refresh the
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 PM
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 dr
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 for
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 proposing
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 is generic. We'd just
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 th
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 involved on the nova side
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 os-b
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 A
11 matches
Mail list logo