| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-01-10 | |||
| 13:51:38 | bauzas | https://github.com/openstack/nova/blob/master/nova/api/metadata/base.py#L165 | |
| 13:51:46 | bauzas | Uggla: ^ | |
| 13:52:00 | Uggla | bauzas, yes I can probably send a new rev today. | |
| 13:53:11 | gibi | stephenfin: I'm confused :) | |
| 13:53:33 | bauzas | Uggla: https://docs.openstack.org/nova/latest/user/metadata.html#ec2-compatible-metadata | |
| 13:53:38 | gibi | stephenfin: so in tox3 we never constrained the editable package install? | |
| 13:53:41 | stephenfin | gibi: https://github.com/pypa/pip/issues/11718#issuecomment-1377291170 | |
| 13:53:45 | gibi | stephenfin: evne with skipdist = True? | |
| 13:54:12 | stephenfin | yup | |
| 13:55:22 | gibi | so either we silently had unconstrained deps in the env or we were lucky and those deps were never updated during the package install | |
| 13:56:52 | stephenfin | I suspect the latter | |
| 13:57:12 | Uggla | bauzas, if I understand well you suggest to keep the uuid as dir name, and change scaphandre to get the instance uuid in the metadata ? | |
| 13:57:48 | bauzas | Uggla: problem is, instance hostname is mutable | |
| 13:57:57 | gibi | stephenfin: so we keep os-vif as is | |
| 13:58:15 | gibi | do you want me to change the nova and placement patch and remove the install_command from there?> | |
| 13:58:25 | gibi | it is not merged yet | |
| 13:58:41 | sean-k-mooney | maybe do that as a follow up patch | |
| 13:59:02 | sean-k-mooney | so we can leave them merge and unblock the gates but then decied the best path forward | |
| 13:59:03 | stephenfin | It might be worth it. The install_command approach will only work for service projects now since those are the only ones not listed in upper-constraints | |
| 13:59:10 | stephenfin | but a follow-up is fine | |
| 13:59:15 | gibi | OK | |
| 13:59:29 | bauzas | Uggla: but with cloud-init, I guess you can get the instance-id | |
| 13:59:32 | bauzas | lemme verify it | |
| 13:59:45 | gibi | Is it fair to say that tox4 is a PITA? | |
| 14:00:24 | sean-k-mooney | maybe with a prefix of an F | |
| 14:00:43 | sean-k-mooney | i personally think we should have kept th 4.0 pin until B | |
| 14:01:03 | sean-k-mooney | based on the breakign changes but its just unfortunate timeing | |
| 14:01:42 | sean-k-mooney | the other reality is that we (openstack) are using a diffent packaging approch to many others | |
| 14:01:53 | bauzas | Uggla: bingo | |
| 14:02:00 | sean-k-mooney | the constriats file is a unique thing we drove and use | |
| 14:02:01 | bauzas | Uggla: tested on our internal cloud | |
| 14:02:14 | bauzas | Uggla: I'm able to get the instance UUID for free | |
| 14:02:20 | sean-k-mooney | so i think we tend to hit these issues first as a result | |
| 14:02:25 | bauzas | Uggla: | |
| 14:02:26 | bauzas | lrwxrwxrwx 1 root root 61 Oct 22 14:05 /var/lib/cloud/instance -> /var/lib/cloud/instances/e8408aef-7717-4c35-9298-828dee80906b/ | |
| 14:02:26 | bauzas | ubuntu@sbauza-devstack1:~$ ll /var/lib/cloud/instance | |
| 14:02:45 | bauzas | https://cloudinit.readthedocs.io/en/latest/topics/faq.html#data | |
| 14:03:05 | bauzas | and I confirm that this UUID is exactly my nova instance UUID | |
| 14:03:56 | opendevreview | Merged openstack/nova stable/xena: Handle "no RAM info was set" migration case https://review.opendev.org/c/openstack/nova/+/860734 | |
| 14:03:58 | Uggla | bauzas, ok sounds not bad. | |
| 14:04:02 | opendevreview | Merged openstack/nova master: Remove basepython def from tox.ini https://review.opendev.org/c/openstack/nova/+/869545 | |
| 14:04:07 | opendevreview | Merged openstack/placement master: Make tox.ini tox 4.0.0 compatible https://review.opendev.org/c/openstack/placement/+/868418 | |
| 14:04:09 | opendevreview | Merged openstack/placement stable/ussuri: placement-status: check only consumers in allocation table https://review.opendev.org/c/openstack/placement/+/840703 | |
| 14:04:13 | opendevreview | Merged openstack/nova stable/xena: Adapt websocketproxy tests for SimpleHTTPServer fix https://review.opendev.org/c/openstack/nova/+/866193 | |
| 14:04:45 | bauzas | Uggla: see my last comment | |
| 14:05:31 | Uggla | bauzas, it needs some changes into scaphandre. But it seems to be a good tradeof. | |
| 14:05:52 | bauzas | Uggla: you can symlink, dude | |
| 14:06:46 | bauzas | some "script" could magically ln -s on some dir based on some UUID it would get from cloud-init data :) | |
| 14:10:21 | Uggla | bauzas, I'm missing how you get the link beetween instance-name --> uuid | |
| 14:10:55 | bauzas | Uggla: what exactly Scaphandre needs to know ? | |
| 14:11:01 | bauzas | without touching it ? | |
| 14:12:06 | Kirill_ | Hi, can we discuss my mr - https://review.opendev.org/c/openstack/nova-specs/+/863773. part with upgrade problem | |
| 14:12:28 | Uggla | bauzas, I need to check, I think it only needs a folder name and propagate the same data to all guests. If it is the case that's ok. | |
| 14:12:39 | bauzas | Kirill_: uploading the context in my mind by looking again at your spec :) | |
| 14:13:02 | Kirill_ | ))) | |
| 14:13:05 | bauzas | Uggla: I guess Scaphandre needs to know the directory to look at, right? | |
| 14:13:19 | bauzas | Uggla: so this is probably config-defined | |
| 14:13:43 | bauzas | or does scaphandre ask you to mount using a specific target ? | |
| 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 | e8408aef-7717-4c35-9298-828dee80906b | |
| 15:33:05 | bauzas | ubuntu@sbauza-devstack1:~$ cat /var/lib/cloud/data/instance-id | |
| 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 | |