Tuesday, 2022-11-15

opendevreviewJorhson Deng proposed openstack/nova master: Remove the redundance code in HostState.update  https://review.opendev.org/c/openstack/nova/+/86427502:18
*** slaweq_ is now known as slaweq07:57
bauzashappy Specs review day, folks08:24
gibio/08:37
gibione done https://review.opendev.org/c/openstack/nova-specs/+/855514 many to go09:45
gibisean-k-mooney: do we need https://review.opendev.org/c/openstack/nova-specs/+/850352 or https://review.opendev.org/c/openstack/nova-specs/+/862626 will cover this as well?09:55
sean-k-mooney[m]oh i can abandon that the new spec will cover it. i need to adress the capitalisation and spelling nits from dan09:58
sean-k-mooney[m]but ill be doning that shortly09:58
gibisean-k-mooney: cool, then lets abadon the old one09:58
sean-k-mooney[m]done09:59
gibithanks!10:03
gibione more done https://review.opendev.org/c/openstack/nova-specs/+/861033 for me it does not make sense but I maybe missing something10:04
bauzasfwiw, I'm fast-approving already-approved specs that were in Zed10:07
gibibauzas: ack, go for it10:07
bauzasjust checking if the file was modified10:07
gibiexcept maybe with https://review.opendev.org/c/openstack/nova-specs/+/863884 where we need to check that is in sync with the new direction10:08
bauzasgibi: correct, I just approved Uggla's spec, that's it10:10
gibibauzas: OK10:10
bauzasgibi: I was litterally diffing on my laptop the userdata one :)10:10
bauzasand I see the new direction10:10
gibicool. I will get to it eventually too10:10
bauzasI'll leave my comments now10:14
bauzasI'm torn10:14
opendevreviewMerged openstack/nova-specs master: Re-propose "Allow Manila shares to be directly attached to an instance when using libvirt"  https://review.opendev.org/c/openstack/nova-specs/+/86420610:15
bauzasgibi: if you're interested, that's my thoughts on the userdata things https://review.opendev.org/c/openstack/nova-specs/+/86388410:28
gibiI will check10:28
bauzastl;dr: I'd rather not want to have something specifically written while we already have os-instance-actions API10:29
* gibi like the spec review day. Good to have the dedicated time to focus 10:29
bauzasindeed10:30
bauzasbut I also need to update my CPU spec :)10:30
* bauzas will miss the gym today, too many things to do10:31
opendevreviewKirill proposed openstack/nova-specs master: new spec: support of vnc console for ironic  https://review.opendev.org/c/openstack/nova-specs/+/86377310:52
opendevreviewsean mooney proposed openstack/nova-specs master: add spec for fqdn in hostname  https://review.opendev.org/c/openstack/nova-specs/+/86262611:06
sean-k-mooney[m]gibi sorry was reworking the fqdn spec. ill take a look at he max physical adress spec. qemu does allow you to change the adress space that is virutalised. i have not read the spec but you can have a requirement to reduce that or increase that depending on  some factors. the adress space of the vm cannot exceed the hardware its on so somethime you need to reduce it to allow kvm to work such as on an m1 macbookair.  qemu does not11:11
sean-k-mooney[m]default to the full adress space of the host either in some cpu models so you might need to increase it to create really large vms.11:11
gibisean-k-mooney[m]: the spec only ask for increasing the address space but as far as I understand that can be done by simply change the default to be as big as the host cpu 11:12
sean-k-mooney[m]i assume there use case is one of those. very big vm where the default is too low or restriced hardware where the default is two high. i feel like this is one case where a host option might work or image property. if we were to do it.11:12
sean-k-mooney[m]can you change teh default in libvirt already?11:12
sean-k-mooney[m]if so then we can just document that11:12
sean-k-mooney[m]im going to step away for 5 mins and get coffee and then ill be back soon to review it.11:13
gibithe libvirt doc suggested having a default so I assumed that it is a configurable default11:14
gibianyhow if the default is not configurable today then I still would like to have that configurable in libvirt instead of exposing yet another really low level HW knob in nova11:14
opendevreviewKirill proposed openstack/nova-specs master: new spec: support of vnc console for ironic  https://review.opendev.org/c/openstack/nova-specs/+/86377311:22
opendevreviewKirill proposed openstack/nova-specs master: new spec: support of vnc console for ironic  https://review.opendev.org/c/openstack/nova-specs/+/86377311:26
bauzasgibi: yeah, I need to update the CPU spec, I didn't had time until noon https://review.opendev.org/c/openstack/nova-specs/+/86159111:38
bauzasgibi: I'll ping you later in the afternoon once I upload a new rev11:38
bauzasshould be an easy small spec11:39
gibibauzas: ack11:39
opendevreviewMerged openstack/nova-specs master: Robustify Compute Node Hostnames backlog spec  https://review.opendev.org/c/openstack/nova-specs/+/85383713:23
opendevreviewSylvain Bauza proposed openstack/nova-specs master: Proposes cpu power managment in libvirt  https://review.opendev.org/c/openstack/nova-specs/+/86159113:28
bauzassean-k-mooney: gibi: just made modifications to the CPU mangement spec ^13:29
sean-k-mooneyack it will proably be an hour or so before i get to it13:35
JohnnyWHello, just a question about nova and barbican cooperation, maybe someone faced such issue already. I have two volumes encrypted, one is using a key which was created before an upgrade of barbican from ussuri version to yoga version, so far both are OK, but if I detach volume which is using ussuri key, then I cannot attach that volume to another13:38
JohnnyWinstance with information in nova logs: "libvirt.libvirtError: internal error: unable to execute QEMU command 'blockdev-add': Invalid password, cannot unlock any keyslot", but if I do the same operation with a volume which is using yoga key, then everything is fine. So far I checked that I'm able to retrieve secret payload from ussuri and yoga keys13:38
JohnnyWand everything looks fine, there is no error logs in barbican. So I'm wondering what can be an issue here, any ideas? Thanks in advance for suggestions! 13:38
sean-k-mooneyJohnnyW: do you onw the key and volume13:40
sean-k-mooneyif you are not the user that created teh encyped volume then the key in barbican will be owned by the orginal user and you will not be able to attach it to another vm13:40
sean-k-mooneyencypted volume encyption keys are onwed by the user that created it not the project13:41
sean-k-mooneyas is the case with all secrets stored in barbican13:41
JohnnyWsure, I'm owner of both keys13:41
JohnnyWthat is why this behavior looks strange for me13:42
sean-k-mooneyok then in that case im not really sure13:42
sean-k-mooneyits the same version fo nova/libvirt right13:42
sean-k-mooneyjust one was created before the upgrade and the other after13:42
JohnnyWnova/libvirt are exactly the same, only barbican version changed in between...and vault as a backend and SoftHSM for keys was upgraded, but only OS not version of vault itself13:43
sean-k-mooneyya thats odd. i wonder if tehere was a bug fix wehre we did nto store some metadata or similar that we require to be able to do the attach13:44
sean-k-mooneyi.e. a bug that affected volumes created in teh older relase that nolonger happens in the later release13:45
JohnnyWopenstack secret get ... are able to return all payload, for "new" and "old" secret, so that's why it looks strange. Only nova seems to have an issue with reading keys, let say old volumes which are already mounted and old are OK right now, but after reattachment I'm sure that problem with old keys will be visible13:45
sean-k-mooneyhave you compare the metadtaa on the volume or attachment info13:45
JohnnyWhmm...let me try to compare metadata or attachment info, maybe that is a good hint, I haven't tried to compare it yet13:46
opendevreviewMerged openstack/nova-specs master: Clarify client changes in rebuild spec  https://review.opendev.org/c/openstack/nova-specs/+/85616413:55
*** dasm|off is now known as dasm13:58
*** haleyb_ is now known as haleyb14:04
JohnnyWsean-k-mooney unfortunately or fortunately it's not up to metadata or attachment info, I already change on both sides to have similar and issue is the same. Logs from nova-compute says:  https://paste.openstack.org/show/bNbPOHiQJOq8OsKZ5Gn2/14:07
sean-k-mooneyya so i have not see that issue before so i cant really say. it would be good to file a bug for this as it likely is an upstream bug but im not sure of the cause14:27
sean-k-mooneyJohnnyW: by the way today is a spec review day so most of the cores will be focused on that so if no one else chims in bring it up tomorrow and it might get more attention15:27
bauzasreminder: nova meeting in ~30 mins15:32
JohnnyWsean-k-mooney ok, thank you very much, already posted a bug here: https://bugs.launchpad.net/nova/+bug/1996622 and hope that everything is placed there15:47
bauzas#startmeeting nova16:00
opendevmeetMeeting started Tue Nov 15 16:00:19 2022 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.16:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
opendevmeetThe meeting name has been set to 'nova'16:00
bauzashowdy everyone16:00
dansmitho/ (but multitasking)16:00
* bauzas is swamped in a mud16:00
elodilleso/16:00
Ugglao/16:00
bauzasdansmith: ditto16:00
bauzas#link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting16:01
gmanno/16:01
gibio/16:01
bauzaslet's try to have a quick meeting16:01
sean-k-mooneyo/16:01
Kirill_0/16:01
bauzas#topic Bugs (stuck/critical) 16:01
bauzas#info No Critical bug16:01
bauzas#link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 7 new untriaged bugs (+2 since the last meeting)16:01
bauzas#info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster16:01
bauzasmelwitt: I've seen you triaging bugs, anything in particular you wanted to discuss ?16:01
bauzaslooks not, moving on16:03
bauzasUggla: happy with getting the baton this week ?16:03
Ugglabauzas, ok16:03
bauzasartom is on some PTO until dec16:03
bauzascool16:03
bauzas#info bug baton is being passed to Uggla16:03
bauzasmoving on16:03
bauzas#topic Gate status 16:04
bauzas#link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs 16:04
bauzas#link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status16:04
bauzaswe had a terrible week16:04
bauzasyellows and reds everywhere16:04
gibiI think it was a global CI outage16:04
gibiat some point16:04
bauzasyup16:04
bauzassince all the runs happened on the same timeframe, this would explain16:05
bauzaswe shall check the statuses next week16:05
bauzasagreed ?16:06
bauzas#info all periodic runs turned into a bad shape this week due to some CI outage on Nov 12, we'll doublecheck next week how things go16:06
bauzas#info Please look at the gate failures and file a bug report with the gate-failure tag.16:07
gibisure16:07
bauzas#info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures16:07
bauzas#topic Release Planning 16:07
bauzas#link https://releases.openstack.org/antelope/schedule.html16:07
bauzas#link https://releases.openstack.org/antelope/schedule.html16:07
bauzasdang16:07
bauzas #info Antelope-1 is planned in 2 days16:07
bauzas#info Antelope-1 is planned in 2 days16:07
bauzas#info Today is a spec review day16:08
bauzasvoilĂ 16:08
bauzascurrently we're all busy at looking at some specs16:08
bauzasso I'll tell the result of this spec day next week 16:08
gibiyepp16:08
bauzasthanks btw. cores for taking time about ^16:08
bauzasmoving on16:09
bauzas#topic Review priorities 16:09
bauzas#link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+(label:Review-Priority%252B1+OR+label:Review-Priority%252B2)16:09
bauzasgiven today is a spec review day, I'd like to skip this check16:09
bauzaspeople can ping us on IRC for reviews, surely16:09
bauzas#info As a reminder, cores eager to review changes can +1 to indicate their interest, +2 for committing to the review16:09
bauzasmoving on16:10
bauzas#topic Stable Branches 16:10
bauzaselodilles: floor is yours16:10
elodilles#info stein, rocky and queens moved to End of Life, branches were deleted (last branch state can be found with tags: stein-eol, rocky-eol, queens-eol): https://review.opendev.org/86252016:10
bauzas\o/16:10
elodilles~o~16:10
elodilles#info all open stable branches should be OK16:10
elodilles#info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci16:10
elodillesand that's it (to be quick :))16:11
bauzasnice16:12
bauzasthanks16:12
elodillesnp16:12
bauzaslast topic with a good question16:12
bauzas#topic Open discussion 16:12
bauzas(takashi) Release python-novaclient 18.2.0 16:12
bauzas(sorry takashi, if you read the meeting notes, I don't know your IRC nick)16:12
bauzashttps://review.opendev.org/c/openstack/releases/+/86136016:12
bauzasThe nova supports microversions 2.93 in the Zed release. However  the support for microversions 2.93 has not been included in the  python-novaclient 18.1.0 (the Zed release).16:13
bauzasAdd support for microversions 2.93 in the 18.2.0.16:13
bauzasthat's it from him16:13
bauzasI'm not opposed to a .y release16:13
bauzasany concerns ?16:13
bauzasbefore I +1 the releases patch ?16:13
elodillesno concern, should be OK, especially as we are at Antelope-116:14
bauzaselodilles: yeah but we usually have a tradition to release client changes around milestone-116:14
gibi18.2.0 works for me16:15
bauzassaid +1d16:15
bauzasshould get the PTL-vote then16:15
bauzasthanks takashi for your efforts, btw.16:15
bauzasgreatly appreciated16:15
gibi^^ +116:16
bauzasI haven't looked at our libs recently16:16
bauzasmilestone-1 is maybe premature but we could release some libs updates like os-vif if that helps16:16
dvo-plvHello, All could you please review our blueprint: https://review.opendev.org/c/openstack/nova-specs/+/85929016:16
sean-k-mooneymilestone 1 already... this will be a very short cycle16:17
bauzassean-k-mooney: yup, I said it loudly in the antelope release schedule patch16:17
elodillesyepp, this is a 24 weeks long cycle16:17
bauzasdvo-plv: we're on meeting now, but be sure we'll look at all specs today as this is a day prioritized for it16:18
bauzasanyway, I guess we're done16:18
bauzaslike I said, no libraries need for release ?16:18
bauzasdisclaimer, I can check the git repos, I'm just lazy to do so16:18
elodillesi haven't checked, but were there merged patches there?16:19
bauzasthat's my question :)16:19
bauzasanyway, we're not constrained by the milestone, we can release whenever we want16:19
bauzasthat's it then for me today16:19
bauzasany other topic to address before we end the meeting ?16:19
bauzasthanks all, appreciated your presence while you all are quite busy this day16:20
bauzashave a good day and let's continue our effort16:20
bauzas#endmeeting16:20
opendevmeetMeeting ended Tue Nov 15 16:20:49 2022 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:20
opendevmeetMinutes:        https://meetings.opendev.org/meetings/nova/2022/nova.2022-11-15-16.00.html16:20
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-11-15-16.00.txt16:20
opendevmeetLog:            https://meetings.opendev.org/meetings/nova/2022/nova.2022-11-15-16.00.log.html16:20
elodillesthanks o/16:20
gibio/16:21
elodillesbauzas: the release patches were generated for Antelope-1, but I see only python-novaclient, so I guess no other lib release is needed: https://review.opendev.org/q/topic:antelope-milestone-116:21
elodillesbauzas: wrong, there's os-vif: https://review.opendev.org/c/openstack/releases/+/86452716:22
elodillessean-k-mooney: ^^^16:22
bauzasI don't think we need to tag it 3.1.016:23
bauzasper the commit msg16:23
elodilleswe need to bump at least MINOR versions between series16:24
sean-k-mooneyelodilles: before we proceed with that i just want to make sure we have landed the tox/gitreview patches16:24
elodillessean-k-mooney: ++, thanks in advance for taking care of that!16:24
sean-k-mooneyoh never mind we dont need too16:24
sean-k-mooneywe only change them on stable to aovid that16:24
elodillesthen even better :)16:24
sean-k-mooneyi saw the email come in for the release this mornign but didnt open the patch yet16:25
elodillesthe generated patches on master branch seem to be merged16:26
sean-k-mooneylooking at the oneline summery i think this makes sense and i agree a feature bump is correct16:26
elodilles++16:26
sean-k-mooneyso there was os-vif and novaclient if i rememebr correctly16:26
bauzasok, then I'll +1 it16:27
sean-k-mooneyhttps://review.opendev.org/c/openstack/releases/+/86453616:27
bauzassean-k-mooney: that's a duplicate of https://review.opendev.org/c/openstack/releases/+/86136016:28
sean-k-mooneyboth have the swap to the new testing runtime merged and not much else so i think we can release that too16:28
sean-k-mooneyyes and no16:28
sean-k-mooneythe release was being doen for different reasons16:28
sean-k-mooneybut sure we can go with the takashi's patch16:29
bauzassurely, but the result is the same even if the gerrit topics are different16:29
opendevreviewGhanshyam proposed openstack/placement master: Policy defaults improvement spec  https://review.opendev.org/c/openstack/placement/+/86438516:34
gmannbauzas: sean-k-mooney dansmith ^^ updated placement spec also for RBAC to add admin-or-service default what we discussed on IRC16:34
dansmithack16:35
bauzasack16:39
opendevreviewMerged openstack/nova-specs master: Policy service role spec  https://review.opendev.org/c/openstack/nova-specs/+/86437916:48
bauzassean-k-mooney: gibi: thanks for having commented out the CPU spec17:27
bauzaswill update it tomorrow 17:27
* bauzas has a serious headache by now17:27
sean-k-mooneycool ill take a look then17:28
gibibauzas: no worries. feel free to ping me later and I cen re-review17:28
opendevreviewGhanshyam proposed openstack/placement master: Policy defaults improvement spec  https://review.opendev.org/c/openstack/placement/+/86438517:51
gmannsean-k-mooney: ^^ updated the upgrade impact and scope_type change. 17:52
opendevreviewMerged openstack/nova-specs master: Re-propose spec for ephemeral storage encryption  https://review.opendev.org/c/openstack/nova-specs/+/86413818:37
opendevreviewMerged openstack/nova-specs master: Re-propose spec for ephemeral encryption for libvirt  https://review.opendev.org/c/openstack/nova-specs/+/86414718:38
opendevreviewDan Smith proposed openstack/nova-specs master: Add stable-compute-uuid spec  https://review.opendev.org/c/openstack/nova-specs/+/86315218:42
*** dasm is now known as dasm|off23:02
opendevreviewGhanshyam proposed openstack/nova master: Add service role in nova policy  https://review.opendev.org/c/openstack/nova/+/86459423:42

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!