Re: [openstack-dev] [cinder] [nova] Do we need a "force" parameter in cinder "re-image" API?
On 10/8/2018 8:54 AM, Sean McGinnis wrote: On Mon, Oct 08, 2018 at 03:09:36PM +0800, Yikun Jiang wrote: In Denver, we agree to add a new "re-image" API in cinder to support upport volume-backed server rebuild with a new image. An initial blueprint has been drafted in [3], welcome to review it, thanks. : ) [snip] The "force" parameter idea comes from [4], means that 1. we can re-image an "available" volume directly. 2. we can't re-image "in-use"/"reserved" volume directly. 3. we can only re-image an "in-use"/"reserved" volume with "force" parameter. And it means nova need to always call re-image API with an extra "force" parameter, because the volume status is "in-use" or "reserve" when we rebuild the server. *So, what's you idea? Do we really want to add this "force" parameter?* I would prefer we have the "force" parameter, even if it is something that will always be defaulted to True from Nova. Having this exposed as a REST API means anyone could call it, not just Nova code. So as protection from someone doing something that they are not really clear on the full implications of, having a flag in there to guard volumes that are already attached or reserved for shelved instances is worth the very minor extra overhead. I concur with Sean's assessment. I think putting a safety switch in place in this design is important to ensure that people using the API directly are less likely to do something that they may not actually want to do. Jay [1] https://etherpad.openstack.org/p/nova-ptg-stein L483 [2] https://etherpad.openstack.org/p/cinder-ptg-stein-thursday-rebuild L12 [3] https://review.openstack.org/#/c/605317 [4] https://review.openstack.org/#/c/605317/1/specs/stein/add-volume-re-image-api.rst@75 Regards, Yikun Jiang Yikun(Kero) Mail: yikunk...@gmail.com __ 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 __ 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
Re: [openstack-dev] [cinder] [nova] Do we need a "force" parameter in cinder "re-image" API?
On 10/9/2018 8:04 AM, Erlon Cruz wrote: If you are planning to re-image an image on a bootable volume then yes you should use a force parameter. I have lost the discussion about this on PTG. What is the main use cases? This seems to me something that could be leveraged with the current revert-to-snapshot API, which would be even better. The flow would be: 1 - create a volume from image 2 - create an snapshot 3 - do whatever you wan't 4 - revert the snapshot Would that help in your the use cases? As the spec mentions, this is for enabling re-imaging the root volume on a server when nova rebuilds the server. That is not allowed today because the compute service can't re-image the root volume. We don't want to jump through a bunch of gross alternative hoops to create a new root volume with the new image and swap them out (the reasons why are in the spec, and have been discussed previously in the ML). So nova is asking cinder to provide an API to change the image in a volume which the nova rebuild operation will use to re-image the root volume on a volume-backed server. I don't know if revert-to-snapshot solves that use case, but it doesn't sound like it. With the nova rebuild API, the user provides an image reference and that is used to re-image the root disk on the server. So it might not be a snapshot, it could be something new. -- Thanks, Matt __ 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
Re: [openstack-dev] [cinder] [nova] Do we need a "force" parameter in cinder "re-image" API?
If you are planning to re-image an image on a bootable volume then yes you should use a force parameter. I have lost the discussion about this on PTG. What is the main use cases? This seems to me something that could be leveraged with the current revert-to-snapshot API, which would be even better. The flow would be: 1 - create a volume from image 2 - create an snapshot 3 - do whatever you wan't 4 - revert the snapshot Would that help in your the use cases? Em seg, 8 de out de 2018 às 10:54, Sean McGinnis escreveu: > On Mon, Oct 08, 2018 at 03:09:36PM +0800, Yikun Jiang wrote: > > In Denver, we agree to add a new "re-image" API in cinder to support > upport > > volume-backed server rebuild with a new image. > > > > An initial blueprint has been drafted in [3], welcome to review it, > thanks. > > : ) > > > > [snip] > > > > The "force" parameter idea comes from [4], means that > > 1. we can re-image an "available" volume directly. > > 2. we can't re-image "in-use"/"reserved" volume directly. > > 3. we can only re-image an "in-use"/"reserved" volume with "force" > > parameter. > > > > And it means nova need to always call re-image API with an extra "force" > > parameter, > > because the volume status is "in-use" or "reserve" when we rebuild the > > server. > > > > *So, what's you idea? Do we really want to add this "force" parameter?* > > > > I would prefer we have the "force" parameter, even if it is something that > will > always be defaulted to True from Nova. > > Having this exposed as a REST API means anyone could call it, not just Nova > code. So as protection from someone doing something that they are not > really > clear on the full implications of, having a flag in there to guard volumes > that > are already attached or reserved for shelved instances is worth the very > minor > extra overhead. > > > [1] https://etherpad.openstack.org/p/nova-ptg-stein L483 > > [2] https://etherpad.openstack.org/p/cinder-ptg-stein-thursday-rebuild > L12 > > [3] https://review.openstack.org/#/c/605317 > > [4] > > > https://review.openstack.org/#/c/605317/1/specs/stein/add-volume-re-image-api.rst@75 > > > > Regards, > > Yikun > > > > Jiang Yikun(Kero) > > Mail: yikunk...@gmail.com > > > > __ > > 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 > __ 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
Re: [openstack-dev] [cinder] [nova] Do we need a "force" parameter in cinder "re-image" API?
On Mon, Oct 08, 2018 at 03:09:36PM +0800, Yikun Jiang wrote: > In Denver, we agree to add a new "re-image" API in cinder to support upport > volume-backed server rebuild with a new image. > > An initial blueprint has been drafted in [3], welcome to review it, thanks. > : ) > > [snip] > > The "force" parameter idea comes from [4], means that > 1. we can re-image an "available" volume directly. > 2. we can't re-image "in-use"/"reserved" volume directly. > 3. we can only re-image an "in-use"/"reserved" volume with "force" > parameter. > > And it means nova need to always call re-image API with an extra "force" > parameter, > because the volume status is "in-use" or "reserve" when we rebuild the > server. > > *So, what's you idea? Do we really want to add this "force" parameter?* > I would prefer we have the "force" parameter, even if it is something that will always be defaulted to True from Nova. Having this exposed as a REST API means anyone could call it, not just Nova code. So as protection from someone doing something that they are not really clear on the full implications of, having a flag in there to guard volumes that are already attached or reserved for shelved instances is worth the very minor extra overhead. > [1] https://etherpad.openstack.org/p/nova-ptg-stein L483 > [2] https://etherpad.openstack.org/p/cinder-ptg-stein-thursday-rebuild L12 > [3] https://review.openstack.org/#/c/605317 > [4] > https://review.openstack.org/#/c/605317/1/specs/stein/add-volume-re-image-api.rst@75 > > Regards, > Yikun > > Jiang Yikun(Kero) > Mail: yikunk...@gmail.com > __ > 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