| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-11-15 | |||
| 10:52:15 | opendevreview | Kirill proposed openstack/nova-specs master: new spec: support of vnc console for ironic https://review.opendev.org/c/openstack/nova-specs/+/863773 | |
| 11:06:37 | opendevreview | sean mooney proposed openstack/nova-specs master: add spec for fqdn in hostname https://review.opendev.org/c/openstack/nova-specs/+/862626 | |
| 11:11:04 | 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 not | |
| 11:11:04 | 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:12:21 | gibi | sean-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:24 | 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:44 | sean-k-mooney[m] | can you change teh default in libvirt already? | |
| 11:12:54 | sean-k-mooney[m] | if so then we can just document that | |
| 11:13:40 | 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:14:13 | gibi | the libvirt doc suggested having a default so I assumed that it is a configurable default | |
| 11:14:46 | gibi | anyhow 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 nova | |
| 11:22:13 | opendevreview | Kirill proposed openstack/nova-specs master: new spec: support of vnc console for ironic https://review.opendev.org/c/openstack/nova-specs/+/863773 | |
| 11:26:24 | opendevreview | Kirill proposed openstack/nova-specs master: new spec: support of vnc console for ironic https://review.opendev.org/c/openstack/nova-specs/+/863773 | |
| 11:38:42 | bauzas | gibi: yeah, I need to update the CPU spec, I didn't had time until noon https://review.opendev.org/c/openstack/nova-specs/+/861591 | |
| 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 | 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: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 | 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: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 | bauzas | #startmeeting nova | |
| 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 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:00:19 | opendevmeet | The meeting name has been set to '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 | bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | |
| 16:01:03 | gmann | o/ | |
| 16:01:07 | gibi | o/ | |
| 16:01:12 | bauzas | let's try to have a quick meeting | |
| 16:01:12 | sean-k-mooney | o/ | |
| 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 | |