| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-01-10 | |||
| 14:13:50 | bauzas | which is not configurable | |
| 14:14:40 | bauzas | point is, if scaphandre allows you to define the mount point, that's cool, the user just has to mention the right UUID or some script can use the cloud-init data trick I mentioned for guessing the right dir | |
| 14:15:00 | Uggla | bauzas, I think so, but I need to ensure there is nothing link with the qemu process. | |
| 14:15:22 | bauzas | if scaphandre isn't configurable and requires a specific path, then you just symlink the right uuid dir to the path it expects | |
| 14:15:33 | bauzas | ah, I see | |
| 14:15:49 | bauzas | something automatically guess from qemu agent ? | |
| 14:18:16 | bauzas | Kirill_: about the upgrade question | |
| 14:18:54 | bauzas | Kirill_: my proposal is to say that this feature (get a console) is only available when all your computes are fully upgraded | |
| 14:20:25 | bauzas | I have to disappear for 45 mins but I'll be back before the nova meeting | |
| 14:21:03 | Kirill_ | full changes will be on ironic side, in ironic_conductor. For nova we only need one method - get_vnc_console. and seems that we dont have any upgrade problems | |
| 14:22:05 | Kirill_ | now if we ask vnc for ironic we cought error - console not emplemented because get_vnc_console is not done | |
| 14:23:19 | Kirill_ | the idea with traits was because in prev desine we affect on more nova containers | |
| 14:38:04 | sean-k-mooney | bauzas: that does not work | |
| 14:38:16 | sean-k-mooney | asuume all comptue are upgraded | |
| 14:38:30 | sean-k-mooney | as not all ironic compute nodes may support this | |
| 14:38:50 | sean-k-mooney | bauzas: i dont really think there is an upgrade impact to this spec | |
| 14:51:39 | sean-k-mooney | bauzas: Uggla just some other things to note OS-EXT-SRV-ATTR:instance_name is admin only so we cannot leak it to the guest via scaphandre. | |
| 14:52:32 | sean-k-mooney | on the host level the libvirt domain xml uuid is also the nova instance uuid | |
| 14:52:59 | sean-k-mooney | we made that change to allow tools like collectd to corralate metrics with the guest | |
| 14:53:18 | sean-k-mooney | so on the host level scaphandre should parse the uuid form there | |
| 14:54:07 | sean-k-mooney | in the guest yes you can get the instnace uuid form the cofnig drive or metadata api | |
| 15:16:54 | Uggla | sean-k-mooney, it will not be leaked, I use it in the doc to make clear which name it is. User will not see that name, he will have to use the mount_tag | |
| 15:18:52 | sean-k-mooney | ok so scaphandre willl not expose it via virtiofs to the guest | |
| 15:19:14 | sean-k-mooney | in that case its proably ok. | |
| 15:20:19 | Uggla | ok | |
| 15:32:33 | bauzas | sean-k-mooney: have you seen my above comments ? | |
| 15:32:41 | bauzas | sean-k-mooney: about how to know the instance UUID | |
| 15:32:48 | bauzas | cloud-init supports it | |
| 15:33:05 | bauzas | ubuntu@sbauza-devstack1:~$ cat /var/lib/cloud/data/instance-id | |
| 15:33:05 | bauzas | e8408aef-7717-4c35-9298-828dee80906b | |
| 15:33:36 | bauzas | for the host, we already know the instance UUID so it's not a problem | |
| 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 | bauzas | #startmeeting nova | |
| 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 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:00:12 | opendevmeet | The meeting name has been set to '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. | |