| gibi | sean-k-mooney dansmith: I'm +2 on stable uuid first patch but hold +A to get an ack on my analysis of fd closing behavior and to read the rest of the series | 09:10 |
|---|---|---|
| gibi | in sort, in cpython we are fine in pypy we are less fine, and in general zen of python says "Explicit is better than implicit." | 09:12 |
| sahid | o/ | 09:17 |
| gibi | stephenfin: if you are around could you +A https://review.opendev.org/c/openstack/nova/+/869545 ? | 09:36 |
| gibi | and https://review.opendev.org/c/openstack/placement/+/868418 | 09:36 |
| opendevreview | Justas Poderys proposed openstack/nova-specs master: Add support for Napatech LinkVirt SmartNICs https://review.opendev.org/c/openstack/nova-specs/+/859290 | 09:59 |
| opendevreview | Kashyap Chamarthy proposed openstack/nova master: libvirt: Remove compareCPU() check in _check_cpu_compatibility() https://review.opendev.org/c/openstack/nova/+/869587 | 10:09 |
| kashyap | gibi: If you get a few spare minutes, please have a gander at the above. Please also read the commit message to load up on context (this is what takes the most time) | 10:13 |
| opendevreview | Merged openstack/os-vif master: Update gate jobs as per the 2023.1 cycle testing runtime https://review.opendev.org/c/openstack/os-vif/+/861468 | 10:27 |
| bauzas | Uggla: can you please provide a new revision for https://review.opendev.org/c/openstack/nova-specs/+/861881 quickly today ? | 10:38 |
| bauzas | 1/ change the directory to use instance UUID instead of name | 10:39 |
| bauzas | 2/ tell that you'll add a doc explaining live-mig won't work | 10:39 |
| bauzas | and then I can +2 it | 10:39 |
| * bauzas needs to go off in a fex mins tho | 10:39 | |
| opendevreview | Balazs Gibizer proposed openstack/nova stable/train: Reproduce bug 1981813 in func env https://review.opendev.org/c/openstack/nova/+/869673 | 10:47 |
| opendevreview | Balazs Gibizer proposed openstack/nova stable/train: Gracefully ERROR in _init_instance if vnic_type changed https://review.opendev.org/c/openstack/nova/+/869674 | 10:47 |
| Uggla | bauzas, looking at it | 10:52 |
| sean-k-mooney | bauzas: traits never enable features so we need an image proprly or flavor extra spec | 11:32 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova-specs/+/861881/7/specs/2023.1/approved/virtiofs_scaphandre.rst#127 | 11:32 |
| opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Process all nodes when host aggregate changes https://review.opendev.org/c/openstack/nova/+/869687 | 11:49 |
| sean-k-mooney | gibi: the pypy behavior was exactly what i was concerend about | 12:03 |
| gibi | I haven't checked jython and ironpython but I guess they also inherit the gc from the runtime env for java and .net so they are not ref count based | 12:06 |
| sean-k-mooney | yep that is proably | 12:06 |
| sean-k-mooney | althogh as i said im my reply to your comment | 12:07 |
| sean-k-mooney | outside the clients we officaly only support cpython | 12:07 |
| sean-k-mooney | but im not against enabling other interperts for core nova we just dont supprot that officaly or test it | 12:07 |
| sean-k-mooney | i mostly cargo cult the "with open ..." pattern because that is waht i learned to do year ago and the implict understandign that when used as a context manager the file like object retruned by open would close the underlying stream/socket/filedescriptor | 12:09 |
| sean-k-mooney | with statements dont actully form scopes so the closign is delayed until the exit of the function in either case | 12:10 |
| sean-k-mooney | well without the with i gues it when the gc runs ranter then the exit of the fuction scope | 12:10 |
| kashyap | gibi: sean-k-mooney: The functional test failures here seem unrelated to my patch: https://review.opendev.org/c/openstack/nova/+/869587 | 12:12 |
| kashyap | Am I reading it right? Example failure from py38 job: https://zuul.opendev.org/t/openstack/build/21785a8539e34c65aad0038a6cae0cde | 12:12 |
| kashyap | "failed with could not find python interpreter matching any of the specs functional-py38" | 12:13 |
| sean-k-mooney | this is the gate blocker we discussed at the start of the tech call yesterday | 12:13 |
| sean-k-mooney | so not related to your patch | 12:13 |
| kashyap | Ah, I missed it. | 12:13 |
| sean-k-mooney | its related to tox 4 | 12:13 |
| kashyap | sean-k-mooney: Thanks! (My keyboard got locked accidentally, and had to reboot) | 12:24 |
| kashyap | I guess it's related to this patch from gibi -- https://review.opendev.org/c/openstack/placement/+/868418 ("Make tox.ini tox 4.0.0 compatible") | 12:25 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Fix huge-page doc https://review.opendev.org/c/openstack/nova/+/869689 | 12:26 |
| gibi | kashyap: yes | 12:28 |
| sean-k-mooney | kashyap: well tehre is a nova version of that too | 12:28 |
| sean-k-mooney | i think from gmann ? | 12:28 |
| gibi | https://review.opendev.org/c/openstack/nova/+/869545 this is the nova one | 12:29 |
| gibi | sean-k-mooney: I think the with statement itself make sure that after the with block the fd is closed. it might not free up any memory but it closed the file descriptor | 12:29 |
| sean-k-mooney | ah right the stable branch ones are from gmann to pin and the master one is form you | 12:30 |
| sean-k-mooney | stephenfin: just hit the nova patch so that should merge soon | 12:31 |
| gibi | cool | 12:31 |
| kashyap | Thanks for the link! | 12:31 |
| sean-k-mooney | gibi: out of interest what does the -I do in python -I -m ... | 12:31 |
| stephenfin | sean-k-mooney: -I : isolate Python from the user's environment (implies -E and -s) | 12:32 |
| stephenfin | -E : ignore PYTHON* environment variables (such as PYTHONPATH) | 12:32 |
| gibi | yepp | 12:32 |
| sean-k-mooney | ack just checked the help text | 12:32 |
| gibi | I had to look that up too | 12:32 |
| gibi | tox uses -I | 12:32 |
| sean-k-mooney | this ensure that it uses only pacakes in teh venv | 12:33 |
| sean-k-mooney | seams to be workign on my local system so fine by me | 12:36 |
| sean-k-mooney | well mostly given i dont have all the dep to powervm on my laptop | 12:39 |
| sean-k-mooney | if im not mistaken once that merges we can resume merging the pci serise yes | 12:39 |
| sean-k-mooney | that is the last patch blocking that? | 12:39 |
| gibi | sean-k-mooney: that is my hope | 12:40 |
| gibi | I will recheck the bottom of the PCI series when the tox patch lands | 12:40 |
| sean-k-mooney | ack | 12:41 |
| kashyap | Thanks for unblocking the Gate, gibi and gmann! | 12:54 |
| gibi | no worries, I have my incentives to do it :) I want to land the PCI series | 12:56 |
| kashyap | :) | 12:58 |
| stephenfin | gibi: btw, filed https://github.com/pypa/pip/issues/11718 | 13:03 |
| stephenfin | Hopefully we can get ahead of it. This will be a big issue once pip switched to the PEP-517/PEP-660 flow by default | 13:04 |
| sean-k-mooney | stephenfin: nice bug report | 13:17 |
| sean-k-mooney | also usign os-vif sicne its small is a good choice | 13:18 |
| gibi | stephenfin: thanks that is a really good summar of the issue | 13:24 |
| *** bhagyashris is now known as bhagyashris|brb | 13:36 | |
| stephenfin | gibi: Just replied there. Turns out this happens without '--use-pip517' or '-e': tox 3 never used 'install_command' when installing the package under test \o/ | 13:36 |
| stephenfin | so perhaps the "correct" thing to do is to not override 'install_command' at all | 13:39 |
| bauzas | sean-k-mooney: about Uggla's spec, OK, you don't want to use the trait in the flavor extraspec | 13:44 |
| sean-k-mooney | well we can have a required trait but htat required trait cannot change the guest xml | 13:45 |
| sean-k-mooney | traits never enable a feature | 13:45 |
| sean-k-mooney | they only find a host where the feature can be enebaled | 13:45 |
| bauzas | sean-k-mooney: I'm OK with your specific image property : "hw_power_metrics" | 13:45 |
| bauzas | without virtiofs | 13:46 |
| sean-k-mooney | sure | 13:46 |
| bauzas | I wrote a comment | 13:47 |
| bauzas | just b/c virtiofs is related to a specific virt driver | 13:47 |
| bauzas | but meh | 13:48 |
| bauzas | Uggla: would you be able to provide a new revision today then ? | 13:48 |
| bauzas | I guess sean-k-mooney and me agree | 13:48 |
| sean-k-mooney | yes one thing im thinking about is in the future we might need a second property | 13:49 |
| bauzas | Uggla: about the instance UUID, don't be afraid | 13:49 |
| sean-k-mooney | hw_power_metrics_interface=virtiofs|qemu-channel | 13:49 |
| bauzas | Uggla: Scaphandre can know about the instance name | 13:49 |
| sean-k-mooney | ie if qemu gains the ablity to supprot scaphadre without virtio fs | 13:49 |
| bauzas | by looking at the metadata API | 13:49 |
| sean-k-mooney | but i think we can evolved to that | 13:49 |
| bauzas | sean-k-mooney: good point | 13:50 |
| bauzas | https://github.com/openstack/nova/blob/master/nova/api/metadata/base.py#L165 | 13:51 |
| bauzas | Uggla: ^ | 13:51 |
| Uggla | bauzas, yes I can probably send a new rev today. | 13:52 |
| gibi | stephenfin: I'm confused :) | 13:53 |
| bauzas | Uggla: https://docs.openstack.org/nova/latest/user/metadata.html#ec2-compatible-metadata | 13:53 |
| gibi | stephenfin: so in tox3 we never constrained the editable package install? | 13:53 |
| stephenfin | gibi: https://github.com/pypa/pip/issues/11718#issuecomment-1377291170 | 13:53 |
| gibi | stephenfin: evne with skipdist = True? | 13:53 |
| stephenfin | yup | 13:54 |
| 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:55 |
| stephenfin | I suspect the latter | 13:56 |
| 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 |
| bauzas | Uggla: problem is, instance hostname is mutable | 13:57 |
| gibi | stephenfin: so we keep os-vif as is | 13:57 |
| gibi | do you want me to change the nova and placement patch and remove the install_command from there?> | 13:58 |
| gibi | it is not merged yet | 13:58 |
| sean-k-mooney | maybe do that as a follow up patch | 13:58 |
| sean-k-mooney | so we can leave them merge and unblock the gates but then decied the best path forward | 13:59 |
| 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 |
| stephenfin | but a follow-up is fine | 13:59 |
| gibi | OK | 13:59 |
| bauzas | Uggla: but with cloud-init, I guess you can get the instance-id | 13:59 |
| bauzas | lemme verify it | 13:59 |
| gibi | Is it fair to say that tox4 is a PITA? | 13:59 |
| sean-k-mooney | maybe with a prefix of an F | 14:00 |
| sean-k-mooney | i personally think we should have kept th 4.0 pin until B | 14:00 |
| *** dasm|off is now known as dasm | 14:00 | |
| sean-k-mooney | based on the breakign changes but its just unfortunate timeing | 14:01 |
| sean-k-mooney | the other reality is that we (openstack) are using a diffent packaging approch to many others | 14:01 |
| bauzas | Uggla: bingo | 14:01 |
| sean-k-mooney | the constriats file is a unique thing we drove and use | 14:02 |
| bauzas | Uggla: tested on our internal cloud | 14:02 |
| bauzas | Uggla: I'm able to get the instance UUID for free | 14:02 |
| sean-k-mooney | so i think we tend to hit these issues first as a result | 14:02 |
| bauzas | Uggla: | 14:02 |
| bauzas | ubuntu@sbauza-devstack1:~$ ll /var/lib/cloud/instance | 14:02 |
| 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 |
| bauzas | https://cloudinit.readthedocs.io/en/latest/topics/faq.html#data | 14:02 |
| bauzas | and I confirm that this UUID is exactly my nova instance UUID | 14:03 |
| opendevreview | Merged openstack/nova stable/xena: Handle "no RAM info was set" migration case https://review.opendev.org/c/openstack/nova/+/860734 | 14:03 |
| Uggla | bauzas, ok sounds not bad. | 14:03 |
| opendevreview | Merged openstack/nova master: Remove basepython def from tox.ini https://review.opendev.org/c/openstack/nova/+/869545 | 14:04 |
| opendevreview | Merged openstack/placement master: Make tox.ini tox 4.0.0 compatible https://review.opendev.org/c/openstack/placement/+/868418 | 14:04 |
| opendevreview | Merged openstack/placement stable/ussuri: placement-status: check only consumers in allocation table https://review.opendev.org/c/openstack/placement/+/840703 | 14:04 |
| opendevreview | Merged openstack/nova stable/xena: Adapt websocketproxy tests for SimpleHTTPServer fix https://review.opendev.org/c/openstack/nova/+/866193 | 14:04 |
| bauzas | Uggla: see my last comment | 14:04 |
| Uggla | bauzas, it needs some changes into scaphandre. But it seems to be a good tradeof. | 14:05 |
| bauzas | Uggla: you can symlink, dude | 14:05 |
| bauzas | some "script" could magically ln -s on some dir based on some UUID it would get from cloud-init data :) | 14:06 |
| Uggla | bauzas, I'm missing how you get the link beetween instance-name --> uuid | 14:10 |
| bauzas | Uggla: what exactly Scaphandre needs to know ? | 14:10 |
| bauzas | without touching it ? | 14:11 |
| Kirill_ | Hi, can we discuss my mr - https://review.opendev.org/c/openstack/nova-specs/+/863773. part with upgrade problem | 14:12 |
| 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 |
| bauzas | Kirill_: uploading the context in my mind by looking again at your spec :) | 14:12 |
| Kirill_ | ))) | 14:13 |
| bauzas | Uggla: I guess Scaphandre needs to know the directory to look at, right? | 14:13 |
| bauzas | Uggla: so this is probably config-defined | 14:13 |
| bauzas | or does scaphandre ask you to mount using a specific target ? | 14:13 |
| bauzas | which is not configurable | 14:13 |
| 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:14 |
| Uggla | bauzas, I think so, but I need to ensure there is nothing link with the qemu process. | 14:15 |
| 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 |
| bauzas | ah, I see | 14:15 |
| bauzas | something automatically guess from qemu agent ? | 14:15 |
| bauzas | Kirill_: about the upgrade question | 14:18 |
| bauzas | Kirill_: my proposal is to say that this feature (get a console) is only available when all your computes are fully upgraded | 14:18 |
| bauzas | I have to disappear for 45 mins but I'll be back before the nova meeting | 14:20 |
| 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:21 |
| Kirill_ | now if we ask vnc for ironic we cought error - console not emplemented because get_vnc_console is not done | 14:22 |
| Kirill_ | the idea with traits was because in prev desine we affect on more nova containers | 14:23 |
| sean-k-mooney | bauzas: that does not work | 14:38 |
| sean-k-mooney | asuume all comptue are upgraded | 14:38 |
| sean-k-mooney | as not all ironic compute nodes may support this | 14:38 |
| sean-k-mooney | bauzas: i dont really think there is an upgrade impact to this spec | 14:38 |
| 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:51 |
| sean-k-mooney | on the host level the libvirt domain xml uuid is also the nova instance uuid | 14:52 |
| sean-k-mooney | we made that change to allow tools like collectd to corralate metrics with the guest | 14:52 |
| sean-k-mooney | so on the host level scaphandre should parse the uuid form there | 14:53 |
| sean-k-mooney | in the guest yes you can get the instnace uuid form the cofnig drive or metadata api | 14: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:16 |
| sean-k-mooney | ok so scaphandre willl not expose it via virtiofs to the guest | 15:18 |
| sean-k-mooney | in that case its proably ok. | 15:19 |
| Uggla | ok | 15:20 |
| bauzas | sean-k-mooney: have you seen my above comments ? | 15:32 |
| bauzas | sean-k-mooney: about how to know the instance UUID | 15:32 |
| bauzas | cloud-init supports it | 15:32 |
| bauzas | ubuntu@sbauza-devstack1:~$ cat /var/lib/cloud/data/instance-id | 15:33 |
| bauzas | e8408aef-7717-4c35-9298-828dee80906b | 15:33 |
| bauzas | for the host, we already know the instance UUID so it's not a problem | 15:33 |
| 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:34 |
| bauzas | from the host, you mean ? | 15:35 |
| Uggla | yes | 15:35 |
| Uggla | When the instance name will change ? Hard reboot ? | 15:36 |
| bauzas | and then, I guess scaphandre creates a directoty in the shared mountpoint, right? | 15:36 |
| Uggla | yes a directory and file containing the data from the vm name. | 15:37 |
| bauzas | ok, but does it create a specific mount ? | 15:38 |
| bauzas | I mean, does it create one mountpoint per instance ? | 15:39 |
| bauzas | using virtiofs | 15:39 |
| Uggla | yep | 15:39 |
| Uggla | 1 dir + file per vm | 15:39 |
| bauzas | ok, then anyway scaphandre will need to be modified | 15:39 |
| bauzas | because your spec only uses one mountpoint | 15:40 |
| bauzas | for all instances | 15:40 |
| Uggla | 1 mp with x dir per vm name | 15:40 |
| bauzas | that's what I understood | 15:40 |
| Uggla | let me give an example it will be easier: | 15:41 |
| bauzas | so, anyway, as you see, if scaphandre wants to supports nova, then they need to modify this | 15:41 |
| bauzas | instead of creating one mountpoint per instance | 15:41 |
| bauzas | they could keep an shared mountpoint between guests | 15:41 |
| Uggla | the actual path on the host is /var/lib/libvirt/scaphandre/<vmname>/intel-rapl:0:0 | 15:44 |
| bauzas | and I guess this whole ath is mounted thru virtiofs as a single mount point ? | 15:45 |
| bauzas | whole path* | 15:45 |
| bauzas | instead of mounting /var/lib/libvirt/scaphandre | 15:46 |
| 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 |
| bauzas | as a reminder, btw. nova meeting in 13 mins here | 15:47 |
| 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:48 |
| 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:49 |
| Uggla | bauzas, if you want we can have a quick chat after nova meeting. | 15:50 |
| Uggla | bauzas, to my mind it works even if vmname change. | 15:52 |
| bauzas | Uggla: who's creating the mount ? | 15:55 |
| bauzas | is it automatically done by scaphandre or does the operator need to do it ? | 15:56 |
| Uggla | scaphandre will create the "path" | 15:56 |
| bauzas | who exposes it thru virtiosfs ? | 15:56 |
| Uggla | nova | 15:57 |
| bauzas | and without nova ? | 15:58 |
| Uggla | user | 15:58 |
| bauzas | this has to be configured ? | 15:58 |
| bauzas | ok, cool enough then | 15:58 |
| bauzas | so, | 15:58 |
| bauzas | we have the nova meeting in a sec | 15:58 |
| bauzas | but we can indeed discuss that later | 15:59 |
| bauzas | because I don't think it's a problem | 15:59 |
| bauzas | unless I'm wrong | 15:59 |
| bauzas | anyway, there it goes | 16:00 |
| bauzas | #startmeeting nova | 16:00 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:00 |
| bauzas | good UTC afternoon everyone | 16:00 |
| bauzas | who's around ? | 16:00 |
| dansmith | Oj | 16:00 |
| gibi | o/ | 16:00 |
| gmann | o/ | 16:00 |
| kgube | o/ | 16:00 |
| elodilles | o/ | 16:01 |
| sean-k-mooney | o/ | 16:01 |
| Uggla | o/ | 16:01 |
| Kirill_ | o/ | 16:01 |
| bauzas | welcome everyone | 16:01 |
| bauzas | #topic Bugs (stuck/critical) | 16:01 |
| bauzas | #info No Critical bug | 16:01 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 27 new untriaged bugs (+2 since the last meeting) | 16:01 |
| bauzas | I have to do my duty | 16:02 |
| bauzas | if someone has time for triaging upstream bugs, that'd be lovely but I can do it | 16:02 |
| bauzas | and then we'll go back to the roster | 16:02 |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:02 |
| Uggla | bauzas, bug triage, I can do it is it helps you. | 16:03 |
| gibi | +1 for the roster | 16:03 |
| bauzas | Uggla: I'll take the baton for this week, but if you want, we can both look at bugs | 16:03 |
| bauzas | #info bug baton is being passed to bauzas | 16:04 |
| bauzas | any particular urgent bug to discuss ? | 16:04 |
| bauzas | I guess we'll discuss the tox saga in the next chapter | 16:04 |
| bauzas | if no, let's move on and go to the gate topic | 16:04 |
| bauzas | #topic Gate status | 16:05 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:05 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | 16:05 |
| bauzas | #link https://review.opendev.org/c/openstack/tempest/+/866049 proposal to add more delay for centos9s-fips job | 16:05 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:05 |
| gibi | placement and nova gate is unblocked as far as I know. we merged the two tox4 patches | 16:05 |
| bauzas | #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures | 16:05 |
| bauzas | I was about to tell it once I was done with the weekly items | 16:05 |
| bauzas | so, | 16:05 |
| gibi | I see nova patches progressing in the gate queue | 16:06 |
| gibi | so I think we are OK | 16:06 |
| gibi | I haven't chacked osc-placement and python-novaclient status | 16:06 |
| gibi | os-vif should be unblocked too | 16:06 |
| gmann | their master gate is good, I checked | 16:06 |
| gmann | but for stable branch gate, python-novaclient patches need to merge #link https://review.opendev.org/q/I442568a5f5900e593feb2b5527109e0aa79e5aa7+status:open | 16:06 |
| dansmith | nice | 16:07 |
| gmann | and osc-placement is failing <= stable/yoga https://review.opendev.org/c/openstack/osc-placement/+/869451 | 16:07 |
| 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 |
| gmann | it is failing on placement functionla job where we use master placement but stable branch constraints so mismatch | 16:07 |
| bauzas | gmann: cool, I'll look at the novaclient patch | 16:07 |
| gmann | I cannot remember why we do not use master constraints in that placement functional job? | 16:08 |
| bauzas | oh, I did it already | 16:08 |
| 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 |
| gibi | gmann: we should I believe | 16:08 |
| gmann | this one https://github.com/openstack/osc-placement/blob/master/tox.ini#L30 | 16:08 |
| sean-k-mooney | we want it t o run against master i belvie | 16:09 |
| gibi | gmann: hm, do we have placement in the upper-constraints? | 16:09 |
| sean-k-mooney | perhaps although we shoudl not | 16:09 |
| sean-k-mooney | only lib projects should eb in uc | 16:09 |
| gmann | gibi: no because we use it from master source | 16:09 |
| bauzas | sean-k-mooney: this is for testing placement itself | 16:10 |
| bauzas | so we need the latest | 16:10 |
| gibi | this is testing osc-placement I believe | 16:10 |
| bauzas | correct | 16:10 |
| gmann | yeah testing osc-placement with master placement | 16:10 |
| sean-k-mooney | its the fucntional test for placement openstackclient plugin | 16:10 |
| gibi | and constarints are inherited from https://github.com/openstack/osc-placement/blob/fdf10423bf29b7cfd5e88d9d06e1313ee881ab80/tox.ini#L17 | 16:10 |
| bauzas | we're discussing of testing osc-placement | 16:10 |
| bauzas | using placement master branch | 16:10 |
| sean-k-mooney | yes and how the functional job forces the master branch of placment | 16:11 |
| bauzas | yup | 16:11 |
| sean-k-mooney | i think this was because fo the placment fixture | 16:11 |
| gmann | gibi: it use stable/yoga for yoga testing #link https://github.com/openstack/osc-placement/blob/stable/yoga/tox.ini#L18 | 16:11 |
| gmann | for master it is all good | 16:11 |
| gmann | master gate | 16:11 |
| bauzas | agreed with gmann | 16:11 |
| sean-k-mooney | https://github.com/openstack/osc-placement/commit/da8cd4d68b06399c607776db2a704b4578146996 | 16:11 |
| gibi | I don't see the issue sorry | 16:11 |
| gmann | for stable/zed somehow constraints matches so we do not see failure | 16:11 |
| bauzas | if I have a osc client patch, I don't wanna hold my check on a placement release | 16:11 |
| sean-k-mooney | so the tox.ini is correct | 16:11 |
| gmann | sean-k-mooney: stable/yoga constraints will not work with latest placement | 16:12 |
| bauzas | anyway, tox4 upgrade was fun | 16:12 |
| gmann | that is why it is failing on os-traits version mismatch | 16:12 |
| sean-k-mooney | for stable branchs we likely need to pin yes | 16:13 |
| * bauzas wonders whether pyproject.toml files were having the same issues than tox.ini | 16:13 | |
| gmann | yeah, either pin placement or use master constraints for this latest placement testing | 16:13 |
| sean-k-mooney | bauzas: likely not because they handel constratits differnrlty | 16:13 |
| gmann | anyways we can discuss it after meeting as it seems need more discussions | 16:13 |
| gibi | gmann: so on stable/yoga this is an issue https://github.com/openstack/osc-placement/blob/stable/yoga/tox.ini#L31 | 16:13 |
| gibi | as it install master placement on stable yoga | 16:13 |
| gmann | gibi: yes. | 16:14 |
| sean-k-mooney | ya so we just need to pin the branch in that line which is posible | 16:14 |
| gibi | OK I got it | 16:14 |
| elodilles | as i remember constraints from master also caused issues on stable branches (in placement) | 16:14 |
| bauzas | sean-k-mooney: yeah, my point is that if the tox developers don't verify the behaviours of tox.ini and rather say they just verify the toml ones, then I'm a bit afraid | 16:14 |
| sean-k-mooney | bauzas: its not related to that | 16:14 |
| sean-k-mooney | bauzas: openstack is quite differnt form ontehr python project in how we use setuptools/pbr and the idea of a constratis file | 16:15 |
| gmann | all other stable branches gate are good. I tested them after pin | 16:15 |
| gibi | bauzas: tox4 was a rewrite, and they are not intending to keep all the tox3 behavior (I learned yesterday) | 16:15 |
| bauzas | sean-k-mooney: sure I'm not saying we should create a pyproject.toml filze | 16:15 |
| gibi | gmann: thanks! | 16:15 |
| bauzas | sean-k-mooney: but I was wondering why nobody was finding the problem until we told them | 16:16 |
| sean-k-mooney | bauzas: well that has been discussed and we might want to eventually but we should lop back to one topic | 16:16 |
| sean-k-mooney | bauzas: because constrait files is baicaly an openstack thing | 16:16 |
| bauzas | sean-k-mooney: we didn't had only problems with constraints | 16:16 |
| clarkb | sean-k-mooney: openstack is the primary user in the wild probably but it is a normal pip functionality | 16:16 |
| sean-k-mooney | we are the comunity that drove that in pip | 16:16 |
| sean-k-mooney | but yes its is a pip capablity | 16:17 |
| bauzas | gibi: ack, good to know | 16:17 |
| clarkb | bauzas: fwiw I'm helping to move zuul and opendev projects to nox | 16:17 |
| * bauzas notes it | 16:17 | |
| sean-k-mooney | isnit that a pti issue | 16:17 |
| sean-k-mooney | dont we specify tox explictly | 16:17 |
| clarkb | (because there are lots of little tox changes and when I file issues upstream the resposne is often "why would you do that?" and the answer is well because v3 supported it so ya...) | 16:17 |
| clarkb | sean-k-mooney: yes for openstack. I personally think openstack should change too | 16:17 |
| clarkb | but it is work | 16:17 |
| sean-k-mooney | perhaps a good ptg topic | 16:18 |
| gmann | +1 | 16:18 |
| dansmith | I'm not super keen on the nox thing | 16:18 |
| sean-k-mooney | how to evovle pti | 16:18 |
| bauzas | not only for our project | 16:18 |
| dansmith | so I'd like to have a real discussion about it | 16:18 |
| bauzas | should be a cross-project discussion honestly | 16:18 |
| dansmith | (I'm also not super keen on tox destroying the world for fun and profit) | 16:18 |
| sean-k-mooney | right i was thinking comuity/cross project topic | 16:18 |
| bauzas | dansmith: me too | 16:18 |
| gmann | right | 16:18 |
| bauzas | honestly, I'd have preferred to continue using tox3 until we test all the modifications they did | 16:19 |
| sean-k-mooney | ok so looping back. we need to pin placment on stable branches fo osc-placment | 16:19 |
| bauzas | but, this is done | 16:19 |
| sean-k-mooney | and we have unbolcked the other "nova" gates | 16:19 |
| sean-k-mooney | with followups for the install_commands changes correct? | 16:19 |
| gmann | sean-k-mooney: gibi: ok for pin but I was thinking we have to test latest placement there? I do not know reason just want to confirm | 16:19 |
| sean-k-mooney | gmann: git+https://opendev.org/openstack/placement.git#egg=openstack-placement line on master | 16:20 |
| sean-k-mooney | is so we get the latest placement fixture | 16:20 |
| bauzas | and the fact that tox developers just rewrite their tox.ini by what they want without continuing to support the existing (and without deprecating them at least) let me think about any new major tox versions we'd have | 16:20 |
| gmann | so we need to test latest placement in master gate only | 16:20 |
| gibi | gmann: I don't know the reason either | 16:20 |
| sean-k-mooney | so we can test when new feture are addded | 16:20 |
| gmann | sean-k-mooney: right but that we do not need on stable osc-placement version right? | 16:21 |
| sean-k-mooney | gmann: correct it can and should use the stable version | 16:21 |
| gmann | I was hesitating to pin placement there as I do not know the original reason ot use latest placement there | 16:21 |
| sean-k-mooney | they do need to be kept in sync however | 16:21 |
| sean-k-mooney | its caputed in teh comme messange here https://github.com/openstack/osc-placement/commit/da8cd4d68b06399c607776db2a704b4578146996 | 16:22 |
| gmann | ack | 16:22 |
| gmann | thanks | 16:22 |
| sean-k-mooney | ok i think we have covered those topics and can move on | 16:24 |
| bauzas | I was about to ask | 16:24 |
| bauzas | ok, let's move on then | 16:24 |
| gmann | yeah | 16:24 |
| bauzas | #topic Release Planning | 16:25 |
| bauzas | #link https://releases.openstack.org/antelope/schedule.html | 16:25 |
| bauzas | #info Antelope-3 is in 5 weeks | 16:25 |
| bauzas | (and featurefreeze... :) ) | 16:25 |
| bauzas | #info As a reminder, Nova SpecFreeze deadline is this Thursday https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031636.html | 16:25 |
| bauzas | I'll modify launchpad's https://blueprints.launchpad.net/nova/antelope once we're done with reviewing specs | 16:26 |
| bauzas | I have then a question | 16:26 |
| bauzas | #link https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031645.html I guess we'll want to have a virtual PTG again ? | 16:27 |
| bauzas | for the Bobcat planning :) | 16:27 |
| bauzas | (man, haven't but should have voted this time...) | 16:27 |
| sean-k-mooney | can we create teh 2023.2 specs repo after spec freeze | 16:28 |
| sean-k-mooney | i dont recall seeing a vote email go out | 16:28 |
| bauzas | there was one | 16:28 |
| sean-k-mooney | i tought this was selected by the foundation | 16:28 |
| bauzas | nope, sent during your holidaus | 16:28 |
| sean-k-mooney | ok well the foundation has never consicidently sent me vote urls anyway | 16:28 |
| bauzas | hence why you haven't probably seen it | 16:28 |
| gmann | format will be 1 virtual PTG + 1 in-person PTG per year. in-person PTG will be aligned to summit+release | 16:29 |
| bauzas | gmann: any chance to have those physical attendances (I don't like the PTG naming) to be at the start of the release time ? | 16:29 |
| bauzas | for Vancouver, ship is sailed | 16:29 |
| dansmith | sean-k-mooney: I didn't get one either | 16:30 |
| gmann | bauzas: yeah, that is what foundation staff updated that they will try to aligned it with summit and openstack relaese but let's see as it can be challenging too | 16:30 |
| bauzas | dansmith: sean-k-mooney: https://lists.openstack.org/pipermail/openstack-discuss/2022-December/031551.html | 16:30 |
| dansmith | oh, to the list | 16:31 |
| bauzas | 70% of the list was probably on PTO | 16:31 |
| sean-k-mooney | but that vote url is a personal one | 16:31 |
| sean-k-mooney | not one everyone can use right | 16:31 |
| gmann | for vancouver, yes as event is in between of cycle it needs to be that time | 16:31 |
| sean-k-mooney | you are ment to get one to your personal email for all votes | 16:31 |
| bauzas | sean-k-mooney: good point, again, I haven't voted so I haven't tested it | 16:31 |
| gmann | sean-k-mooney: I think it is public vote so anyone can vote with that url but one per IP or so | 16:32 |
| bauzas | anyway, this is done anyway | 16:32 |
| gmann | if I am remembering public vote things correctly | 16:32 |
| bauzas | gmann: fun fact is, voting isn't closed AFAICS | 16:32 |
| sean-k-mooney | perhaps in the tool but the name has been released | 16:33 |
| bauzas | yup, another ship sailed | 16:33 |
| sean-k-mooney | in anycase i can create a 2023.2 folder in the spec repo | 16:33 |
| gmann | ohk :) honestly saying I have not given mush attention to release naming :) | 16:33 |
| gmann | sean-k-mooney: +1 | 16:33 |
| bauzas | sean-k-mooney: wait for the spec freeze | 16:33 |
| sean-k-mooney | but bauzas if you want to do that after spec freeze we can wait till after thrsday | 16:33 |
| opendevreview | Merged openstack/nova stable/wallaby: Adapt websocketproxy tests for SimpleHTTPServer fix https://review.opendev.org/c/openstack/nova/+/866194 | 16:33 |
| bauzas | sean-k-mooney: or it would perhaps confuse people | 16:33 |
| bauzas | sean-k-mooney: well, I'm not opposed to delegate | 16:33 |
| sean-k-mooney | cool well i ahve done it in the past but lest do it next week | 16:34 |
| bauzas | anyway, I guess we vote for a virtual PTG on end of March ? (that was the original question) | 16:34 |
| bauzas | and we don't say "meh, no, just let's do a physical one at right the middle of the release, and go f*** our deadlines !" | 16:35 |
| bauzas | :D | 16:35 |
| bauzas | I hear crickets, so I decide so | 16:36 |
| elodilles | well, that is the usual PTG time, so i think it is not something to vote for :) | 16:36 |
| gmann | not sure physical one can be utilized same as our normal PTG but can plan for some operaotr oriented discussions | 16:36 |
| bauzas | #info we'll have a virtual Nova PTG on March 27-31 | 16:36 |
| gmann | virtual one in March will be the normal vPTG we have for cycle | 16:36 |
| bauzas | I'll register our name :) | 16:36 |
| bauzas | gmann: honestly, I don't expect much more from what we currently have at the Forum | 16:37 |
| bauzas | gmann: but let's be creative | 16:37 |
| gmann | bauzas: yeah. | 16:37 |
| bauzas | if we really need to s/Forum/PTG to have more people coming, I'm not opposed to a rebranding | 16:37 |
| elodilles | some teams do mid-cycle PTG-s, so the in-person one can be considered such, i guess | 16:37 |
| gmann | we asked same PTG fomat questions on vancouver PTG but that is not answer yet | 16:37 |
| bauzas | elodilles: given the Summit will be around Spec Freeze, that's gonna be fun | 16:38 |
| gmann | I think in openstack-discuss ML but anyways let's see | 16:38 |
| bauzas | elodilles: but we could do 'review sprints' or 'implementation sessions' | 16:38 |
| bauzas | if that helps people wanting to come :) | 16:39 |
| gmann | +1. good idea | 16:39 |
| bauzas | I guess we're done on that topic | 16:39 |
| bauzas | moving on | 16:39 |
| bauzas | #topic Review priorities | 16:39 |
| 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:39 |
| bauzas | #info As a reminder, cores eager to review changes can +1 to indicate their interest, +2 for committing to the review | 16:39 |
| bauzas | I'll slowly but progressively use this label for knowing what to review | 16:40 |
| bauzas | so you know about it | 16:40 |
| bauzas | next topic (we only have 20 mins) | 16:40 |
| bauzas | #topic Stable Branches | 16:40 |
| bauzas | elodilles: happy to see you back | 16:40 |
| elodilles | :) | 16:40 |
| elodilles | we mostly discussed, but | 16:40 |
| elodilles | #info stable branches seem to be unblocked / OK -- except placement, osc-placement, ... | 16:41 |
| elodilles | thanks gmann for fixing the tox4 issues on stable branches! | 16:41 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:41 |
| elodilles | and maybe one more thing: | 16:41 |
| gmann | for pin not fix :) | 16:41 |
| elodilles | gmann: yepp, a good workaround for now ;) | 16:42 |
| elodilles | so maybe we should do nova stable releases as there are already some merged content on zed, yoga and xena | 16:42 |
| elodilles | and a small side track: i would want some stable core opinions about my comment here: https://review.opendev.org/c/openstack/nova/+/867912 | 16:43 |
| elodilles | as the zed release might depend on that | 16:43 |
| bauzas | elodilles: sure, want me to create the releases ? | 16:43 |
| bauzas | stable releases, I mean | 16:44 |
| elodilles | but that can be done after the meeting | 16:44 |
| bauzas | we're in a good timing | 16:44 |
| sean-k-mooney | elodilles this is your main question right https://review.opendev.org/c/openstack/nova/+/867912/5/nova/conf/workarounds.py | 16:44 |
| elodilles | bauzas: yes, if you have time :) otherwise i can also propose them | 16:44 |
| elodilles | sean-k-mooney: yes | 16:44 |
| sean-k-mooney | so i considerd that when reviewing | 16:45 |
| sean-k-mooney | i tought the value of the fix in behaivor outwaied the possibel performance impact | 16:45 |
| sean-k-mooney | but you are correct that fliping the default would maintain the old behaivor | 16:45 |
| sean-k-mooney | fliping the default woudl also result in a workaorunds option being enabeld by default | 16:46 |
| sean-k-mooney | which we generally avoid | 16:46 |
| sean-k-mooney | so not changing the default felt more consitent to me | 16:46 |
| sean-k-mooney | im not sure what other think ^ | 16:46 |
| bauzas | hmmm | 16:46 |
| bauzas | loading the context | 16:46 |
| sean-k-mooney | the context is mostly captured in teh help text :) | 16:47 |
| bauzas | so it was a opt-out config | 16:47 |
| bauzas | and when backporting it suddently became opt-in | 16:47 |
| bauzas | right? | 16:47 |
| sean-k-mooney | no we did not change it when back porting | 16:47 |
| sean-k-mooney | elodilles: question is should we | 16:47 |
| sean-k-mooney | so on master we default to the new more desireable beahvior | 16:48 |
| elodilles | no. to put it simple: we change the default behavior on stable branches | 16:48 |
| sean-k-mooney | and elodilles is asking shoudl we keep the old beahivor in the backports | 16:48 |
| bauzas | https://review.opendev.org/c/openstack/nova/+/864773/3/nova/conf/workarounds.py default on master is False | 16:48 |
| bauzas | so that's opt-in | 16:48 |
| bauzas | which is the same for the backports | 16:49 |
| elodilles | i mean, given an installed environment, they upgrade, and the behaviour is changed with the upgraded nova | 16:49 |
| sean-k-mooney | elodilles: correct | 16:49 |
| bauzas | elodilles: I don't see a problem here with keeping it opt-in | 16:49 |
| sean-k-mooney | bauzas: well it will required all operator to update there config to adress the bug | 16:49 |
| elodilles | bauzas: it is opt-out :) you have to change the configuration to have the existing behaviour | 16:49 |
| bauzas | sean-k-mooney which is the current behaviour on master, right? | 16:50 |
| sean-k-mooney | on master we now set the reseved value on instnace boot | 16:50 |
| sean-k-mooney | before this patch we set reserved wehn deleteing | 16:50 |
| bauzas | because the option defaults to False, right? | 16:51 |
| bauzas | if you set to True, you keep the original behaviou | 16:51 |
| sean-k-mooney | the workaroudn option is a skip to opt out yes and it default to false | 16:51 |
| bauzas | behaviour | 16:51 |
| sean-k-mooney | correct | 16:51 |
| bauzas | ok | 16:51 |
| bauzas | so, say we backport this | 16:51 |
| bauzas | as it is | 16:51 |
| bauzas | to understand, that means we'll change the behaviour by upgrading to the latest (obviously .y) release | 16:52 |
| sean-k-mooney | as is then the stable branchs get the new behaivor and you need to modify the config to restore the old behaiovr | 16:52 |
| sean-k-mooney | but this is an internal implemation detail that is not part of any public contract | 16:52 |
| bauzas | I think we have semver for communicating the behavioural change | 16:52 |
| sean-k-mooney | so we felt this was better | 16:52 |
| bauzas | can we discuss this out of the meeting ? | 16:53 |
| bauzas | we have 5 mins left | 16:53 |
| sean-k-mooney | sure | 16:53 |
| bauzas | #topic Open discussion | 16:53 |
| bauzas | (bauzas) As a reminder, Summit proposals deadline is today 11:59pm PT | 16:53 |
| elodilles | so if we release now zed, then the operators who uses zed, need to update their configs to have NOT to change how nova works | 16:53 |
| bauzas | you have the very last minute to add your topics | 16:53 |
| bauzas | fwiw, I proposed two forum sessions about nova onboarding and operator meet&greet | 16:54 |
| bauzas | if someone wants to co-host the onboarding forum session, let me know | 16:54 |
| bauzas | gmann: correct me but forum proposal deadline is on april ? | 16:55 |
| bauzas | I'm confused by the fact they added the forum proposals in the tool | 16:55 |
| gmann | bauzas: I hope so. I asked Erin in email but no reply yet. But from form it shows april | 16:55 |
| bauzas | yup, hence my confusion | 16:55 |
| bauzas | I just hope we won't get like Berlin some Forum sessions that very look like Summit sessions with slides and one-sided discussions | 16:56 |
| kashyap | Oh, come on...after all the jobs passed, one "tempest-integrated-compute" job times out :( https://zuul.opendev.org/t/openstack/build/8b07fa0b71c94fb6abb2b350c5c84c74 | 16:56 |
| bauzas | kashyap: on our meeting atm | 16:56 |
| kashyap | Oops, sorry for that random chime in. | 16:56 |
| kashyap | bauzas: Yeah, only realized it just now (sorry) | 16:56 |
| bauzas | np | 16:56 |
| bauzas | (gmann) updates on switching the RBAC(scope and new defaults) defaults in nova | 16:57 |
| gibi | bauzas: if you need a co-host for the onboarding then you can write me up | 16:57 |
| bauzas | you have 3 mins | 16:57 |
| bauzas | gibi: noted. I'm used to do some onboarding and I have ideas but having a co-speaker is somehow better | 16:57 |
| gibi | sure | 16:57 |
| bauzas | looks like gmann is gone and our meeting will end | 16:58 |
| gmann | patch is ready for review #link https://review.opendev.org/c/openstack/nova/+/866218/12 | 16:58 |
| bauzas | cool thanks | 16:58 |
| bauzas | gmann: I've seen your ping, I just didn't had time to review it yet | 16:58 |
| gmann | please check and it need placement test fixture change too which is depends-on on nova change #link https://review.opendev.org/c/openstack/placement/+/869525/3 | 16:58 |
| gmann | do not want to delay the switching at the end of cycle | 16:59 |
| bauzas | I've just said review-prio +2 | 16:59 |
| gmann | Tempest already run integration job with new RBAC on Nova, glance, neutron and cinder and it is passing finw | 16:59 |
| gmann | thanks | 16:59 |
| bauzas | \o/ | 16:59 |
| opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Process all nodes when host aggregate changes https://review.opendev.org/c/openstack/nova/+/869687 | 17:00 |
| bauzas | ok, we're on time | 17:00 |
| bauzas | thanks all | 17:00 |
| bauzas | #endmeeting | 17:00 |
| opendevmeet | Meeting ended Tue Jan 10 17:00:20 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-01-10-16.00.html | 17:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-01-10-16.00.txt | 17:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-01-10-16.00.log.html | 17:00 |
| gibi | o/ thanks' | 17:00 |
| elodilles | thanks o/ | 17:00 |
| gmann | thanks o/ | 17:00 |
| clarkb | re nox it is definitely worth careful consideration and discussion. I like to bring it up ecause I've found many people aren't aware there is an alternative. As far as why I think it is worth considering the main thing is that it is simpler and uses simple building blocks instead of a bunch of custom rewrites of standard tools like build | 17:01 |
| clarkb | when you install things you just run pip basically. | 17:01 |
| clarkb | and you aren't getting custom wheel building like with tox for example | 17:01 |
| gmann | bauzas: dansmith: this is tempest job enabling new rbac and passing fine. I am adding same in nova side too in 866218 https://zuul.openstack.org/builds?job_name=tempest-full-enforce-scope-new-defaults&skip=0 | 17:02 |
| sean-k-mooney | johnthetubaguy: can you review this ironic hostaggreate change https://review.opendev.org/c/openstack/nova/+/869687 | 17:04 |
| sean-k-mooney | bauzas: ^ also good for you to look at | 17:04 |
| sean-k-mooney | bauzas: did we settel on ironic is not supprot for host aggreates a while ago when chatting downstream | 17:04 |
| bauzas | sean-k-mooney: I thought we said given we only support hostnames in aggregates (and not nodenames), I hardly understand how this can work | 17:06 |
| bauzas | but you can target a specific nova-compute using aggregates so that can still work with sharded ironic nodes | 17:07 |
| sean-k-mooney | when you add a comptue host to thet api https://docs.openstack.org/api-ref/compute/?expanded=add-host-detail#add-host | 17:07 |
| sean-k-mooney | you are adding the comptue service | 17:07 |
| sean-k-mooney | and ironic is currently loadbalanceing compute nodes between compute services | 17:07 |
| bauzas | agreed, that's what I said | 17:09 |
| bauzas | but you can't target a node, that's my point | 17:09 |
| bauzas | the good news is that placement aggregates support nodes | 17:10 |
| sean-k-mooney | right so what they are trying to do in that patch is incluse all the ironic RPs created for the ironic servier in the the placement aggreate | 17:10 |
| bauzas | so theorically, you could do some flavorey query about it | 17:10 |
| sean-k-mooney | you coudl but if we proceed with this patch we are baissly saying we now supprot host aggrates with ironic again | 17:11 |
| sean-k-mooney | im pretty sure we did in the past and that broke at some point | 17:11 |
| sean-k-mooney | where somepoint is a long long time ago | 17:11 |
| bauzas | long long time ago, we were not having placement aggregates | 17:12 |
| bauzas | and if I blame the existing add_host_to_agg code, I don't think I'll see a difference | 17:13 |
| sean-k-mooney | didnt we used to have multipel compute services for ironic ndoes or something | 17:14 |
| bauzas | I don't think so but I could be wrong | 17:15 |
| sean-k-mooney | ok your right we did not | 17:16 |
| sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/add-ironic-driver.html#proposed-change | 17:16 |
| sean-k-mooney | it was intially one compute service | 17:16 |
| sean-k-mooney | then we supported muple in newton https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/ironic-multiple-compute-hosts.html | 17:17 |
| sean-k-mooney | i guess based on https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/cells-aggregate-api-db.html | 17:20 |
| sean-k-mooney | the aggreate api si ment ot be aggreate to compute node mappings | 17:21 |
| sean-k-mooney | in which case then yes ironci shoudl work | 17:21 |
| sean-k-mooney | you just need to add each node by the ironic uuid | 17:21 |
| sean-k-mooney | however that is what we tried downstream and it did not seam to work | 17:21 |
| sean-k-mooney | and i recal that that used to work before | 17:21 |
| bauzas | that's what I remember when we discussed about placement aggs | 17:23 |
| bauzas | in general, we only support the first node | 17:23 |
| sean-k-mooney | well for nova aggreates ignoring placment that is what used to work in newton | 17:23 |
| sean-k-mooney | we coudl map compute nodes to aggates by the host key | 17:24 |
| sean-k-mooney | which presumable was hypervior_hostname | 17:24 |
| bauzas | no | 17:24 |
| bauzas | host was in general the Host conf opt | 17:24 |
| sean-k-mooney | that would have been the compute service then not the comptue node | 17:25 |
| bauzas | always | 17:25 |
| sean-k-mooney | the usecase says "Operators wish to apply the same host aggregate to compute nodes in multiple cells." | 17:25 |
| bauzas | that was always the service | 17:25 |
| bauzas | because hostname key is about the n-cpu service | 17:25 |
| sean-k-mooney | the spec does not say service. an by the way im agreein gi tought this was also the service not the comptue node | 17:25 |
| sean-k-mooney | so the problem is context the pec that created the db table repataly says compute node | 17:26 |
| sean-k-mooney | so maybe the spec is wrong or not what we implemnted | 17:26 |
| bauzas | "Aggregates may be applied to compute nodes in multiple cells and are a global concept." | 17:27 |
| bauzas | this phrase is wrong | 17:27 |
| bauzas | Placement aggregates relate to resource providers | 17:27 |
| sean-k-mooney | right but this spec neverf mention compute services | 17:27 |
| sean-k-mooney | only compute nodes | 17:27 |
| bauzas | Nova aggregates related to nova-compute services | 17:27 |
| sean-k-mooney | so if i read the spec the intent seams to be to mapp compute nodes | 17:27 |
| bauzas | relate* | 17:28 |
| bauzas | sean-k-mooney: the intent of that spec was to put the aggregates table to the API DB | 17:28 |
| bauzas | not about desiging placement aggs | 17:28 |
| sean-k-mooney | i am not talking about placment aggs at all | 17:29 |
| sean-k-mooney | just nova | 17:30 |
| sean-k-mooney | im also reading our newton docs https://docs.openstack.org/nova/newton/aggregates.html | 17:30 |
| sean-k-mooney | whcih again talk about comptue nodes not compute services | 17:30 |
| bauzas | sure | 17:30 |
| bauzas | we also talk about ephemeral storage, remember ? :) | 17:31 |
| bauzas | but the fact is, I know how scheduling works and I know what we return | 17:31 |
| sean-k-mooney | yep but i know we have downstream docs about addign ironic does to host aggretes by uuid and i have seen that used in other place too | 17:31 |
| bauzas | we return a destination which is a hostame for calling the RPC API | 17:32 |
| sean-k-mooney | we return more then that | 17:32 |
| sean-k-mooney | or at least we provide more then that to the filters | 17:33 |
| sean-k-mooney | its not so much about what we return to the conductor | 17:33 |
| opendevreview | Merged openstack/nova master: Support evacuate with PCI in placement https://review.opendev.org/c/openstack/nova/+/854615 | 17:34 |
| sean-k-mooney | so lookign at the newton code it is in terms of the compute service | 17:37 |
| sean-k-mooney | we do https://github.com/openstack/nova/blob/808d36475103e373f1deb3344b6829ce68d6cdd5/nova/db/sqlalchemy/api.py#L533-L542 | 17:37 |
| bauzas | sean-k-mooney; I need to stop today's work :( | 17:38 |
| sean-k-mooney | bauzas: that ok | 17:39 |
| sean-k-mooney | anyway we need to look at the patch carfullly as it sound more liek a feature then a bug and im not sure it work fully | 17:39 |
| bauzas | sean-k-mooney: I was about to say it | 17:40 |
| bauzas | looks to me a new behavioural support | 17:40 |
| bauzas | hence not a bug | 17:40 |
| bauzas | and I'd prefer us to design it correctly | 17:40 |
| bauzas | as there could be corner cases | 17:40 |
| sean-k-mooney | well i think there are defintly usecase for supprotiing ironic with host aggreates | 17:41 |
| sean-k-mooney | but ya i think it needs a spec espcislly with the other ironic work that is in flight | 17:41 |
| bauzas | I'll quickly add a comment on that patch into that direction | 17:41 |
| bauzas | I won't use the -2 hammer yet as it's late | 17:42 |
| opendevreview | Kirill proposed openstack/nova-specs master: new spec: support of vnc console for ironic https://review.opendev.org/c/openstack/nova-specs/+/863773 | 18:19 |
| opendevreview | Dan Smith proposed openstack/nova master: Add virt/node module for stable uuids https://review.opendev.org/c/openstack/nova/+/863915 | 18:31 |
| opendevreview | Dan Smith proposed openstack/nova master: Pass service ref to init_host(), if exists https://review.opendev.org/c/openstack/nova/+/863916 | 18:31 |
| opendevreview | Dan Smith proposed openstack/nova master: Add get_available_node_uuids() to virt driver https://review.opendev.org/c/openstack/nova/+/863917 | 18:31 |
| opendevreview | Dan Smith proposed openstack/nova master: Persist existing node uuids locally https://review.opendev.org/c/openstack/nova/+/863918 | 18:31 |
| opendevreview | Dan Smith proposed openstack/nova master: WIP: Make resource tracker use UUIDs instead of names https://review.opendev.org/c/openstack/nova/+/863919 | 18:31 |
| opendevreview | Dan Smith proposed openstack/nova master: WIP: Detect host renames and abort startup https://review.opendev.org/c/openstack/nova/+/863920 | 18:31 |
| dansmith | gibi: I still need to do the undelete explicit test in ^ so I marked that penultimate one as WIP with a note, I just want to get a bunch of work pushed up for insurance | 18:31 |
| gibi | dansmith: ack | 18:32 |
| artom | Besides the tox thing (that is now fixed?) there are no further known gate issues? | 18:42 |
| sean-k-mooney | beseide the multiple tox thigns not that comes to mind | 18:42 |
| sean-k-mooney | artom: are you seing somthing or wonderifn if you can recheck | 18:43 |
| artom | Latter | 18:43 |
| sean-k-mooney | then i belive yes | 18:43 |
| artom | ✊✊ | 18:43 |
| sean-k-mooney | on master at least | 18:44 |
| sean-k-mooney | i dont know if all the pin patches are mergd on all the sable branches | 18:44 |
| gmann | pin patches only required on python-novaclient and others are taken care by the pinning in common place https://review.opendev.org/q/I442568a5f5900e593feb2b5527109e0aa79e5aa7+status:open | 18:45 |
| gmann | nova stable branches are all green https://review.opendev.org/q/topic:tox4-pin-testing | 18:45 |
| sean-k-mooney | cool ill appove the client patches now so | 18:46 |
| gmann | thanks | 18:46 |
| opendevreview | Dan Smith proposed openstack/nova master: Add get_available_node_uuids() to virt driver https://review.opendev.org/c/openstack/nova/+/863917 | 18:47 |
| opendevreview | Dan Smith proposed openstack/nova master: Persist existing node uuids locally https://review.opendev.org/c/openstack/nova/+/863918 | 18:47 |
| opendevreview | Dan Smith proposed openstack/nova master: WIP: Make resource tracker use UUIDs instead of names https://review.opendev.org/c/openstack/nova/+/863919 | 18:47 |
| opendevreview | Dan Smith proposed openstack/nova master: WIP: Detect host renames and abort startup https://review.opendev.org/c/openstack/nova/+/863920 | 18:47 |
| Kirill_ | sean-k-mooney: could you please confirm that now everything is good) https://review.opendev.org/c/openstack/nova-specs/+/863773 | 18:53 |
| opendevreview | Dan Smith proposed openstack/nova master: Add virt/node module for stable uuids https://review.opendev.org/c/openstack/nova/+/863915 | 18:56 |
| opendevreview | Dan Smith proposed openstack/nova master: Pass service ref to init_host(), if exists https://review.opendev.org/c/openstack/nova/+/863916 | 18:56 |
| opendevreview | Dan Smith proposed openstack/nova master: Add get_available_node_uuids() to virt driver https://review.opendev.org/c/openstack/nova/+/863917 | 18:56 |
| opendevreview | Dan Smith proposed openstack/nova master: Persist existing node uuids locally https://review.opendev.org/c/openstack/nova/+/863918 | 18:56 |
| opendevreview | Dan Smith proposed openstack/nova master: WIP: Make resource tracker use UUIDs instead of names https://review.opendev.org/c/openstack/nova/+/863919 | 18:56 |
| opendevreview | Dan Smith proposed openstack/nova master: WIP: Detect host renames and abort startup https://review.opendev.org/c/openstack/nova/+/863920 | 18:56 |
| sean-k-mooney | Kirill_: i think so but im to tired to review a spec fully this evning. skiming its in teh correct directory and since almost all the implemation is on the ironic sid eand ther eis no api changes this is likely sufficent | 19:00 |
| Kirill_ | got it. thanks for your efforts! | 19:01 |
| sean-k-mooney | im not sure if melwitt is around today but she might be able to provide more feedback today. otherwise ill take another look tomorow. you still need a second core to review and approvhe it in either case. | 19:03 |
| opendevreview | Ghanshyam proposed openstack/osc-placement stable/zed: [stable-only] Use stable branch version of placement in functional tests https://review.opendev.org/c/openstack/osc-placement/+/869753 | 19:07 |
| opendevreview | Ghanshyam proposed openstack/osc-placement stable/yoga: [stable-only] Use stable branch version of placement in functional tests https://review.opendev.org/c/openstack/osc-placement/+/869754 | 19:08 |
| opendevreview | Ghanshyam proposed openstack/osc-placement master: Use pypi released version of placement in functional tests https://review.opendev.org/c/openstack/osc-placement/+/869755 | 19:23 |
| opendevreview | Ghanshyam proposed openstack/osc-placement stable/zed: Use pypi released version of placement in functional tests https://review.opendev.org/c/openstack/osc-placement/+/869753 | 19:24 |
| opendevreview | Dan Smith proposed openstack/nova master: Add virt/node module for stable uuids https://review.opendev.org/c/openstack/nova/+/863915 | 19:25 |
| opendevreview | Dan Smith proposed openstack/nova master: Pass service ref to init_host(), if exists https://review.opendev.org/c/openstack/nova/+/863916 | 19:25 |
| opendevreview | Dan Smith proposed openstack/nova master: Add get_available_node_uuids() to virt driver https://review.opendev.org/c/openstack/nova/+/863917 | 19:25 |
| opendevreview | Dan Smith proposed openstack/nova master: Persist existing node uuids locally https://review.opendev.org/c/openstack/nova/+/863918 | 19:25 |
| opendevreview | Dan Smith proposed openstack/nova master: WIP: Make resource tracker use UUIDs instead of names https://review.opendev.org/c/openstack/nova/+/863919 | 19:25 |
| opendevreview | Dan Smith proposed openstack/nova master: WIP: Detect host renames and abort startup https://review.opendev.org/c/openstack/nova/+/863920 | 19:25 |
| opendevreview | Ghanshyam proposed openstack/osc-placement stable/yoga: Use pypi released version of placement in functional tests https://review.opendev.org/c/openstack/osc-placement/+/869754 | 19:28 |
| *** EugenMayer43 is now known as EugenMayer4 | 19:31 | |
| opendevreview | Ghanshyam proposed openstack/osc-placement master: Use pypi released version of placement in functional tests https://review.opendev.org/c/openstack/osc-placement/+/869755 | 19:58 |
| opendevreview | Ghanshyam proposed openstack/osc-placement stable/zed: Use pypi released version of placement in functional tests https://review.opendev.org/c/openstack/osc-placement/+/869753 | 20:23 |
| opendevreview | Ghanshyam proposed openstack/osc-placement stable/yoga: Use pypi released version of placement in functional tests https://review.opendev.org/c/openstack/osc-placement/+/869754 | 20:24 |
| opendevreview | Merged openstack/python-novaclient stable/zed: [stable-only] Pin tox <4 https://review.opendev.org/c/openstack/python-novaclient/+/869527 | 20:40 |
| opendevreview | Ghanshyam proposed openstack/osc-placement master: Use pypi released version of placement in functional tests https://review.opendev.org/c/openstack/osc-placement/+/869755 | 20:56 |
| opendevreview | Ghanshyam proposed openstack/osc-placement stable/xena: Use pypi released version of placement in functional tests https://review.opendev.org/c/openstack/osc-placement/+/869768 | 21:17 |
| gmann | sean-k-mooney: bauzas: gibi : these are the osc-placement gate fixes https://review.opendev.org/q/I4e3e5732411639054baaa9211a29e2e2c8210ac0 | 21:17 |
| opendevreview | Merged openstack/nova stable/victoria: Adapt websocketproxy tests for SimpleHTTPServer fix https://review.opendev.org/c/openstack/nova/+/866195 | 21:39 |
| dansmith | gmann: still around? | 22:14 |
| * dansmith will just comment on the roles review | 22:22 | |
| -opendevstatus- NOTICE: One of our CI job log storage providers appears to be having trouble with log uploads and retrievals. We are in the process of removing that provider from the pool. | 22:44 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!