| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-02-21 | |||
| 12:02:51 | sean-k-mooney | am well the compute node would not have the new values if it was not updated | |
| 12:03:11 | sean-k-mooney | and an instance object with the new values shoudl not be sendable to the compute node | |
| 12:03:24 | gibi | there is code path in live migration where an old compute loads the new compute from the DB | |
| 12:03:49 | sean-k-mooney | oh | |
| 12:04:00 | sean-k-mooney | thats a nasty edgecase | |
| 12:04:05 | gibi | grenade caught it | |
| 12:04:39 | sean-k-mooney | right ok so the list object would have to strip the new version instead of raise | |
| 12:04:44 | gibi | yes | |
| 12:04:51 | gibi | but it is really hard to do that with OVO | |
| 12:05:02 | gibi | (see the patch with a ton of comments) | |
| 12:05:10 | sean-k-mooney | i dont think we have had to do that in the past | |
| 12:05:19 | sean-k-mooney | at least i cant think of a case where this has come up | |
| 12:05:30 | gibi | my alternative proposal is not to publish HVSpec objects with new arch values until a min service version check is passed | |
| 12:05:43 | sean-k-mooney | most of the enums we have extended in the past have been only in teh instance object | |
| 12:06:01 | sean-k-mooney | ok ya that would work | |
| 12:06:16 | sean-k-mooney | we often dont enable feature until the cloud is fully upgraded | |
| 12:06:52 | sean-k-mooney | this woudl cause all the compute nodes to update the comptue node table once they are all upgraded | |
| 12:06:54 | gibi | I pulled dansmith into the discussion maybe he sees an easy fix in the OVO support for this case but if not then I will suggest chateaulav to add a service version check instead | |
| 12:07:08 | sean-k-mooney | well maybe not | |
| 12:07:30 | sean-k-mooney | we are extendign the values but that does not mean the compute node would use one of the new values | |
| 12:07:45 | gibi | today it uses in the gate | |
| 12:07:57 | gibi | I haven't checked it what enables all the new arch | |
| 12:08:15 | sean-k-mooney | its likely just the presence fo the qemu binary | |
| 12:08:30 | sean-k-mooney | on ubuntu it installs all of them by default | |
| 12:08:57 | sean-k-mooney | how is this reported in the compute node db recored by the way | |
| 12:09:18 | sean-k-mooney | ah supported_hv_specs | |
| 12:09:30 | gibi | yes, that one | |
| 12:10:21 | sean-k-mooney | i guess we dont wnat to defien that as the host native arch | |
| 12:10:32 | sean-k-mooney | since that would not really help if we had native hosts using one of the new options | |
| 12:10:57 | gibi | it seems the new arch coming from the host cababilities via libvirt | |
| 12:11:05 | sean-k-mooney | yes | |
| 12:11:21 | sean-k-mooney | those are dynmic based on which qemu binaries libvirt finds | |
| 12:11:25 | gibi | ahh I see | |
| 12:11:33 | gibi | the you are right about the binaries | |
| 12:12:37 | sean-k-mooney | technically its dynmaic based on which libvirt virt plugin too e.g. if you install the lxc or openvz plugins they also extend it but in this case its the presence of the riscv emulators | |
| 12:13:15 | sean-k-mooney | ignoring this for a miniute how close do you think the emulation work is for this cycle | |
| 12:13:29 | sean-k-mooney | i think the previous impression i heard was likely not this cycle | |
| 12:13:58 | sean-k-mooney | i am debating if defering the ricsv support woudl help or not | |
| 12:14:18 | sean-k-mooney | that woudl allow use to punt this enum change to next cycle | |
| 12:16:35 | sean-k-mooney | so basically im suggesting that perhaps its better for chateaulav to focus on the arm and mips supprot this cycle and we can adress teh riscv supprot next cycel btu if we dont think the code is likely to land before thruday which i gusse is unlikely it proably is not worth spliting it out | |
| 12:25:00 | gibi | sean-k-mooney: good point. I think the series is in an OK shape overall | |
| 12:25:21 | gibi | so if we could remove the OVO backport pain by not adding risc then we can land it this week I believe | |
| 12:26:22 | gibi | bauzas, melwitt: there is a gate bug on nova that is a duplicate of a gate bug in neutron https://bugs.launchpad.net/nova/+bug/1959349 https://bugs.launchpad.net/neutron/+bug/1940425 but if I mark the newer bug as duplicate then we loose the tracking of it | |
| 12:26:51 | gibi | bauzas, melwitt: is it OK if I mark it duplicate and then add nova as affected to the eariler neutron bug? | |
| 12:27:06 | sean-k-mooney | gibi: riscv was not orgianlly on there list i suggeted it be added since i tought that would be one of the more useful targets | |
| 12:27:20 | gibi | sean-k-mooney: OK, then I think it make sense to split it out | |
| 12:27:21 | sean-k-mooney | gibi: so defering that i dont think woudl compropise there usecase | |
| 12:27:30 | gibi | OK | |
| 12:28:00 | gibi | chateaulav: ^^ I know that it is again a change in direction but could you remove the riscv support from the series. that way we can avoid the ovo backport pain | |
| 12:28:05 | sean-k-mooney | chateaulav: ^ at the end fo the day the descion is yours | |
| 12:28:12 | gibi | sean-k-mooney: +1 | |
| 12:35:52 | chateaulav | Lol. Yeah I think that will be better overall gibi, I agree with sean-k-mooney that I can look at doing that for next cycle. It seems as though there are also some things in the work for the riscv firmware community that may be needed. Overall initial support will be arm, s390x, ppc, and potentially mips if I can solve the pci issue. So not bad, if you ask me, for initial release of emulation | |
| 12:36:18 | gibi | chateaulav: cool | |
| 12:36:52 | gibi | sean-k-mooney: filed the bug for the pci.utils networking.neutron coupling issue https://bugs.launchpad.net/nova/+bug/1961587 | |
| 12:59:47 | sean-k-mooney | ack just triaged it | |
| 13:43:45 | gibi | thanks | |
| 14:22:06 | opendevreview | Alexey Stupnikov proposed openstack/nova master: Add functional tests to reproduce bug #1960412 https://review.opendev.org/c/openstack/nova/+/830010 | |
| 14:25:12 | opendevreview | Alexey Stupnikov proposed openstack/nova master: Add functional tests to reproduce bug #1960412 https://review.opendev.org/c/openstack/nova/+/830010 | |
| 14:38:27 | sean-k-mooney | gibi: have i mentioned how much i hate the fact that gerrit forward ports comments now | |
| 14:38:37 | sean-k-mooney | its such a ux regressions | |
| 14:38:59 | gibi | it is only a problem iff we forget to close the comments when they are solved | |
| 14:39:18 | sean-k-mooney | liek these ones https://review.opendev.org/c/openstack/nova/+/821606/10/nova/virt/libvirt/volume/lightos.py | |
| 14:39:35 | sean-k-mooney | gibi: also this has been retoactivly enabeld for all reviews in the past | |
| 14:39:51 | gibi | yeah, that retroactive thing is a pain I agree | |
| 14:40:03 | sean-k-mooney | so if we lookup a revew becasue we are lookign at git blame we will now get all the unresoved ones where the feature did not exist | |
| 14:41:04 | sean-k-mooney | im going to ack most of the commend on that once i check them but to me this breaks the workflow since if the converation is happenign betwen reviewrs rather then just the revier and authour | |
| 14:44:17 | gibi | yeah | |
| 14:44:44 | gibi | not optimal but in the other hand it helps when people only fix a set of comments and forget the rest | |
| 14:44:49 | gibi | and push a new PS | |
| 14:45:16 | sean-k-mooney | yes and know. it can but over all i think this is a more harmful change then good | |
| 14:45:41 | gibi | It forces me to close comment when they fixed or answered | |
| 14:45:50 | gibi | I think in time we can learn to use it well | |
| 14:45:54 | sean-k-mooney | right but i dont think you should have to do that | |
| 14:46:10 | sean-k-mooney | i am hoping we will get the option to disable it personlly | |
| 14:46:48 | sean-k-mooney | its the frist time that gerrit has made a change that has made me consider if we shoudl continue to use gerrit longterm | |
| 14:47:14 | sean-k-mooney | to me the fact that comments were pined to reveriosn was one of the big benifits for using gerrit | |
| 14:47:17 | sean-k-mooney | this regresses that | |
| 14:48:00 | sean-k-mooney | i can see the beniftis too but to me in its current form the beiftis do not outway the downside | |
| 14:48:21 | gibi | hm, maybe a toggle in the UX to show / hide the old PS comments can be a compromise | |
| 14:48:32 | opendevreview | yuval proposed openstack/nova master: Lightbits LightOS driver https://review.opendev.org/c/openstack/nova/+/821606 | |
| 14:48:38 | sean-k-mooney | if it only forward ported the comment that refered to lines that were modified in the next revision i could proably live with that | |
| 14:49:35 | yuval_ | gibi sean-k-mooney thanks for the fast reply! | |
| 14:49:41 | sean-k-mooney | like its infurating that i have to load back up ps 8 to see why they refer too | |
| 14:50:53 | gibi | yuval_: will check the last version before end of my day | |
| 14:52:16 | yuval_ | thanks, I just updated as sean-k-mooney suggested the req file and lower constraints | |
| 14:52:23 | yuval_ | to see zuul pass | |
| 14:52:47 | yuval_ | I am now re-adding the lightbits ci to work on nova repo | |
| 14:53:00 | sean-k-mooney | yuval_: https://review.opendev.org/c/openstack/nova/+/821606/11/nova/virt/libvirt/volume/lightos.py#31 can you respond to this too | |
| 14:53:40 | yuval_ | yes, no problem | |
| 14:53:45 | dmitriis | sean-k-mooney, gibi: w.r.t. the above ping, I can chime in to help with reviews | |
| 14:54:14 | gibi | dmitriis: thanks | |
| 14:55:08 | gibi | dmitriis, sean-k-mooney: w.r.t. the sysfs pci_utils network.neutron coupling, I started looking into the refactor and I have to say that the whole resource tracker is infected with teh sysfs coupling via the pci device tracker | |
| 14:55:52 | sean-k-mooney | gibi: yes that is not surpriseing to be honest | |
| 14:56:08 | gibi | so this sean-k-mooney but then we are back to that the compute manager depends on sysfs | |
| 14:56:16 | sean-k-mooney | everything pci related is only supproted on linux today | |
| 14:56:47 | gibi | which is an acceptable limitation but the external depenency (sysfs) is not abstracted out | |
| 14:56:58 | gibi | and heavily tangled in | |
| 14:57:10 | sean-k-mooney | yes it is | |
| 14:57:31 | gibi | so I think today it would be extremely hard to add support to PCI for a non Linux host | |
| 14:57:45 | sean-k-mooney | it could certenly be factored more but i guess the expecation is you woudl add windows suport to the pci module if that ever came to be a thing | |