Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

Great, Jon. Thanks for your reply. I am looking forward to your report. Cheers, Boxiang On 10/23/2018 22:01，Jon Bernard wrote： * melanie witt wrote: On Mon, 22 Oct 2018 11:45:55 +0800 (GMT+08:00), Boxiang Zhu wrote: I created a new vm and a new volume with type 'ceph'[So that the volume will

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

On Tue, 23 Oct 2018 10:01:42 -0400, Jon Bernard wrote: * melanie witt wrote: On Mon, 22 Oct 2018 11:45:55 +0800 (GMT+08:00), Boxiang Zhu wrote: I created a new vm and a new volume with type 'ceph'[So that the volume will be created on one of two hosts. I assume that the volume created on host

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

On 10/23/2018 9:01 AM, Jon Bernard wrote: * melanie witt wrote: On Mon, 22 Oct 2018 11:45:55 +0800 (GMT+08:00), Boxiang Zhu wrote: I created a new vm and a new volume with type 'ceph'[So that the volume will be created on one of two hosts. I assume that the volume created on host

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

* melanie witt wrote: > On Fri, 19 Oct 2018 23:21:01 +0800 (GMT+08:00), Boxiang Zhu wrote: > > > > The version of my cinder and nova is Rocky. The scope of the cinder spec[1] > > is only for available volume migration between two pools from the same > > ceph cluster. > > If the volume is in-use

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

* melanie witt wrote: > On Mon, 22 Oct 2018 11:45:55 +0800 (GMT+08:00), Boxiang Zhu wrote: > > I created a new vm and a new volume with type 'ceph'[So that the volume > > will be created on one of two hosts. I assume that the volume created on > > host dev@rbd-1#ceph this time]. Next step is to

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

On Mon, 22 Oct 2018 11:45:55 +0800 (GMT+08:00), Boxiang Zhu wrote: I created a new vm and a new volume with type 'ceph'[So that the volume will be created on one of two hosts. I assume that the volume created on host dev@rbd-1#ceph this time]. Next step is to attach the volume to the vm. At

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

Jay and Melanie, It's my fault to let you misunderstand the problem. I should describe my problem more clearly. My problem is not to migrate volumes between two ceph clusters. I have two clusters, one is openstack cluster(allinone env, hostname is dev) and another is ceph cluster. Omit the

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

Boxiang, I have not herd any discussion of extending this functionality for Ceph to work between different Ceph Clusters.  I wasn't aware, however, that the existing spec was limited to one Ceph cluster. So, that is good to know. I would recommend reaching out to Jon Bernard or Eric Harney

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

On Fri, 19 Oct 2018 23:21:01 +0800 (GMT+08:00), Boxiang Zhu wrote: The version of my cinder and nova is Rocky. The scope of the cinder spec[1] is only for available volume migration between two pools from the same ceph cluster. If the volume is in-use status[2], it will call the generic

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

Hi melanie, thanks for your reply. The version of my cinder and nova is Rocky. The scope of the cinder spec[1] is only for available volume migration between two pools from the same ceph cluster. If the volume is in-use status[2], it will call the generic migration function. So that as you

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

On Fri, 19 Oct 2018 11:33:52 +0800 (GMT+08:00), Boxiang Zhu wrote: When I use the LVM backend to create the volume, then attach it to a vm. I can migrate the volume(in-use) from one host to another. The nova libvirt will call the 'rebase' to finish it. But if using ceph backend, it raises

[openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

Hi folks, When I use the LVM backend to create the volume, then attach it to a vm. I can migrate the volume(in-use) from one host to another. The nova libvirt will call the 'rebase' to finish it. But if using ceph backend, it raises exception 'Swap only supports host devices'. So now it

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

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

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.

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

[openstack-dev] [cinder] [nova] Do we need a "force" parameter in cinder "re-image" API?

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. : ) The API is very simple, something like: URL: POST

[openstack-dev] [cinder][nova][placement] Doodle Calendar Created for Placement Discussion

All, We discussed in our weekly meeting yesterday that it might be good to plan an additional meeting at the PTG to continue discussions with regards to Cinder's use of the Placement Service. I have looked at the room schedule [1] and there are quite a few open rooms on Monday.  Fewer rooms

[openstack-dev] [cinder][nova] - Barbican w/Live Migration in DevStack Multinode

Hi OpenStack Community, I am having some issues with key management in a multinode devstack (from master branch 27th July '18) environment where Barbican is the configured key_manager. I have followed setup instructions from the following pages: *

Re: [openstack-dev] [cinder][nova] Proper behavior for os-force_detach

On 20-07-18 08:10:37, Erlon Cruz wrote: > Nice, good to know. Thanks all for the feedback. We will fix that in our > drivers. FWIW Nova does not and AFAICT never has called os-force_detach. We previously used os-terminate_connection with v2 where the connector was optional. Even then we always

Re: [openstack-dev] [cinder][nova] Proper behavior for os-force_detach

Nice, good to know. Thanks all for the feedback. We will fix that in our drivers. @Walter, so, in this case, if Cinder has the connector, it should not need to call the driver passing a None object right? Erlon Em qua, 18 de jul de 2018 às 12:56, Walter Boring escreveu: > The whole purpose of

Re: [openstack-dev] [cinder][nova] Proper behavior for os-force_detach

The whole purpose of this test is to simulate the case where Nova doesn't know where the vm is anymore, or may simply not exist, but we need to clean up the cinder side of things. That being said, with the new attach API, the connector is being saved in the cinder database for each volume

Re: [openstack-dev] [cinder][nova] Proper behavior for os-force_detach

On 17/07, Sean McGinnis wrote: > On Tue, Jul 17, 2018 at 04:06:29PM -0300, Erlon Cruz wrote: > > Hi Cinder and Nova folks, > > > > Working on some tests for our drivers, I stumbled upon this tempest test > > 'force_detach_volume' > > that is calling Cinder API passing a 'None' connector. At the

Re: [openstack-dev] [cinder][nova] Proper behavior for os-force_detach

On Tue, Jul 17, 2018 at 04:06:29PM -0300, Erlon Cruz wrote: > Hi Cinder and Nova folks, > > Working on some tests for our drivers, I stumbled upon this tempest test > 'force_detach_volume' > that is calling Cinder API passing a 'None' connector. At the time this was > added several CIs > went

[openstack-dev] [cinder][nova] Proper behavior for os-force_detach

Hi Cinder and Nova folks, Working on some tests for our drivers, I stumbled upon this tempest test 'force_detach_volume' that is calling Cinder API passing a 'None' connector. At the time this was added several CIs went down, and people started discussing whether this (accepting/sending a None

Re: [openstack-dev] [cinder][nova] RBD multi-attach

On 04/12/2018 10:25 PM, 李俊波 wrote: > Hello Nova, Cinder developers, > > > > I would like to ask you a question concerns a Cinder patch [1]. > > > > In this patch, it mentioned that RBD features were incompatible with > multi-attach, which disabled multi-attach for RBD. I would like to know

[openstack-dev] [cinder][nova]

Hello Nova, Cinder developers, I would like to ask you a question concerns a Cinder patch [1]. In this patch, it mentioned that RBD features were incompatible with multi-attach, which disabled multi-attach for RBD. I would like to know which RBD features that are incompatible? In the

Re: [openstack-dev] [cinder][nova] about re-image the volume

On 09/04, Sean McGinnis wrote: > On Mon, Apr 09, 2018 at 07:00:56PM +0100, Duncan Thomas wrote: > > Hopefully this flow means we can do rebuild root filesystem from > > snapshot/backup too? It seems rather artificially limiting to only do > > restore-from-image. I'd expect restore-from-snap to be

Re: [openstack-dev] [cinder][nova] about re-image the volume

On 4/9/2018 1:00 PM, Duncan Thomas wrote: Hopefully this flow means we can do rebuild root filesystem from snapshot/backup too? It seems rather artificially limiting to only do restore-from-image. I'd expect restore-from-snap to be a more common use case, personally. Hmm, now you've got me

Re: [openstack-dev] [cinder][nova] about re-image the volume

On Mon, Apr 09, 2018 at 07:00:56PM +0100, Duncan Thomas wrote: > Hopefully this flow means we can do rebuild root filesystem from > snapshot/backup too? It seems rather artificially limiting to only do > restore-from-image. I'd expect restore-from-snap to be a more common > use case, personally. >

Re: [openstack-dev] [cinder][nova] about re-image the volume

Hopefully this flow means we can do rebuild root filesystem from snapshot/backup too? It seems rather artificially limiting to only do restore-from-image. I'd expect restore-from-snap to be a more common use case, personally. On 9 April 2018 at 09:51, Gorka Eguileor wrote: >

Re: [openstack-dev] [cinder][nova] about re-image the volume

On 4/9/2018 3:51 AM, Gorka Eguileor wrote: As I see it, the process would look something like this: - Nova detaches volume using OS-Brick - Nova calls Cinder re-image passing the node's info (like we do when attaching a new volume) - Cinder would: - Ensure only that node is connected to

Re: [openstack-dev] [cinder][nova] about re-image the volume

On 06/04, Matt Riedemann wrote: > On 4/6/2018 5:09 AM, Matthew Booth wrote: > > I think you're talking at cross purposes here: this won't require a > > swap volume. Apart from anything else, swap volume only works on an > > attached volume, and as previously discussed Nova will detach and > >

Re: [openstack-dev] [cinder][nova] about re-image the volume

On 4/6/2018 5:09 AM, Matthew Booth wrote: I think you're talking at cross purposes here: this won't require a swap volume. Apart from anything else, swap volume only works on an attached volume, and as previously discussed Nova will detach and re-attach. Gorka, the Nova api Matt is referring to

Re: [openstack-dev] [cinder][nova] about re-image the volume

On 6 April 2018 at 09:31, Gorka Eguileor wrote: > On 05/04, Matt Riedemann wrote: >> On 4/5/2018 3:15 AM, Gorka Eguileor wrote: >> > But just to be clear, Nova will have to initialize the connection with >> > the re-imagined volume and attach it again to the node, as in all

Re: [openstack-dev] [cinder][nova] about re-image the volume

On 05/04, Matt Riedemann wrote: > On 4/5/2018 3:15 AM, Gorka Eguileor wrote: > > But just to be clear, Nova will have to initialize the connection with > > the re-imagined volume and attach it again to the node, as in all cases > > (except when defaulting to downloading the image and dd-ing it to

Re: [openstack-dev] [cinder][nova] about re-image the volume

On 4/5/2018 3:15 AM, Gorka Eguileor wrote: But just to be clear, Nova will have to initialize the connection with the re-imagined volume and attach it again to the node, as in all cases (except when defaulting to downloading the image and dd-ing it to the volume) the result will be a new volume

Re: [openstack-dev] [cinder][nova] about re-image the volume

On 04/04, Matt Riedemann wrote: > On 4/2/2018 6:59 AM, Gorka Eguileor wrote: > > I can only see one benefit from implementing this feature in Cinder > > versus doing it in Nova, and that is that we can preserve the volume's > > UUID, but I don't think this is even relevant for this use case, so

Re: [openstack-dev] [cinder][nova] about re-image the volume

On 4/2/2018 6:59 AM, Gorka Eguileor wrote: I can only see one benefit from implementing this feature in Cinder versus doing it in Nova, and that is that we can preserve the volume's UUID, but I don't think this is even relevant for this use case, so why is it better to implement this in Cinder

Re: [openstack-dev] [cinder][nova] about re-image the volume

On 29/03, Sean McGinnis wrote: > > This is the spec [0] about rebuild the volumed backed server. > > The question raised in the spec is about how to bandle the root volume. > > Finally,in Nova team,we think that the cleanest / best solution to this is > > to > > add a volume action API to

Re: [openstack-dev] [cinder][nova] about re-image the volume

On 3/29/2018 8:36 PM, Matt Riedemann wrote: On 3/29/2018 6:50 PM, Sean McGinnis wrote: May we can add a "Reimaging" state to the volume? Then Nova could poll for it to go from that back to Available? That would be fine with me, and maybe similar to how 'extending' and 'retyping' work for

Re: [openstack-dev] [cinder][nova] about re-image the volume

On 3/29/2018 6:50 PM, Sean McGinnis wrote: May we can add a "Reimaging" state to the volume? Then Nova could poll for it to go from that back to Available? That would be fine with me, and maybe similar to how 'extending' and 'retyping' work for an attached volume? Nova wouldn't wait for the

Re: [openstack-dev] [cinder][nova] about re-image the volume

> > > > >Ideally, from my perspective, Nova would take care of the detach/attach > >portion > >and Cinder would only need to take care of imaging the volume. > > Agree. :) And yeah, I pointed this out in the nova spec for volume-backed > rebuild also. I think nova can basically handle this like

Re: [openstack-dev] [cinder][nova] about re-image the volume

On 3/29/2018 9:28 AM, Sean McGinnis wrote: I do not think changing the revert to snapshot implementation is appropriate here. There may be some cases where this can get the desired result, but there is no guarantee that there is a snapshot on the volume's base image state to revert to. It also

Re: [openstack-dev] [cinder][nova] about re-image the volume

> This is the spec [0] about rebuild the volumed backed server. > The question raised in the spec is about how to bandle the root volume. > Finally,in Nova team,we think that the cleanest / best solution to this is to > add a volume action API to cinder for re-imaging the volume.Once that is

[openstack-dev] [cinder][nova] about re-image the volume

Hi,all This is the spec [0] about rebuild the volumed backed server.The question raised in the spec is about how to bandle the root volume.Finally,in Nova team,we think that the cleanest / best solution to this is to add a volume action API to cinder for re-imaging the volume.Once that

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

Re: [openstack-dev] [cinder][nova][castellan] Toward deprecating ConfKeyManager

I'm not sure there's a general agreement about removing the fixed key manager code in future. It serves several purposes, testing being the most significant one, though it also covers some people's usecase from a security PoV too where something better might not be worth the complexity trade off.

Re: [openstack-dev] [cinder][nova][castellan] Toward deprecating ConfKeyManager

On Wed, Oct 11, 2017 at 1:17 PM, Dave McCowan (dmccowan) wrote: > Hi Alan-- > Since a fixed-key implementation is not secure, I would prefer not > adding it to Castellan. Our desire is that Castellan can be a best-practice > project to encourage operators to use key

Re: [openstack-dev] [cinder][nova][castellan] Toward deprecating ConfKeyManager

Hi Alan-- Since a fixed-key implementation is not secure, I would prefer not adding it to Castellan. Our desire is that Castellan can be a best-practice project to encourage operators to use key management securely. I'm all for consolidating code and providing good migration paths from

Re: [openstack-dev] [cinder][nova][castellan] Toward deprecating ConfKeyManager

Seems really well thought out. Super impressed by the level of detail here. Consolidation of duplicated code is pretty much always a good idea in my book. Thanks for getting this rolling. I am happy to review as you push patches. Might also be good to get Kaitlin Farr involved too since she knows

Re: [openstack-dev] [cinder][nova][castellan] Toward deprecating ConfKeyManager

> > To that end, I identified a series of small steps to get us there: > > 1) Unify the "fixed_key" oslo_config definitions in Cinder and Nova > so they are identical (right now their help texts are slightly > different). This step avoids triggering a DuplicateOptError exception > in the next

[openstack-dev] [cinder][nova][castellan] Toward deprecating ConfKeyManager

There is an ongoing effort to deprecate the ConfKeyManager, but care must be taken when migrating existing ConfKeyManager deployments to Barbican. The ConfKeyManager's fixed_key secret can be added to Barbican, but the process of switching from one key manager to another will need to be done

Re: [openstack-dev] [cinder][nova]May I run iscsiadm --op show & update 100 times?

On 02/10, Rikimaru Honjo wrote: > Hello, > > I'd like to discuss about the following bug of os-brick. > > * os-brick's iscsi initiator unexpectedly reverts node.startup from > "automatic" to "manual". > https://bugs.launchpad.net/os-brick/+bug/1670237 > > The important point of this bug is: > >

[openstack-dev] [cinder][nova]May I run iscsiadm --op show & update 100 times?

Hello, I'd like to discuss about the following bug of os-brick. * os-brick's iscsi initiator unexpectedly reverts node.startup from "automatic" to "manual". https://bugs.launchpad.net/os-brick/+bug/1670237 The important point of this bug is: When os-brick initializes iscsi connections: 1.

Re: [openstack-dev] [Cinder][Nova][Requirements] Lib freeze exception for os-brick

On Mon, Jul 31, 2017 at 09:09:52PM -0500, Matt Riedemann wrote: > On 7/31/2017 5:21 PM, Tony Breeds wrote: > > We need a +1 from the release team (are they okay to accept a late > > release of glance_store); and a +1 from glance (are they okay to do said > > release) > > Glance doesn't actually

Re: [openstack-dev] [Cinder][Nova][Requirements] Lib freeze exception for os-brick

Do it +1 On Mon, Jul 31, 2017 at 7:37 AM, Sean McGinnis wrote: > I am requesting a library release of os-brick during the feature freeze > in order to fix an issue with the recently landed online volume extend > feature across Nova and Cinder. > > Patches have landed in

Re: [openstack-dev] [Cinder][Nova][Requirements] Lib freeze exception for os-brick

On 17-07-31 21:09:52, Matt Riedemann wrote: > On 7/31/2017 5:21 PM, Tony Breeds wrote: > > We need a +1 from the release team (are they okay to accept a late > > release of glance_store); and a +1 from glance (are they okay to do said > > release) > > Glance doesn't actually need this minimum

Re: [openstack-dev] [Cinder][Nova][Requirements] Lib freeze exception for os-brick

On 7/31/2017 5:21 PM, Tony Breeds wrote: We need a +1 from the release team (are they okay to accept a late release of glance_store); and a +1 from glance (are they okay to do said release) Glance doesn't actually need this minimum version bump for os-brick, the fix is for some attached

Re: [openstack-dev] [Cinder][Nova][Requirements] Lib freeze exception for os-brick

On Mon, Jul 31, 2017 at 03:00:16PM -0500, Sean McGinnis wrote: > > I am requesting a library release of os-brick during the feature freeze > > in order to fix an issue with the recently landed online volume extend > > feature across Nova and Cinder. > > > > New os-brick 1.15.2 release has been

Re: [openstack-dev] [Cinder][Nova][Requirements] Lib freeze exception for os-brick

> I am requesting a library release of os-brick during the feature freeze > in order to fix an issue with the recently landed online volume extend > feature across Nova and Cinder. > New os-brick 1.15.2 release has been requested here: https://review.openstack.org/489370 Thanks, Sean

Re: [openstack-dev] [Cinder][Nova][Requirements] Lib freeze exception for os-brick

Sounds reasonable for me too. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Mon, Jul 31, 2017 at 5:40 PM, Davanum Srinivas wrote: > I'd support this Sean. +1 > > Thanks, > Dims > > On Mon, Jul 31, 2017 at 10:37 AM, Sean McGinnis > wrote: > > I

Re: [openstack-dev] [Cinder][Nova][Requirements] Lib freeze exception for os-brick

Yep, please submit the review refrencing this thread, lgtm. On 17-07-31 10:40:10, Davanum Srinivas wrote: > I'd support this Sean. +1 > > Thanks, > Dims > > On Mon, Jul 31, 2017 at 10:37 AM, Sean McGinnis wrote: > > I am requesting a library release of os-brick during

Re: [openstack-dev] [Cinder][Nova][Requirements] Lib freeze exception for os-brick

I'd support this Sean. +1 Thanks, Dims On Mon, Jul 31, 2017 at 10:37 AM, Sean McGinnis wrote: > I am requesting a library release of os-brick during the feature freeze > in order to fix an issue with the recently landed online volume extend > feature across Nova and

[openstack-dev] [Cinder][Nova][Requirements] Lib freeze exception for os-brick

I am requesting a library release of os-brick during the feature freeze in order to fix an issue with the recently landed online volume extend feature across Nova and Cinder. Patches have landed in both projects to add this feature. It wasn't until later that Matt was able to get tempest tests in

Re: [openstack-dev] [cinder] [nova] How to provide additional options to NFS backend?

V Wed, 31 May 2017 11:34:20 -0400 Eric Harney napsáno: > On 05/25/2017 05:51 AM, Jiri Suchomel wrote: > > Hi, > > it seems to me that the way of adding extra NFS options to the > > cinder backend is somewhat confusing. > > > > 1. There is nfs_mount_options in cinder config

Re: [openstack-dev] [cinder][nova][os-brick] Testing for proposed iSCSI OS-Brick code

On 31/05, Matt Riedemann wrote: > On 5/31/2017 6:58 AM, Gorka Eguileor wrote: > > Hi, > > > > As some of you may know I've been working on improving iSCSI connections > > on OpenStack to make them more robust and prevent them from leaving > > leftovers on attach/detach operations. > > > > There

Re: [openstack-dev] [cinder] [nova] How to provide additional options to NFS backend?

On 5/31/2017 12:02 PM, Jiri Suchomel wrote: V Wed, 31 May 2017 11:34:20 -0400 Eric Harney napsáno: On 05/25/2017 05:51 AM, Jiri Suchomel wrote: Hi, it seems to me that the way of adding extra NFS options to the cinder backend is somewhat confusing. ... This has gotten

Re: [openstack-dev] [cinder] [nova] How to provide additional options to NFS backend?

V Wed, 31 May 2017 11:34:20 -0400 Eric Harney napsáno: > On 05/25/2017 05:51 AM, Jiri Suchomel wrote: > > Hi, > > it seems to me that the way of adding extra NFS options to the > > cinder backend is somewhat confusing. > > > > ... > This has gotten a bit more confusing than

Re: [openstack-dev] [cinder] [nova] How to provide additional options to NFS backend?

On 05/25/2017 05:51 AM, Jiri Suchomel wrote: > Hi, > it seems to me that the way of adding extra NFS options to the cinder > backend is somewhat confusing. > > 1. There is nfs_mount_options in cinder config file [1] > > 2. Then I can put my options to the nfs_shares_config file - that > it

Re: [openstack-dev] [cinder][nova][os-brick] Testing for proposed iSCSI OS-Brick code

On 5/31/2017 6:58 AM, Gorka Eguileor wrote: Hi, As some of you may know I've been working on improving iSCSI connections on OpenStack to make them more robust and prevent them from leaving leftovers on attach/detach operations. There are a couple of posts [1][2] going in more detail, but a

[openstack-dev] [cinder][nova][os-brick] Testing for proposed iSCSI OS-Brick code

Hi, As some of you may know I've been working on improving iSCSI connections on OpenStack to make them more robust and prevent them from leaving leftovers on attach/detach operations. There are a couple of posts [1][2] going in more detail, but a good summary would be that to fix this issue we

[openstack-dev] [cinder] [nova] How to provide additional options to NFS backend?

Hi, it seems to me that the way of adding extra NFS options to the cinder backend is somewhat confusing. 1. There is nfs_mount_options in cinder config file [1] 2. Then I can put my options to the nfs_shares_config file - that it could contain additional options mentiones [2] or the commit

[openstack-dev] [cinder]nova client code

Hi! As we're trying to use the InstanceLocalityFilter in cinder, I encountered some strange issues. I've opened a bug report already: https://bugs.launchpad.net/cinder/+bug/1686616 But further looking at the novaclient code in Cinder, cinder/nova.py smells a bit more. Seems the latest

Re: [openstack-dev] [Cinder][Nova] Scheduling issue for the Summit

On Thu, Apr 20, 2017 at 06:55:30PM -0500, Jay S Bryant wrote: > Sean, > > In the case that all the conflicts cannot be resolved I would be happy to > cover the Onboarding session if you can keep me in the loop/take items for > the Cinder Ephemeral session. > > Let me know, > > Jay > Thanks

Re: [openstack-dev] [Cinder][Nova] Scheduling issue for the Summit

Sean, In the case that all the conflicts cannot be resolved I would be happy to cover the Onboarding session if you can keep me in the loop/take items for the Cinder Ephemeral session. Let me know, Jay On 4/20/2017 9:55 AM, Sean McGinnis wrote: Unfortunately I am way late at noticing

Re: [openstack-dev] [Cinder][Nova] Scheduling issue for the Summit

Will do, thanks! On Thu, Apr 20, 2017 at 09:59:39AM -0500, Jimmy McArthur wrote: > Sean, > > Can you send this request into speakersupp...@openstack.org and we'll see if > we can move it around. > > Thanks, > Jimmy > > >Sean McGinnis > >April 20, 2017 at 9:55 AM

Re: [openstack-dev] [Cinder][Nova] Scheduling issue for the Summit

Sean, Can you send this request into speakersupp...@openstack.org and we'll see if we can move it around. Thanks, Jimmy Sean McGinnis April 20, 2017 at 9:55 AM Unfortunately I am way late at noticing this, but bringing it up in case there's anything that can

[openstack-dev] [Cinder][Nova] Scheduling issue for the Summit

Unfortunately I am way late at noticing this, but bringing it up in case there's anything that can still be done about it. Tuesday the 9th, from 11:15am-11:55am, is going to be a challenge for me. The Track Chairs Recap, Using Cinder for Nova Ephemeral Storage, and the Cinder - Project Onboarding

[openstack-dev] [cinder][nova] Cinder-Nova API meeting time slot change

Hi All, As of __today__ the Cinder-Nova API interactions meeting has a new time slot, __1600 UTC__. The meeting channel is the same: __#openstack-meeting-cp__. The patch [1] to change the slot officially is still under review with no conflicts. See you soon! Thanks and Best Regards, Ildikó

Re: [openstack-dev] [Cinder] [Nova] Extend attached volume

Hey, Mathieu Thanks for bringing us the solution, Jay and I are willing to help if you are looking for someone to coordinate at the Cinder side. TommyLike.Hu On 2017-04-04 08:50 , Mathieu Gagné Wrote: Hi, On Mon, Apr 3, 2017 at 8:40 PM, Jay S Bryant wrote: > > Thank you

Re: [openstack-dev] [Cinder] [Nova] Extend attached volume

On 4/3/2017 11:27 AM, Walter Boring wrote: Actually, this is incorrect. The sticking point of this all was doing the coordination and initiation of workflow from Nova. Cinder already has the ability to call the driver to do the resize of the volume. Cinder just prevents this now, because

Re: [openstack-dev] [Cinder] [Nova] Extend attached volume

Hi, On Mon, Apr 3, 2017 at 8:40 PM, Jay S Bryant wrote: > > Thank you for sharing this. Nice to see you have a solution that looks > agreeable to Matt. Do you think you can get a spec pushed up and propose > your code? > I will go ahead, write the spec and contribute the

Re: [openstack-dev] [Cinder] [Nova] Extend attached volume

Mathieu, Thank you for sharing this. Nice to see you have a solution that looks agreeable to Matt. Do you think you can get a spec pushed up and propose your code? Jay On 4/3/2017 2:21 PM, Mathieu Gagné wrote: On Mon, Apr 3, 2017 at 12:27 PM, Walter Boring wrote:

Re: [openstack-dev] [Cinder] [Nova] Extend attached volume

On 4/3/2017 5:30 PM, Matt Riedemann wrote: On 4/3/2017 2:21 PM, Mathieu Gagné wrote: I would like to share our private implementation (based on Mitaka): https://gist.github.com/mgagne/9402089c11f8c80f6d6cd49f3db76512 The implementation makes it so Cinder leverages the existing Nova

Re: [openstack-dev] [Cinder] [Nova] Extend attached volume

On 4/3/2017 2:21 PM, Mathieu Gagné wrote: I would like to share our private implementation (based on Mitaka): https://gist.github.com/mgagne/9402089c11f8c80f6d6cd49f3db76512 The implementation makes it so Cinder leverages the existing Nova external-events endpoint to trigger the BDM update and

Re: [openstack-dev] [Cinder] [Nova] Extend attached volume

On Mon, Apr 3, 2017 at 12:27 PM, Walter Boring wrote: > Actually, this is incorrect. > > The sticking point of this all was doing the coordination and initiation of > workflow from Nova. Cinder already has the ability to call the driver to > do the resize of the volume.

Re: [openstack-dev] [Cinder] [Nova] Extend attached volume

Actually, this is incorrect. The sticking point of this all was doing the coordination and initiation of workflow from Nova. Cinder already has the ability to call the driver to do the resize of the volume. Cinder just prevents this now, because there is work that has to be done on the

Re: [openstack-dev] [Cinder] [Nova] Extend attached volume

On 4/1/2017 4:07 PM, Matt Riedemann wrote: On 4/1/2017 12:17 PM, Jay Bryant wrote: Matt, I think discussion on this goes all the way back to Tokyo. There was work on the Cinder side to send the notification to Nova which I believe all the pieces were in place for. The missing part (sticking

Re: [openstack-dev] [Cinder] [Nova] Extend attached volume

On 4/1/2017 12:17 PM, Jay Bryant wrote: Matt, I think discussion on this goes all the way back to Tokyo. There was work on the Cinder side to send the notification to Nova which I believe all the pieces were in place for. The missing part (sticking point) was doing a rescan of the SCSI bus in

  1   2   3   4   >