Re: [nova][cinder][ops] question/confirmation of legacy vol attachment migration
On Tue, Dec 10, 2019 at 11:15 PM Gorka Eguileor geguileo@redhat.com wrote:
On 06/12, Brett Milford wrote:
On Fri, Nov 22, 2019 at 3:54 AM Matt Riedemann mriedemos@gmail.com wrote:
On 10/17/2019 5:24 AM, Gorka Eguileor wrote:
I stand by my initial recommendation, being able to update the existing attachment to add the connection information from Nova.
OK, thanks for the input and thoughtfulness on this. I've abandoned my change since I'm not going to be pushing this boulder anymore but left notes in the change in case someone else wants to pick it up some day.
Note to nova cores: this means we'll have legacy volume attachment compat code around forever.
--
Thanks,
Matt
Hi Groka, Cinder & Nova devs,
Following up this thread from the context of https://review.opendev.org/#/c/579004/
To summarise the discussion:
- initialize_connection shouldn't be called more than once, as it
may mess up some drivers.
- To (safely) refresh connection_info a new api for cinder is required.
Hi,
It may be a new API or a modification of one of the existing ones.
- a patch to nova, such as #579004 could make a call to this new api
to refresh connection info on events such as reboot.
Is there any other context to this issue I've missed or an alternate path to solving this?
Does the creation of a new api for cinder have any implications for being able to backport this patch for nova?
I don't think backporting it in Nova would do us much good, since the Cinder code would not be backportable (it's a new feature, not a bug fix).
What would be the process for me to kick off this work?
You should propose a Cinder spec [1] for your work and you may provide a WIP patch to Cinder at the same time, though depending on the review you may have to completely change that code later.
Cheers, Gorka.
Thanks for your help, Brett (bcm) -- ❯ brett
Cheers Matt, Groka, I thought this might be the case.
On 12-12-19 12:49:57, Brett Milford wrote:
On Tue, Dec 10, 2019 at 11:15 PM Gorka Eguileor geguileo@redhat.com wrote:
On 06/12, Brett Milford wrote:
On Fri, Nov 22, 2019 at 3:54 AM Matt Riedemann mriedemos@gmail.com wrote:
On 10/17/2019 5:24 AM, Gorka Eguileor wrote:
I stand by my initial recommendation, being able to update the existing attachment to add the connection information from Nova.
OK, thanks for the input and thoughtfulness on this. I've abandoned my change since I'm not going to be pushing this boulder anymore but left notes in the change in case someone else wants to pick it up some day.
Note to nova cores: this means we'll have legacy volume attachment compat code around forever.
--
Thanks,
Matt
Hi Groka, Cinder & Nova devs,
Following up this thread from the context of https://review.opendev.org/#/c/579004/
To summarise the discussion:
- initialize_connection shouldn't be called more than once, as it
may mess up some drivers.
- To (safely) refresh connection_info a new api for cinder is required.
Hi,
It may be a new API or a modification of one of the existing ones.
- a patch to nova, such as #579004 could make a call to this new api
to refresh connection info on events such as reboot.
Is there any other context to this issue I've missed or an alternate path to solving this?
Does the creation of a new api for cinder have any implications for being able to backport this patch for nova?
I don't think backporting it in Nova would do us much good, since the Cinder code would not be backportable (it's a new feature, not a bug fix).
What would be the process for me to kick off this work?
You should propose a Cinder spec [1] for your work and you may provide a WIP patch to Cinder at the same time, though depending on the review you may have to completely change that code later.
Cheers, Gorka.
Thanks for your help, Brett (bcm) -- ❯ brett
Cheers Matt, Groka, I thought this might be the case.
Did anyone on the Cinder side pickup the connection_info refresh or export(?) to attachment migration work in the end here? I can't see anything but just wanted to ask before proposing something for V.
Cheers,
On 21-04-20 18:43:29, Lee Yarwood wrote:
On 12-12-19 12:49:57, Brett Milford wrote:
On Tue, Dec 10, 2019 at 11:15 PM Gorka Eguileor geguileo@redhat.com wrote:
On 06/12, Brett Milford wrote:
On Fri, Nov 22, 2019 at 3:54 AM Matt Riedemann mriedemos@gmail.com wrote:
On 10/17/2019 5:24 AM, Gorka Eguileor wrote:
I stand by my initial recommendation, being able to update the existing attachment to add the connection information from Nova.
OK, thanks for the input and thoughtfulness on this. I've abandoned my change since I'm not going to be pushing this boulder anymore but left notes in the change in case someone else wants to pick it up some day.
Note to nova cores: this means we'll have legacy volume attachment compat code around forever.
--
Thanks,
Matt
Hi Groka, Cinder & Nova devs,
Following up this thread from the context of https://review.opendev.org/#/c/579004/
To summarise the discussion:
- initialize_connection shouldn't be called more than once, as it
may mess up some drivers.
- To (safely) refresh connection_info a new api for cinder is required.
Hi,
It may be a new API or a modification of one of the existing ones.
- a patch to nova, such as #579004 could make a call to this new api
to refresh connection info on events such as reboot.
Is there any other context to this issue I've missed or an alternate path to solving this?
Does the creation of a new api for cinder have any implications for being able to backport this patch for nova?
I don't think backporting it in Nova would do us much good, since the Cinder code would not be backportable (it's a new feature, not a bug fix).
What would be the process for me to kick off this work?
You should propose a Cinder spec [1] for your work and you may provide a WIP patch to Cinder at the same time, though depending on the review you may have to completely change that code later.
Cheers, Gorka.
Thanks for your help, Brett (bcm) -- ❯ brett
Cheers Matt, Groka, I thought this might be the case.
Did anyone on the Cinder side pickup the connection_info refresh or export(?) to attachment migration work in the end here? I can't see anything but just wanted to ask before proposing something for V.
Assuming no one is working on this, what about the following that provides a backportable hackaround to specifically address the ceph MON update issue *and* new APIs in V to address the v2 to v3 migration flow.
- Have the c-vol drivers return a flag in their connection_info to indicate when calls to intialize_connection/attachment_update are idempotent. This will allow n-cpu to know here when it's safe to call intialize_connection/attachment_update to fully refresh the connection_info. Both changes should be backportable.
- For the specific ceph MON update issue here, introduce a backportable workaround configurable that forces a refresh of the connection_info for running instances somehow, either through a periodic job, start up of n-cpu or some other trigger.
- Introduce a new c-api v3 API to refresh an attachments connection_info, essentially do all of the above on the Cinder side and have n-cpu call that instead of checking connection_info for the idempotent flag. This wouldn't be backportable.
- Introduce a new n-api API to trigger the refresh of a specific attachments connection_info via the above c-api API. This wouldn't be backportable.
- Introduce a new c-api v3 attachments action (os-migrate) API to migrate from v2 exports to v3 attachments using the above refresh logic, again on the Cinder side.
- Finally remove the idempotent connection_info flag from c-vol and workaround option from n-cpu.
Thoughts?
participants (2)
-
Brett Milford
-
Lee Yarwood