| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-04-24 | |||
| 12:32:24 | opendevreview | ribaudr proposed openstack/nova master: Support resuming an instance with shares (compute and API part) https://review.opendev.org/c/openstack/nova/+/860285 | |
| 12:32:26 | opendevreview | ribaudr proposed openstack/nova master: Support rescuing an instance with shares (compute and API part) https://review.opendev.org/c/openstack/nova/+/860288 | |
| 12:32:26 | opendevreview | ribaudr proposed openstack/nova master: Support rescuing an instance with shares (driver part) https://review.opendev.org/c/openstack/nova/+/860287 | |
| 12:32:28 | opendevreview | ribaudr proposed openstack/nova master: Mounting the shares as part of the initialization process https://review.opendev.org/c/openstack/nova/+/880075 | |
| 12:32:28 | opendevreview | ribaudr proposed openstack/nova master: Docs about Manila shares API usage https://review.opendev.org/c/openstack/nova/+/871642 | |
| 12:42:13 | ralonsoh | sean-k-mooney, about PYTHON3_VERSION=3.9, I've tested that in Neutron and focal and doesn't work | |
| 12:42:23 | ralonsoh | even with https://review.opendev.org/c/openstack/devstack/+/881363 | |
| 12:43:06 | ralonsoh | about https://review.opendev.org/c/openstack/nova/+/868419, is it possible to merge this patch this week? that will unblock the Neutron CI | |
| 12:43:29 | ralonsoh | tested in https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/879036 | |
| 12:48:52 | sean-k-mooney | ralonsoh: well thats a problem since it was ment to be supported | |
| 12:49:20 | ralonsoh | 3.9 in focal? yes, we can install it | |
| 12:49:26 | ralonsoh | but uwsgi cannot | |
| 12:49:41 | sean-k-mooney | no i mean we had support for this in the past | |
| 12:49:57 | sean-k-mooney | so its obviously regressed in devstack | |
| 12:50:09 | ralonsoh | I'll check that | |
| 12:50:34 | sean-k-mooney | it proably regressed when the py2 support was remvoed | |
| 12:50:43 | sean-k-mooney | thats just a guess | |
| 12:50:51 | ralonsoh | from https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/881354 | |
| 12:50:54 | sean-k-mooney | but devstack is ment to support non default python versions | |
| 12:51:01 | ralonsoh | https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_a41/881354/2/check/neutron-tempest-plugin-openvswitch/a419d15/controller/logs/screen-keystone.txt | |
| 12:51:07 | ralonsoh | yes, devstack can | |
| 12:51:17 | ralonsoh | but it seems that focal uwsgi cannot | |
| 12:51:20 | bauzas | sean-k-mooney: ralonsoh: sorry, saw your pings, catching up | |
| 12:51:46 | sean-k-mooney | ralonsoh: we install uwsgi form pypi dont we? | |
| 12:52:02 | ralonsoh | let me check, one sec | |
| 12:52:26 | bauzas | sean-k-mooney: my main concern is that we are removing a python version support during a SLURP cadence | |
| 12:52:31 | sean-k-mooney | ralonsoh: maybe we dont but we might need to extxted devstack fixup script to work around it | |
| 12:52:34 | ralonsoh | sean-k-mooney, no, apt install | |
| 12:52:47 | sean-k-mooney | bauzas: yes and that perfectly fine to do | |
| 12:52:47 | bauzas | this means that operators need to prepare their computes *before* the SLURP upgrade | |
| 12:52:55 | sean-k-mooney | bauzas: yes that is intentional | |
| 12:53:00 | bauzas | by upgrading to 22.10 and py310 | |
| 12:53:04 | sean-k-mooney | no | |
| 12:53:09 | sean-k-mooney | by upgrading to 22.04 | |
| 12:53:13 | bauzas | whoops | |
| 12:53:18 | bauzas | 22.04 my bad | |
| 12:53:20 | sean-k-mooney | 22.04 use py310 | |
| 12:53:37 | sean-k-mooney | ya antelop is the release that supprot 22.04 and 20.04 | |
| 12:54:10 | bauzas | sean-k-mooney: my point is that I want to make sure that we can support the same python version and OS between SLURPs | |
| 12:54:12 | sean-k-mooney | ralonsoh: by they way we should not have any focal jobs on master right now | |
| 12:54:26 | sean-k-mooney | bauzas: we can py3.10 | |
| 12:54:31 | bauzas | at a SLURP release, operators can then upgrade | |
| 12:54:40 | ralonsoh | sean-k-mooney, that's right | |
| 12:54:44 | bauzas | sean-k-mooney: just checking yoga | |
| 12:54:54 | ralonsoh | but we still have the problem with nested virt | |
| 12:55:07 | sean-k-mooney | bauzas: yoga to antelope uses 20.04 and py 3.8 | |
| 12:55:17 | bauzas | https://governance.openstack.org/tc/reference/runtimes/yoga.html | |
| 12:55:24 | bauzas | ok, then I'm OK | |
| 12:55:35 | sean-k-mooney | then before you can SLURP to bobcat you have to do the 20.04 to 22.04 upgrade | |
| 12:55:45 | bauzas | operators can upgrade their OS to 20.04 and py3.8 during yoga | |
| 12:56:00 | bauzas | then they can skip-level upgrade to Antelope | |
| 12:56:17 | sean-k-mooney | yes and then upgrade there os to 22.04 | |
| 12:56:25 | bauzas | then, before skip-level upgrading again to C, they need to upgrade their computes to 22.04 and py310 | |
| 12:56:31 | sean-k-mooney | then slurp to 2024.1 | |
| 12:56:32 | bauzas | cool, then I accept the plan | |
| 12:56:51 | bauzas | sean-k-mooney: ok, then I'll clarify the context | |
| 12:57:03 | bauzas | sean-k-mooney: fwiw, I'm horrified we're pulling tooz as a dep for nova | |
| 12:57:15 | bauzas | just because of the ironic virt driver | |
| 12:57:18 | sean-k-mooney | its just for ironic and its going away | |
| 12:57:58 | sean-k-mooney | likely in 2024.2 assumign we get the shared supprot done in B or C | |
| 12:58:22 | sean-k-mooney | our aim shoudl be to deprecate teh peer list in b/C so it can go out in C and we can drop it in D | |
| 12:58:44 | sean-k-mooney | ralonsoh: what is the problem with ndested virt by the way | |
| 12:58:56 | ralonsoh | https://bugs.launchpad.net/neutron/+bug/1999249 | |
| 12:59:00 | sean-k-mooney | ralonsoh: you are aware that we are not ment to have any voting jobs that use it | |
| 12:59:06 | ralonsoh | timeouts in the jobs | |
| 12:59:50 | ralonsoh | so how we implement neutron-tempest-plugins jobs? | |
| 13:00:03 | sean-k-mooney | ralonsoh: they shoudl be useing QEMU not kvm | |
| 13:00:09 | sean-k-mooney | like all the nova jobs | |
| 13:00:42 | sean-k-mooney | ralonsoh: infra provied the abltiy to run josb with nested virt but we shoudl not have any voting jobs in any project that depend on them | |
| 13:01:08 | sean-k-mooney | ralonsoh: can you link to the job so i can confirm its actully using nested virt | |
| 13:01:14 | ralonsoh | sean-k-mooney, one sec | |
| 13:01:39 | sean-k-mooney | https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/857031/8/zuul.d/base-nested-switch.yaml#32 | |
| 13:01:42 | sean-k-mooney | so ya they are | |
| 13:01:49 | ralonsoh | https://github.com/openstack/neutron-tempest-plugin/blob/master/zuul.d/base-nested-switch.yaml | |
| 13:01:53 | ralonsoh | exactly | |
| 13:02:21 | sean-k-mooney | im kind of surpised that you have those since we were ask not to use the nested virt lables in any voting job | |
| 13:02:37 | sean-k-mooney | ralonsoh: what is the reason you are using nested virt there | |
| 13:02:50 | ralonsoh | sean-k-mooney, I can't reply to this, tbh | |
| 13:02:53 | sean-k-mooney | what kvm only funcitonality is neutron testing tha twould justify that | |
| 13:03:03 | ralonsoh | yk^^ | |
| 13:03:08 | ralonsoh | one sec | |
| 13:03:33 | sean-k-mooney | to be clare we have some kvm only fucntionliyt in nova we do not test sicne we did not have enough cloud provider to be comfortable with having a votign job | |
| 13:03:40 | ralonsoh | ykarel, hi! | |
| 13:03:46 | ykarel | hi ralonsoh | |
| 13:03:48 | ralonsoh | let me ask you the same question | |
| 13:04:00 | ralonsoh | what is the reason you are using nested virt there | |
| 13:04:08 | ralonsoh | in n-t-p | |
| 13:05:18 | ykarel | ralonsoh, context in https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/821067 | |
| 13:05:34 | ykarel | linked etherpad have more details | |
| 13:07:20 | ralonsoh | ykarel, then I think, for now, we should move to Jammy and non nested | |
| 13:07:44 | sean-k-mooney | ykarel: you realsie that we are not ment to have any voting job that use nested virt since we have not enough ci priorse for it. we were asked in teh past not to make any voting jobs unless we had 3 providers for it | |
| 13:08:05 | sean-k-mooney | it looks like we now have 2 clouds form vexhost and one form ovh | |
| 13:08:15 | sean-k-mooney | is this why this was made to use nested virt | |
| 13:08:22 | ykarel | sean-k-mooney, when we moved i recall there were 3 providers, need to check current status | |
| 13:08:26 | sean-k-mooney | i am not aware fo any anochment that it was now ok to do this | |
| 13:08:50 | sean-k-mooney | ykarel: so nested virt should only be used if a job needs it | |
| 13:09:02 | sean-k-mooney | what in this tempest plug need nested virt | |
| 13:09:59 | sean-k-mooney | we were previosuly asked not to enable it just to make the job faster to concerve the capsity | |
| 13:10:09 | ykarel | sean-k-mooney, yes right nothing in those tests need nested virt, the switch was done just for better perf/times in jobs, and that worked great for us for almost an year before hte switch to jammy | |
| 13:10:09 | ralonsoh | no one in particular, that was to improve the current stability of our jobs | |