| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-02 | |||
| 14:46:43 | sean-k-mooney | it work in most cases | |
| 14:46:51 | sean-k-mooney | but it cant resize image to match the flavor | |
| 14:47:08 | sean-k-mooney | we could fix that but not sure we want too | |
| 14:47:30 | sean-k-mooney | stephenfin: we said we would deprecated at least if it did not have a ci by the end of victoria | |
| 14:47:49 | sean-k-mooney | so if we want to remove it we proably could. | |
| 14:48:13 | sean-k-mooney | i would still like to have support for it but im not going to work on it this cycle | |
| 14:51:01 | sean-k-mooney | dansmith: looks like https://review.opendev.org/c/openstack/devstack/+/771505 took about 17 mins off the job time | |
| 14:51:40 | sean-k-mooney | well comparing to bionic | |
| 14:51:58 | sean-k-mooney | not sure that is the same but its shaved off at least 3 mins | |
| 14:52:39 | sean-k-mooney | ah ya it inherits form tempest-full-py3 | |
| 14:52:58 | sean-k-mooney | so ya about 2-3 mins which is not bad | |
| 14:53:39 | sean-k-mooney | most of the time in that job is still tempest anyway | |
| 14:53:53 | dansmith | sean-k-mooney: well, I looked at a bunch of run times and even on the same worker, it was really not fair to compare the times | |
| 14:54:22 | dansmith | we found cases where one run would be 50% longer on the same worker a couple hours before another | |
| 14:54:28 | sean-k-mooney | ya i guess eye ball stats are not exctly the best way to look at this | |
| 14:54:52 | dansmith | unless it's making it longer, which I don't think it is, I think we can rely on our local repeatable stats to say that this will be an improvement overall in the aggregate | |
| 14:54:59 | dansmith | we just need to be able to turn it on | |
| 14:55:50 | sean-k-mooney | ya then we can use zull stats form multiple runs to work out the avergae job time over a month or so and see if it goes down or not | |
| 15:03:07 | alexe9191 | hello all:) I seem to have a problem with volume detachment after upgrading cinder. I am wondering if someone here in nova can help me | |
| 15:03:31 | alexe9191 | it seems that the detachment request is not sending the os-detach id to cinder and that's breaking cinder basically. | |
| 15:03:49 | alexe9191 | nova version is kilo, cinder version is rocky:) I know .. | |
| 15:04:31 | sean-k-mooney | cinder should be microverioning there api and the kilo version should be using an old microverion | |
| 15:04:39 | sean-k-mooney | so it sound like cinder broke there compatiablity | |
| 15:05:03 | sean-k-mooney | unfortunetlly im not famiarl enough with that interaction to help | |
| 15:05:03 | alexe9191 | is there a way to pin the version of cinder api? i am pretty sure nova is calling version 2 API | |
| 15:05:19 | alexe9191 | thanks in all cases:) | |
| 15:34:16 | openstackgerrit | sean mooney proposed openstack/nova stable/ussuri: only wait for plugtime events in pre-live-migration https://review.opendev.org/c/openstack/nova/+/770745 | |
| 15:34:17 | kashyap | stephenfin: I see you submitted this backport: https://review.opendev.org/c/openstack/nova/+/758763/ | |
| 15:34:46 | kashyap | stephenfin: Can we get it rolling. It fixes an important live migration issue | |
| 15:34:58 | kashyap | s/rolling./rolling?/ :-) | |
| 15:35:25 | kashyap | (Train backport, specifically) | |
| 16:27:08 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: Handle disabled CPU features to fix live migration failures https://review.opendev.org/c/openstack/nova/+/758763 | |
| 16:28:15 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: Handle disabled CPU features to fix live migration failures https://review.opendev.org/c/openstack/nova/+/758763 | |
| 16:28:35 | lyarwood | kashyap: ^ lets wait for that to pass | |
| 16:30:38 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Always enable USB controller on PPC64 https://review.opendev.org/c/openstack/nova/+/773728 | |
| 16:30:38 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Stub out 'nova.virt.libvirt.utils.get_arch' https://review.opendev.org/c/openstack/nova/+/773727 | |
| 16:31:25 | stephenfin | sean-k-mooney: need to see if that passes third party CI but that should fix the PPC64 gate issue ^ | |
| 16:31:45 | stephenfin | lyarwood: You might be interested in the first patch of those two patches also ^ | |
| 16:32:32 | stephenfin | We have a couple of places in the driver where we're checking the host architecture but we should really be checking the guest (or attempting to) | |
| 16:32:56 | stephenfin | Guess it's things like those that are preventing the emulation of architectures that CERN are after | |
| 16:32:59 | lyarwood | stephenfin: ack yeah thanks for that | |
| 16:37:21 | lyarwood | stephenfin: https://review.opendev.org/c/openstack/nova/+/769920 - any point in this if we go ahead with your change? | |
| 16:38:12 | stephenfin | I think there's still merit in it to prevent holes opening up/identify what I've missed | |
| 16:38:18 | stephenfin | Would be interesting to rebase that on top of my change | |
| 16:39:31 | sean-k-mooney | stephenfin: one thing that is a little tricky is if the host and guest arch dont mach | |
| 16:39:37 | sean-k-mooney | then we have to fall back to qemu | |
| 16:39:40 | openstackgerrit | Lee Yarwood proposed openstack/nova master: tests: Posion nova.objects.fields.Architecture.from_host https://review.opendev.org/c/openstack/nova/+/769920 | |
| 16:39:44 | sean-k-mooney | even if kvm is enabled | |
| 16:39:50 | sean-k-mooney | as the virt-type | |
| 16:40:06 | sean-k-mooney | since you cant use kvm and do emulation concurrenlty | |
| 16:40:07 | stephenfin | yes, understood. However, afaict that isn't even possible at the moment | |
| 16:40:25 | sean-k-mooney | its ment to be posiable if you use qemu as the virt-type | |
| 16:40:42 | sean-k-mooney | at least that is what we ahve said a few times in the PTG | |
| 16:40:55 | sean-k-mooney | we dotn have testing for it though and said fi emulation does not work its a bug | |
| 16:40:55 | stephenfin | Yup, but it's not. Belmiro has a couple of bugs open for it | |
| 16:41:02 | sean-k-mooney | yep | |
| 16:41:10 | stephenfin | I also saw a patch up for this recently | |
| 16:41:16 | sean-k-mooney | i think it work at some point in the distent past | |
| 16:41:25 | sean-k-mooney | as in pre placment era | |
| 17:09:57 | bauzas | sean-k-mooney: quick question, when a port is bound to an instance, which kind of allocation the port is having ? deffered, I guess ? | |
| 17:10:08 | bauzas | (when you don't create a port) | |
| 17:10:24 | bauzas | (just when asking for an instance related to a network) | |
| 17:11:41 | sean-k-mooney | am | |
| 17:11:57 | sean-k-mooney | the ip allocation policy wont change | |
| 17:12:15 | sean-k-mooney | ip_allocation=deferened means the ip is assigined when its bound to a host | |
| 17:12:20 | sean-k-mooney | if that binding succeds | |
| 17:12:41 | sean-k-mooney | so if it had deffered perviously it willl still be deffered if i understand correctly | |
| 17:12:56 | bauzas | ok, so the ip_allocation should be "deferred" but it will have fixed_ips | |
| 17:13:00 | sean-k-mooney | it just wont cahnge ip again in the future once its initally assigned on | |
| 17:13:15 | sean-k-mooney | yep it should get a fix ip at binding time | |
| 17:13:27 | bauzas | while when passing a deferred port for an instance, the fixed_ips value should be emptu | |
| 17:13:30 | bauzas | empyu | |
| 17:13:37 | bauzas | empty* | |
| 17:15:54 | sean-k-mooney | no | |
| 17:16:14 | sean-k-mooney | if its not a deffered ip_allocation policy then it default to immeidate | |
| 17:16:25 | sean-k-mooney | meaning it will get the fixed ip when the port is created | |
| 17:16:58 | sean-k-mooney | bauzas: we currently dont allow port to not have a fixed ip unless its defereed | |
| 17:17:06 | sean-k-mooney | in which case it will eventually have a fixed ip | |
| 17:17:21 | sean-k-mooney | as such it should always have a fixed ip after binding | |
| 17:17:44 | sean-k-mooney | oh sorry miss read that | |
| 17:17:49 | sean-k-mooney | yes on the nova command line | |
| 17:18:00 | bauzas | yeah ok | |
| 17:18:03 | sean-k-mooney | when passing a deferred port its fix-ip should be empty | |
| 17:18:40 | openstackgerrit | Stephen Finucane proposed openstack/nova master: cmd: Remove 'nova-manage db ironic_flavor_migration' https://review.opendev.org/c/openstack/nova/+/773776 | |
| 17:18:40 | openstackgerrit | Stephen Finucane proposed openstack/nova master: cmd: Remove 'nova-manage db null_instance_uuid_scan' https://review.opendev.org/c/openstack/nova/+/773775 | |
| 17:18:59 | sean-k-mooney | i mean it technically could be set but we would treat that the same as ip_allocation=imidieate or a live migration | |
| 17:19:24 | sean-k-mooney | e.g. the prence of an ip means we have to restrict the hots to the aggreate corresponidnng to the subnet/segment | |
| 17:27:07 | stephenfin | gmann: I'm +2 on everything I can +2 in the placement RBAC series. You should have +2 rights too now so if you've time this week your attention would be appreciated :) | |
| 17:29:31 | stephenfin | lyarwood: fwiw, there are still OpenStack Release Bot patches to be merged in placement. Could you take a look? https://review.opendev.org/q/project:openstack/placement+is:open+NOT+branch:master | |
| 17:37:48 | sean-k-mooney | stephenfin: removing those nova manage command technially might break some installer scripts if they use them | |
| 17:38:04 | sean-k-mooney | stephenfin: but they should be run via the online migration too | |
| 17:38:25 | sean-k-mooney | bauzas: amend? append? | |
| 17:38:28 | stephenfin | possibly, though that's why they're mentioned in the release notes | |
| 17:38:45 | sean-k-mooney | stephenfin: do we need to go through a deprecation cycle | |
| 17:38:51 | sean-k-mooney | havent opened the patch yet | |
| 17:39:03 | bauzas | sean-k-mooney: context is https://review.opendev.org/c/openstack/nova/+/749068/6/nova/tests/fixtures.py#2114 | |
| 17:39:05 | stephenfin | I don't think so. Not for those. They're usless now | |
| 17:39:08 | stephenfin | *useless | |
| 17:39:20 | bauzas | we can't blindly provide a port without knowing which segment was used | |
| 17:39:39 | sean-k-mooney | bauzas: we can | |