| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-04-27 | |||
| 13:01:55 | openstack | bugzilla.redhat.com bug 1566723 in RBD "Instance live migration times out after <x> seconds with nova - doesn't copy instance memory" [High,Closed: errata] - Assigned to jdillama | |
| 13:01:55 | sean-k-mooney | that was form https://bugzilla.redhat.com/show_bug.cgi?id=1566723 | |
| 13:01:55 | openstack | bugzilla.redhat.com bug 1566723 in RBD "Instance live migration times out after <x> seconds with nova - doesn't copy instance memory" [High,Closed: errata] - Assigned to jdillama | |
| 13:03:08 | sean-k-mooney | frickler: apparently restarting OSDs durign the migration could cause locking issues in librbd in the past | |
| 13:03:08 | sean-k-mooney | frickler: apparently restarting OSDs durign the migration could cause locking issues in librbd in the past | |
| 13:03:33 | frickler | oh, I can check whether this is actually a boot-from-volume instance | |
| 13:03:33 | frickler | oh, I can check whether this is actually a boot-from-volume instance | |
| 13:04:20 | sean-k-mooney | frickler: there is also https://bugs.launchpad.net/nova/+bug/1583145 | |
| 13:04:21 | openstack | Launchpad bug 1644248 in OpenStack Compute (nova) "duplicate for #1583145 Nova incorrectly tracks live migration progress" [High,Fix released] | |
| 13:04:21 | sean-k-mooney | frickler: there is also https://bugs.launchpad.net/nova/+bug/1583145 | |
| 13:04:21 | openstack | Launchpad bug 1644248 in OpenStack Compute (nova) "duplicate for #1583145 Nova incorrectly tracks live migration progress" [High,Fix released] | |
| 13:04:44 | sean-k-mooney | oh the other one is fixed | |
| 13:04:44 | sean-k-mooney | oh the other one is fixed | |
| 13:04:49 | sean-k-mooney | https://bugs.launchpad.net/nova/+bug/1644248 | |
| 13:04:50 | openstack | Launchpad bug 1644248 in OpenStack Compute (nova) "Nova incorrectly tracks live migration progress" [High,Fix released] | |
| 13:04:50 | sean-k-mooney | https://bugs.launchpad.net/nova/+bug/1644248 | |
| 13:04:50 | openstack | Launchpad bug 1644248 in OpenStack Compute (nova) "Nova incorrectly tracks live migration progress" [High,Fix released] | |
| 13:18:13 | sean-k-mooney | bauzas: gibi lyarwood if we were to impleemnte the generic nova manage command for updating image metadata | |
| 13:18:13 | sean-k-mooney | bauzas: gibi lyarwood if we were to impleemnte the generic nova manage command for updating image metadata | |
| 13:18:26 | sean-k-mooney | how would ye feel about backpoarting hat | |
| 13:18:26 | sean-k-mooney | how would ye feel about backpoarting hat | |
| 13:18:28 | sean-k-mooney | *that | |
| 13:18:28 | sean-k-mooney | *that | |
| 13:18:57 | sean-k-mooney | elod: any tought form a stable core perspective | |
| 13:18:57 | sean-k-mooney | elod: any tought form a stable core perspective | |
| 13:19:44 | sean-k-mooney | context is we have a custoemr downstream that really want to fix a few instance by adding os-type=windows to the inatnce that were booted before they fixed there windows images | |
| 13:19:45 | sean-k-mooney | context is we have a custoemr downstream that really want to fix a few instance by adding os-type=windows to the inatnce that were booted before they fixed there windows images | |
| 13:20:18 | sean-k-mooney | and today they will have to do a manual db update to do that | |
| 13:20:18 | sean-k-mooney | and today they will have to do a manual db update to do that | |
| 13:20:38 | sean-k-mooney | then live/cold migrate teh inststances so they land up in the correct host aggrate after | |
| 13:20:38 | sean-k-mooney | then live/cold migrate teh inststances so they land up in the correct host aggrate after | |
| 13:21:38 | bauzas | sean-k-mooney: in general, we don't accept to backport features like this | |
| 13:21:39 | bauzas | sean-k-mooney: in general, we don't accept to backport features like this | |
| 13:21:42 | bauzas | (upstream) | |
| 13:21:42 | bauzas | (upstream) | |
| 13:22:23 | sean-k-mooney | bauzas: in general but we have backported nova-manage command on the bases it resolved operator pain in the past | |
| 13:22:24 | sean-k-mooney | bauzas: in general but we have backported nova-manage command on the bases it resolved operator pain in the past | |
| 13:22:35 | sean-k-mooney | like the heal allocations ones | |
| 13:22:35 | sean-k-mooney | like the heal allocations ones | |
| 13:28:33 | bauzas | sean-k-mooney: yup, because it's a bugfix | |
| 13:28:33 | bauzas | sean-k-mooney: yup, because it's a bugfix | |
| 13:29:49 | bauzas | but fwiw, we abandoned the backports for the placement audit https://review.opendev.org/q/I537ed74503d208957f0a97af3ab754a6750dac20 | |
| 13:29:49 | bauzas | but fwiw, we abandoned the backports for the placement audit https://review.opendev.org/q/I537ed74503d208957f0a97af3ab754a6750dac20 | |
| 13:41:45 | elod | sean-k-mooney: bauzas is right: in general, we don't accept to backport features like this | |
| 13:41:46 | elod | sean-k-mooney: bauzas is right: in general, we don't accept to backport features like this | |
| 13:43:18 | frickler | sean-k-mooney: turns out this migration was in status "queued", being held up by another one in progress that is having trouble getting the disk synced, seems I didn't look close enough there. thanks for your help anyway | |
| 13:43:18 | frickler | sean-k-mooney: turns out this migration was in status "queued", being held up by another one in progress that is having trouble getting the disk synced, seems I didn't look close enough there. thanks for your help anyway | |
| 13:43:59 | sean-k-mooney | frickler: glad you figured it out | |
| 13:43:59 | sean-k-mooney | frickler: glad you figured it out | |
| 13:45:16 | sean-k-mooney | elod: bauzas yep i know and in general we do not allow custoemr to do db udate eitehr. i dont partically want to do a downstream only backport of that feature. i think it would be generic useful but if we do not want to backport it that is fine | |
| 13:45:16 | sean-k-mooney | elod: bauzas yep i know and in general we do not allow custoemr to do db udate eitehr. i dont partically want to do a downstream only backport of that feature. i think it would be generic useful but if we do not want to backport it that is fine | |
| 14:09:50 | elod | sean-k-mooney: well, according to policy, there could be exceptions. I still tend to say no for this backport (though I haven't seen the implementation) | |
| 14:09:50 | elod | sean-k-mooney: well, according to policy, there could be exceptions. I still tend to say no for this backport (though I haven't seen the implementation) | |
| 14:10:22 | elod | exception* -- if stable cores agree... | |
| 14:10:22 | elod | exception* -- if stable cores agree... | |
| 14:10:51 | sean-k-mooney | elod: its not written yet :) | |
| 14:10:51 | sean-k-mooney | elod: its not written yet :) | |
| 14:12:49 | sean-k-mooney | elod: it would be https://review.opendev.org/c/openstack/nova/+/774896/8/nova/cmd/manage.py excpet instead of setting just machine_type you could set any image metatadata value that does not chagne resouce usage | |
| 14:12:49 | sean-k-mooney | elod: it would be https://review.opendev.org/c/openstack/nova/+/774896/8/nova/cmd/manage.py excpet instead of setting just machine_type you could set any image metatadata value that does not chagne resouce usage | |
| 14:13:57 | sean-k-mooney | elod: anyway its fine i was going to say if it was short to implement and contovertial then maybe instead of deliving a custom sql srcript we could implement this and backport it for our customer to use | |
| 14:13:57 | sean-k-mooney | elod: anyway its fine i was going to say if it was short to implement and contovertial then maybe instead of deliving a custom sql srcript we could implement this and backport it for our customer to use | |
| 14:19:00 | gibi | elod, sean-k-mooney: we discussed backport nova-manage "feature" in the past. Like heal allocation. It is useful, it is self contained in mostly in the manage.py and it is not impacting any of our public APIs | |
| 14:19:00 | gibi | elod, sean-k-mooney: we discussed backport nova-manage "feature" in the past. Like heal allocation. It is useful, it is self contained in mostly in the manage.py and it is not impacting any of our public APIs | |
| 14:19:22 | gibi | so it is pretty safe to backport | |
| 14:19:22 | gibi | so it is pretty safe to backport | |
| 14:19:48 | gibi | I was lazy and did not backported the port allocation part of the heal allocation command to stable but we did agreed with mriedem in the past that that could happen | |
| 14:19:48 | gibi | I was lazy and did not backported the port allocation part of the heal allocation command to stable but we did agreed with mriedem in the past that that could happen | |
| 14:20:39 | gibi | also I'm supporting to backporting thigs that helps avoiding the need of direct and manual db update | |
| 14:20:39 | gibi | also I'm supporting to backporting thigs that helps avoiding the need of direct and manual db update | |
| 14:21:12 | gibi | nobody likes customer bugs where the db was manually changed for some reason and it caused inconsitencies | |
| 14:21:12 | gibi | nobody likes customer bugs where the db was manually changed for some reason and it caused inconsitencies | |
| 14:25:48 | elod | in that case... if it really is as gibi says, and the implementation looks OK in the sense of backportability... then so be it :] | |
| 14:25:48 | elod | in that case... if it really is as gibi says, and the implementation looks OK in the sense of backportability... then so be it :] | |
| 14:26:14 | elod | if there are no objections from other stable cores | |
| 14:26:15 | elod | if there are no objections from other stable cores | |
| 14:26:55 | gibi | :) | |
| 14:27:04 | gibi | I can be pretty convincing :) | |
| 14:27:04 | gibi | I can be pretty convincing :) | |
| 14:37:18 | sean-k-mooney | well we need to write it and get project core to agree on it first. | |
| 14:37:18 | sean-k-mooney | well we need to write it and get project core to agree on it first. | |
| 14:38:05 | sean-k-mooney | just wondering if we should plan to make it backportable when writing it or not basically and if there was apite to backport it at all | |
| 14:38:06 | sean-k-mooney | just wondering if we should plan to make it backportable when writing it or not basically and if there was apite to backport it at all | |
| 15:33:47 | openstackgerrit | Jessie Lass proposed openstack/nova master: Add emulation support if host arch != guest arch. https://review.opendev.org/c/openstack/nova/+/772156 | |
| 15:52:58 | gibi | melwitt: hi! I have left comments in the consumer_type patch series. | |
| 15:52:58 | gibi | melwitt: hi! I have left comments in the consumer_type patch series. | |
| 15:57:06 | gibi | if you like them then I might as a favor to look at my RP re-parenting spec / impl :) | |
| 15:57:06 | gibi | if you like them then I might as a favor to look at my RP re-parenting spec / impl :) | |
| 15:58:36 | sean-k-mooney | speaking of placemnt there is no resource provider allocation candiate create command in osc-placment | |
| 15:58:36 | sean-k-mooney | speaking of placemnt there is no resource provider allocation candiate create command in osc-placment | |
| 15:58:54 | sean-k-mooney | it might be nice to have one for debuging | |
| 15:58:55 | sean-k-mooney | it might be nice to have one for debuging | |
| 15:59:22 | sean-k-mooney | granted we can use curl pretty simply but was debuging something there and it would have been nice to have | |
| 15:59:22 | sean-k-mooney | granted we can use curl pretty simply but was debuging something there and it would have been nice to have | |
| 16:01:27 | gibi | sean-k-mooney: I think we have openstack --os-placement-api-version 1.29 allocation candidate list | |
| 16:01:27 | gibi | sean-k-mooney: I think we have openstack --os-placement-api-version 1.29 allocation candidate list | |
| 16:02:18 | sean-k-mooney | oh cool | |
| 16:02:18 | sean-k-mooney | oh cool | |
| 16:02:30 | sean-k-mooney | this is a train version of osc-placment | |
| 16:02:30 | sean-k-mooney | this is a train version of osc-placment | |
| 16:02:38 | sean-k-mooney | so i guess its jsut a little too old for that | |