| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-11-15 | |||
| 11:38:56 | bauzas | gibi: I'll ping you later in the afternoon once I upload a new rev | |
| 11:39:04 | bauzas | should be an easy small spec | |
| 11:39:26 | gibi | bauzas: ack | |
| 13:23:20 | opendevreview | Merged openstack/nova-specs master: Robustify Compute Node Hostnames backlog spec https://review.opendev.org/c/openstack/nova-specs/+/853837 | |
| 13:28:50 | opendevreview | Sylvain Bauza proposed openstack/nova-specs master: Proposes cpu power managment in libvirt https://review.opendev.org/c/openstack/nova-specs/+/861591 | |
| 13:29:06 | bauzas | sean-k-mooney: gibi: just made modifications to the CPU mangement spec ^ | |
| 13:35:30 | sean-k-mooney | ack it will proably be an hour or so before i get to it | |
| 13:38:58 | JohnnyW | and 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:58 | JohnnyW | instance 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 keys | |
| 13:38:58 | JohnnyW | Hello, 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 another | |
| 13:40:03 | sean-k-mooney | JohnnyW: do you onw the key and volume | |
| 13:40:40 | sean-k-mooney | if 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 vm | |
| 13:41:19 | sean-k-mooney | encypted volume encyption keys are onwed by the user that created it not the project | |
| 13:41:29 | sean-k-mooney | as is the case with all secrets stored in barbican | |
| 13:41:48 | JohnnyW | sure, I'm owner of both keys | |
| 13:42:07 | JohnnyW | that is why this behavior looks strange for me | |
| 13:42:14 | sean-k-mooney | ok then in that case im not really sure | |
| 13:42:23 | sean-k-mooney | its the same version fo nova/libvirt right | |
| 13:42:35 | sean-k-mooney | just one was created before the upgrade and the other after | |
| 13:43:36 | JohnnyW | nova/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 itself | |
| 13:44:59 | sean-k-mooney | ya 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 attach | |
| 13:45:17 | sean-k-mooney | i.e. a bug that affected volumes created in teh older relase that nolonger happens in the later release | |
| 13:45:22 | JohnnyW | openstack 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 visible | |
| 13:45:30 | sean-k-mooney | have you compare the metadtaa on the volume or attachment info | |
| 13:46:39 | JohnnyW | hmm...let me try to compare metadata or attachment info, maybe that is a good hint, I haven't tried to compare it yet | |
| 13:55:50 | opendevreview | Merged openstack/nova-specs master: Clarify client changes in rebuild spec https://review.opendev.org/c/openstack/nova-specs/+/856164 | |
| 14:07:19 | JohnnyW | sean-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:27:41 | sean-k-mooney | ya 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 cause | |
| 15:27:46 | sean-k-mooney | JohnnyW: 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 attention | |
| 15:32:00 | bauzas | reminder: nova meeting in ~30 mins | |
| 15:47:15 | JohnnyW | sean-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 there | |
| 16:00:19 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:00:19 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:00:19 | opendevmeet | Meeting 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:19 | bauzas | #startmeeting nova | |
| 16:00:33 | bauzas | howdy everyone | |
| 16:00:45 | dansmith | o/ (but multitasking) | |
| 16:00:52 | elodilles | o/ | |
| 16:00:57 | Uggla | o/ | |
| 16:00:58 | bauzas | dansmith: ditto | |
| 16:01:03 | gmann | o/ | |
| 16:01:03 | bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | |
| 16:01:07 | gibi | o/ | |
| 16:01:12 | sean-k-mooney | o/ | |
| 16:01:12 | bauzas | let's try to have a quick meeting | |
| 16:01:14 | Kirill_ | 0/ | |
| 16:01:24 | bauzas | #topic Bugs (stuck/critical) | |
| 16:01:29 | bauzas | #info No Critical bug | |
| 16:01:34 | bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 7 new untriaged bugs (+2 since the last meeting) | |
| 16:01:40 | bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | |
| 16:01:56 | bauzas | melwitt: I've seen you triaging bugs, anything in particular you wanted to discuss ? | |
| 16:03:20 | bauzas | looks not, moving on | |
| 16:03:31 | bauzas | Uggla: happy with getting the baton this week ? | |
| 16:03:39 | Uggla | bauzas, ok | |
| 16:03:41 | bauzas | artom is on some PTO until dec | |
| 16:03:45 | bauzas | cool | |
| 16:03:51 | bauzas | #info bug baton is being passed to Uggla | |
| 16:03:55 | bauzas | moving on | |
| 16:04:00 | bauzas | #topic Gate status | |
| 16:04:06 | bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | |
| 16:04:11 | bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | |
| 16:04:22 | bauzas | we had a terrible week | |
| 16:04:37 | bauzas | yellows and reds everywhere | |
| 16:04:48 | gibi | I think it was a global CI outage | |
| 16:04:50 | gibi | at some point | |
| 16:04:55 | bauzas | yup | |
| 16:05:25 | bauzas | since all the runs happened on the same timeframe, this would explain | |
| 16:05:56 | bauzas | we shall check the statuses next week | |
| 16:06:15 | bauzas | agreed ? | |
| 16:06:56 | 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 go | |
| 16:07:12 | bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | |
| 16:07:20 | gibi | sure | |
| 16:07:23 | bauzas | #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures | |
| 16:07:28 | bauzas | #topic Release Planning | |
| 16:07:34 | bauzas | #link https://releases.openstack.org/antelope/schedule.html | |
| 16:07:39 | bauzas | #link https://releases.openstack.org/antelope/schedule.html | |
| 16:07:49 | bauzas | dang | |
| 16:07:54 | bauzas | #info Antelope-1 is planned in 2 days | |
| 16:07:56 | bauzas | #info Antelope-1 is planned in 2 days | |
| 16:08:03 | bauzas | #info Today is a spec review day | |
| 16:08:05 | bauzas | voilà | |
| 16:08:16 | bauzas | currently we're all busy at looking at some specs | |
| 16:08:40 | bauzas | so I'll tell the result of this spec day next week | |
| 16:08:49 | gibi | yepp | |
| 16:08:56 | bauzas | thanks btw. cores for taking time about ^ | |
| 16:09:03 | bauzas | moving on | |
| 16:09:08 | bauzas | #topic Review priorities | |
| 16:09:14 | 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:26 | bauzas | given today is a spec review day, I'd like to skip this check | |
| 16:09:40 | bauzas | people can ping us on IRC for reviews, surely | |
| 16:09:46 | bauzas | #info As a reminder, cores eager to review changes can +1 to indicate their interest, +2 for committing to the review | |
| 16:10:24 | bauzas | elodilles: floor is yours | |
| 16:10:24 | bauzas | #topic Stable Branches | |
| 16:10:24 | bauzas | moving on | |
| 16:10:30 | 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/862520 | |
| 16:10:35 | bauzas | \o/ | |
| 16:10:40 | elodilles | ~o~ | |
| 16:10:43 | elodilles | #info all open stable branches should be OK | |
| 16:10:52 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:11:05 | elodilles | and that's it (to be quick :)) | |