| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-23 | |||
| 09:48:06 | gibi | bauzas: the lib releases are probably proposed by the release team automatically | |
| 09:48:09 | bauzas | if so, I'll do it | |
| 09:48:20 | bauzas | gibi: yeah I'm looking at the releases gerrit | |
| 09:48:30 | bauzas | gibi: I wasn't asked to look at some changes | |
| 09:49:33 | gibi | bauzas: it seems that I only released xena-3 in launchpad not 1, 2 or rc1 | |
| 09:49:52 | bauzas | hah, OK | |
| 09:49:55 | bauzas | I'll look at that | |
| 09:50:49 | gibi | bauzas: I think the release team only proposes a release if there was real content on the branch since the last release | |
| 09:51:02 | bauzas | yeah, I only see https://review.opendev.org/c/openstack/releases/+/818415 | |
| 09:51:12 | bauzas | elodilles: ^ correct ? | |
| 09:51:28 | gibi | bauzas: we have os-vif release proposed https://review.opendev.org/c/openstack/releases/+/818415 | |
| 09:51:37 | bauzas | jinxed :p | |
| 09:51:44 | gibi | but not python-novaclient | |
| 09:52:29 | bauzas | yup | |
| 09:52:33 | gibi | os-vif had some meaningfull change since 2.6 | |
| 09:52:49 | bauzas | yes | |
| 09:52:49 | gibi | novaclient does not | |
| 09:52:54 | bauzas | correct | |
| 09:53:22 | gibi | and I thin placement's os-traits and os-resource-classes are marked as independent libs so there we don't need a release | |
| 09:53:28 | gibi | per milestone | |
| 09:53:42 | bauzas | this is correct | |
| 09:54:24 | bauzas | https://releases.openstack.org/independent.html#os-traits | |
| 09:54:33 | bauzas | https://releases.openstack.org/independent.html#os-resource-classes | |
| 09:54:40 | bauzas | they are independant | |
| 09:56:52 | gibi | what I did at m1 is to move the bps targeted to m1 to m2 | |
| 09:58:16 | gibi | but as far as see you opted not to target bps to milestones at all, so that retargeting is not needed | |
| 09:58:28 | gibi | the list https://blueprints.launchpad.net/nova/yoga seem OK | |
| 10:02:20 | elodilles | bauzas: gibi is right :) at milestone-1 only such projects had a generated release patch that had some real content in their master branch since the last release | |
| 10:17:46 | bauzas | elodilles: thanks for explaining :) | |
| 10:33:30 | elodilles | :) | |
| 11:10:00 | opendevreview | Merged openstack/nova master: db: Replace use of Executable.scalar(), Executable.execute() https://review.opendev.org/c/openstack/nova/+/804878 | |
| 11:17:39 | bauzas | lyarwood: haven't seen that https://specs.openstack.org/openstack/nova-specs/specs/yoga/approved/ephemeral-encryption-libvirt.html shares the same BP than https://specs.openstack.org/openstack/nova-specs/specs/yoga/approved/ephemeral-encryption.html | |
| 11:17:58 | bauzas | lyarwood: could you please create another BP for the libvirt one so I could mark it for yoga ? | |
| 11:18:20 | bauzas | lyarwood: also, could you please modify the spec to use the new BP ? | |
| 11:26:44 | opendevreview | Merged openstack/nova master: db: Replace use of 'autoload' parameter https://review.opendev.org/c/openstack/nova/+/805734 | |
| 11:26:53 | opendevreview | Merged openstack/nova master: db: Replace use of legacy select() calling style https://review.opendev.org/c/openstack/nova/+/805735 | |
| 11:34:03 | lyarwood | bauzas: do we need a bp per spec? It appears to graph them out correctly in the bp at least | |
| 11:35:25 | opendevreview | Merged openstack/nova master: db: Replace 'insert.inline' parameter with 'Insert.inline()' method https://review.opendev.org/c/openstack/nova/+/805736 | |
| 11:35:32 | opendevreview | Merged openstack/nova master: db: Don't pass strings to 'Connection.execute' https://review.opendev.org/c/openstack/nova/+/805737 | |
| 13:09:46 | jhartkopf | Hi there, I'd like to add another topic to the open discussion section of today's Nova meeting, but it seems to be quite full already. Would you recommend to add the topic to next week's meeting instead? And how can I add a topic to the list? Should I just edit the Wiki page? | |
| 13:14:34 | sean-k-mooney | you can just add it to the adgenda | |
| 13:14:45 | sean-k-mooney | just edit the wiki | |
| 13:14:48 | sean-k-mooney | what is the topic | |
| 13:15:50 | sean-k-mooney | lyarwood: normally yes we have a blueprint per spec, you can model the depencies between the blueprints | |
| 13:16:25 | sean-k-mooney | lyarwood: i think that works across projects too but not tried that in a while so not 100% sure | |
| 13:16:50 | sean-k-mooney | lyarwood: im pretty sure i have linke a nova blueprint to a neutron one at some point | |
| 13:22:44 | jhartkopf | sean-k-mooney: Alright, thanks. The topic is the spec for updating user data. We've already discussed it on OpenDev but I'd like to bring up some specific use cases once again. | |
| 13:23:02 | sean-k-mooney | ack | |
| 13:28:40 | opendevreview | Lee Yarwood proposed openstack/nova-specs master: fup: Correct the libvirt ephemeral encryption blueprint link https://review.opendev.org/c/openstack/nova-specs/+/818917 | |
| 13:29:07 | lyarwood | sean-k-mooney: right thanks I thought the single bp showed the spec relationship but it looks like you created another bp previously | |
| 13:29:32 | lyarwood | updated the spec to point to that second bp, iirc gibi was cool with one bp previously but I really don't mind either way | |
| 13:30:06 | sean-k-mooney | ya im fine with both where it was useful in the past was vhost-user | |
| 13:30:23 | sean-k-mooney | we had one blueprint for generic vhost-user support and a second for vhost-user with ovs-dpdk | |
| 13:30:57 | sean-k-mooney | we happend to enable both in the same release but if the ovs-dpdk supprot had slipped we could have closed the generic one and move the ovs one | |
| 13:31:17 | sean-k-mooney | we rarely have 2 feature that share a common part like that | |
| 13:31:37 | sean-k-mooney | at least rarely in the same cycle | |
| 13:34:05 | sean-k-mooney | lyarwood: actully one minor reason to have 2 bluepritns is the script we use to mark specs as implemented and move them uses the script file name to determin which blueprint to query | |
| 13:34:22 | sean-k-mooney | lyarwood: i thinkthat is why i originally created the second libvirt one | |
| 13:37:07 | EugenMayer | is it a known issue that ubuntu (20.04) does not accept the DNS server pushed by DHCP openstack (OVN)? Debian generic cloud image does work though | |
| 13:38:37 | sean-k-mooney | EugenMayer: thats odd i would have expected that to work | |
| 13:39:00 | sean-k-mooney | you set the nameservers on the subnet as normal | |
| 13:39:11 | EugenMayer | Same does me. Spinnging up a debian box right now, expecting it to work (since all the debian boxes worked) | |
| 13:39:14 | sean-k-mooney | and it just does not pic those up via dhcp? | |
| 13:39:16 | EugenMayer | yes i do | |
| 13:39:29 | EugenMayer | it ignores it on ubuntu, exactly | |
| 13:39:39 | sean-k-mooney | ya that sound like a dhcpclint bug in ubuntu 20.04 | |
| 13:40:07 | sean-k-mooney | i assume they are both useing the came dhcp clinet implemenation by default | |
| 13:40:13 | EugenMayer | yes debian works. Same network same everything (using terraform here, so just replaced the image) | |
| 13:41:00 | sean-k-mooney | perhap its fixed in a later cloud image? im not sure if you are using the latest point release image of 20.04 but might be worth trying the nightly image | |
| 13:41:09 | EugenMayer | using the latest one | |
| 13:41:13 | EugenMayer | not older then 5 days | |
| 13:41:24 | EugenMayer | did you find a bug reeport? | |
| 13:41:37 | sean-k-mooney | no have not look | |
| 13:42:03 | EugenMayer | i look it up and try > 20.xx | |
| 13:42:10 | sean-k-mooney | it used to work i think but that the only thing i can think of is a bug in the dhcpclient or the cloud-init default behavior in ubuntu | |
| 13:42:26 | EugenMayer | maybe it is netplan related | |
| 13:43:37 | EugenMayer | i use what is referenced at Same does me. Spinnging up a debian box right now, expecting it to work about | |
| 13:43:40 | EugenMayer | sorry | |
| 13:43:45 | EugenMayer | here https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/configure-openstack.html#set-up-public-networking | |
| 13:49:46 | EugenMayer | interesting, resolvectl status shows up the right dns serevers... but the resolution of my internal domains does not work | |
| 13:49:57 | EugenMayer | i have to use 'dig @IP domain' | |
| 13:56:30 | bauzas | lyarwood: oh, sorry, I haven't seen https://blueprints.launchpad.net/nova/+spec/ephemeral-encryption-libvirt | |
| 13:56:41 | bauzas | lyarwood: then we need to update the spec to tell that the BP is ^ | |
| 13:56:51 | bauzas | lyarwood: I mean, in https://specs.openstack.org/openstack/nova-specs/specs/yoga/approved/ephemeral-encryption-libvirt.html | |
| 13:57:32 | lyarwood | bauzas: yeah there's a fup above for that now | |
| 13:59:30 | lyarwood | https://review.opendev.org/c/openstack/nova-specs/+/818917 sorry | |
| 14:03:15 | EugenMayer | sean-k-mooney ok i found it. Damn i confused the isolated test. I had a typo in my CNAME thus the isolated test with a blank 20.04 box failed and i assumed a general issues. Now vanilla focal works. just focal + rke2 has the wrong DNS servers, which might be an RKE2 setup thing. Sorry for wasting time, got dragged away, missed that typo | |
| 14:04:01 | sean-k-mooney | EugenMayer: no worries | |
| 14:19:40 | opendevreview | Merged openstack/nova-specs master: fup: Correct the libvirt ephemeral encryption blueprint link https://review.opendev.org/c/openstack/nova-specs/+/818917 | |
| 14:33:11 | bauzas | eeeeek https://github.com/libvirt/libvirt/commit/3bd8181bc5548a0ce81107cbfb480dfdcba5679d | |
| 14:33:17 | bauzas | sean-k-mooney ^ | |
| 14:34:13 | mnaser | gibi: yeah i saw your comments and found that issue, it seems like even with retry=0, it still is kinda failing | |
| 14:34:20 | mnaser | since it gets stuck in a reconnecting loop | |
| 14:34:27 | bauzas | sean-k-mooney: context is https://bugs.launchpad.net/nova/+bug/1951656 | |
| 14:34:51 | gibi | mnaser: yepp the retry config is only used to message sending but not connection setup | |
| 14:35:16 | mnaser | that's where i ended up and it felt pretty non-trivial at that point to go from there :( | |
| 14:35:34 | mnaser | at least, it's beyond my scope of comfortable knowledge anyways | |
| 14:35:38 | gibi | mnaser: it seems the current oslo.messaging driver interface does not have way to express that the consumer wants configurable retry for conenction setup | |
| 14:36:03 | sean-k-mooney | bauzas: we proably shoudl jsut not use libvirt for mdevs at all honestly but fun | |
| 14:36:09 | gibi | mnaser: I'm still digging oslo.messaging to understand more how to fit this in | |