| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-01-10 | |||
| 15:34:10 | Uggla | I'll try to explain what I have seen in the scaphandre code, scaphandre loops every 5s on all qemu processes, it extracts data from these processes (timing, cpu usage...) and exposed them in the directory/file that will be shared with the guest. To provide the correct data to guest VM, it requires to know which qemu process belongs to which vm. So we need the link VM name / process id, and today it is provided by the instance name. | |
| 15:35:05 | bauzas | from the host, you mean ? | |
| 15:35:14 | Uggla | yes | |
| 15:36:06 | Uggla | When the instance name will change ? Hard reboot ? | |
| 15:36:30 | bauzas | and then, I guess scaphandre creates a directoty in the shared mountpoint, right? | |
| 15:37:09 | Uggla | yes a directory and file containing the data from the vm name. | |
| 15:38:57 | bauzas | ok, but does it create a specific mount ? | |
| 15:39:10 | bauzas | I mean, does it create one mountpoint per instance ? | |
| 15:39:21 | bauzas | using virtiofs | |
| 15:39:25 | Uggla | yep | |
| 15:39:39 | Uggla | 1 dir + file per vm | |
| 15:39:50 | bauzas | ok, then anyway scaphandre will need to be modified | |
| 15:40:03 | bauzas | because your spec only uses one mountpoint | |
| 15:40:07 | bauzas | for all instances | |
| 15:40:22 | Uggla | 1 mp with x dir per vm name | |
| 15:40:57 | bauzas | that's what I understood | |
| 15:41:14 | Uggla | let me give an example it will be easier: | |
| 15:41:19 | bauzas | so, anyway, as you see, if scaphandre wants to supports nova, then they need to modify this | |
| 15:41:38 | bauzas | instead of creating one mountpoint per instance | |
| 15:41:55 | bauzas | they could keep an shared mountpoint between guests | |
| 15:44:57 | Uggla | the actual path on the host is /var/lib/libvirt/scaphandre/<vmname>/intel-rapl:0:0 | |
| 15:45:49 | bauzas | and I guess this whole ath is mounted thru virtiofs as a single mount point ? | |
| 15:45:55 | bauzas | whole path* | |
| 15:46:14 | bauzas | instead of mounting /var/lib/libvirt/scaphandre | |
| 15:47:07 | bauzas | (tbc, when I say 'mounting' this is wrong, I rather mean 'instead of creating a mount point for' so it would be mounted on the guest) | |
| 15:47:26 | bauzas | as a reminder, btw. nova meeting in 13 mins here | |
| 15:48:04 | Uggla | in the guest you will have a dir ex: /var/lib/scaphandre/ and inside intel-rapl:0:0 so you map /var/lib/libvirt/scaphandre/<vmname> to somewhere on the guest | |
| 15:49:39 | Uggla | but this is scaphandre that create /var/lib/libvirt/scaphandre/<vmname>/intel-rapl:0:0 on the host and vmname is coming from qemu cmdline. | |
| 15:50:46 | Uggla | bauzas, if you want we can have a quick chat after nova meeting. | |
| 15:52:34 | Uggla | bauzas, to my mind it works even if vmname change. | |
| 15:55:44 | bauzas | Uggla: who's creating the mount ? | |
| 15:56:05 | bauzas | is it automatically done by scaphandre or does the operator need to do it ? | |
| 15:56:31 | Uggla | scaphandre will create the "path" | |
| 15:56:43 | bauzas | who exposes it thru virtiosfs ? | |
| 15:57:56 | Uggla | nova | |
| 15:58:10 | bauzas | and without nova ? | |
| 15:58:29 | Uggla | user | |
| 15:58:30 | bauzas | this has to be configured ? | |
| 15:58:38 | bauzas | ok, cool enough then | |
| 15:58:45 | bauzas | so, | |
| 15:58:53 | bauzas | we have the nova meeting in a sec | |
| 15:59:01 | bauzas | but we can indeed discuss that later | |
| 15:59:07 | bauzas | because I don't think it's a problem | |
| 15:59:36 | bauzas | unless I'm wrong | |
| 16:00:08 | bauzas | anyway, there it goes | |
| 16:00:12 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:00:12 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:00:12 | opendevmeet | Meeting started Tue Jan 10 16:00:12 2023 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 16:00:12 | bauzas | #startmeeting nova | |
| 16:00:21 | bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | |
| 16:00:45 | bauzas | good UTC afternoon everyone | |
| 16:00:48 | bauzas | who's around ? | |
| 16:00:49 | dansmith | Oj | |
| 16:00:51 | gibi | o/ | |
| 16:00:53 | gmann | o/ | |
| 16:00:58 | kgube | o/ | |
| 16:01:05 | elodilles | o/ | |
| 16:01:17 | sean-k-mooney | o/ | |
| 16:01:18 | Uggla | o/ | |
| 16:01:26 | Kirill_ | o/ | |
| 16:01:29 | bauzas | welcome everyone | |
| 16:01:48 | bauzas | #topic Bugs (stuck/critical) | |
| 16:01:53 | bauzas | #info No Critical bug | |
| 16:01:57 | bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 27 new untriaged bugs (+2 since the last meeting) | |
| 16:02:02 | bauzas | I have to do my duty | |
| 16:02:27 | bauzas | if someone has time for triaging upstream bugs, that'd be lovely but I can do it | |
| 16:02:35 | bauzas | and then we'll go back to the roster | |
| 16:02:41 | bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | |
| 16:03:22 | Uggla | bauzas, bug triage, I can do it is it helps you. | |
| 16:03:27 | gibi | +1 for the roster | |
| 16:03:51 | bauzas | Uggla: I'll take the baton for this week, but if you want, we can both look at bugs | |
| 16:04:07 | bauzas | #info bug baton is being passed to bauzas | |
| 16:04:29 | bauzas | any particular urgent bug to discuss ? | |
| 16:04:40 | bauzas | I guess we'll discuss the tox saga in the next chapter | |
| 16:04:59 | bauzas | if no, let's move on and go to the gate topic | |
| 16:05:06 | bauzas | #topic Gate status | |
| 16:05:12 | bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | |
| 16:05:16 | bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | |
| 16:05:21 | bauzas | #link https://review.opendev.org/c/openstack/tempest/+/866049 proposal to add more delay for centos9s-fips job | |
| 16:05:26 | bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | |
| 16:05:30 | gibi | placement and nova gate is unblocked as far as I know. we merged the two tox4 patches | |
| 16:05:31 | bauzas | #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures | |
| 16:05:51 | bauzas | I was about to tell it once I was done with the weekly items | |
| 16:05:52 | bauzas | so, | |
| 16:06:12 | gibi | I see nova patches progressing in the gate queue | |
| 16:06:17 | gibi | so I think we are OK | |
| 16:06:33 | gibi | I haven't chacked osc-placement and python-novaclient status | |
| 16:06:40 | gibi | os-vif should be unblocked too | |
| 16:06:46 | gmann | their master gate is good, I checked | |
| 16:06:54 | gmann | but for stable branch gate, python-novaclient patches need to merge #link https://review.opendev.org/q/I442568a5f5900e593feb2b5527109e0aa79e5aa7+status:open | |
| 16:07:12 | dansmith | nice | |
| 16:07:15 | gmann | and osc-placement is failing <= stable/yoga https://review.opendev.org/c/openstack/osc-placement/+/869451 | |
| 16:07:17 | bauzas | #info we had a funky week due to tox4 but now gate is better https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031709.html | |
| 16:07:41 | gmann | it is failing on placement functionla job where we use master placement but stable branch constraints so mismatch | |
| 16:07:42 | bauzas | gmann: cool, I'll look at the novaclient patch | |
| 16:08:11 | gmann | I cannot remember why we do not use master constraints in that placement functional job? | |
| 16:08:12 | bauzas | oh, I did it already | |
| 16:08:13 | gibi | the there are follow up request for nova and placement too: i) remove the install_command usage ii) check if pdf doc build works or not | |
| 16:08:33 | gibi | gmann: we should I believe | |
| 16:08:43 | gmann | this one https://github.com/openstack/osc-placement/blob/master/tox.ini#L30 | |