Earlier  
Posted Nick Remark
#openstack-nova - 2021-11-22
20:21:12 sean-k-mooney well it should not but that might just mean that -1 for retry is not a vaild value
20:21:34 sean-k-mooney -1 presumable mean you must keep every notificaiotn in memory
20:21:37 sean-k-mooney untill its sent
20:22:41 sean-k-mooney with a copertive threading model like evently if you have enough notificiton eventlet pendign that will eventurally degrade the performance of the service
20:23:38 mnaser yeah im trying to repro right now
21:21:22 opendevreview Stanislav Dmitriev proposed openstack/nova master: Retry image download if it's corrupted https://review.opendev.org/c/openstack/nova/+/818503
22:06:47 opendevreview Dmitrii Shcherbakov proposed openstack/nova master: [yoga] Add PCI VPD Capability Handling https://review.opendev.org/c/openstack/nova/+/808199
22:06:48 opendevreview Dmitrii Shcherbakov proposed openstack/nova master: [yoga] Support remote-managed SmartNIC DPU ports https://review.opendev.org/c/openstack/nova/+/812111
#openstack-nova - 2021-11-23
04:02:58 mnaser sean-k-mooney: https://bugs.launchpad.net/nova/+bug/1917645?comments=all there's literally no way to workaround this issue, if that rabbitmq is down, the whole clouds melts down, even with retry=0
08:49:10 opendevreview Nicolas Parquet proposed openstack/nova master: Add v2.91 microversion, allowing @ and dot (.) characters in keypair name https://review.opendev.org/c/openstack/nova/+/781076
09:04:44 opendevreview Nicolas Parquet proposed openstack/nova master: Add v2.91 microversion, allowing @ and dot (.) characters in keypair name https://review.opendev.org/c/openstack/nova/+/781076
09:14:41 gibi mnaser: hi, about notification blocking the main thread, there is a bug from belmiro https://bugs.launchpad.net/nova/+bug/1917645
09:15:18 gibi I intended to look into at some point, but never had the time
09:17:01 gibi now I feel again I should look
09:46:12 gibi stephenfin: I have a bad feeling about https://review.opendev.org/c/openstack/nova/+/817746/comment/6690000b_3989ece7/ but if there is no better way then I will +A it
09:46:41 bauzas gibi: looking at https://docs.openstack.org/nova/latest/contributor/ptl-guide.html#milestone-1
09:46:50 bauzas gibi: wondering if all this fish is still needed ?
09:47:48 gibi bauzas: launchpad bookkeeping is really just bookkeeping. If you don't do it then nothing will fail
09:48:04 bauzas gibi: you did this for Xena ?
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 gibi novaclient does not
09:52:49 bauzas yes
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'

Earlier   Later