| gibi | bauzas: ack | 07:24 |
|---|---|---|
| bauzas | ack of what ? :) | 07:24 |
| gibi | 16:08 < bauzas> gibi: sean-k-mooney: elodilles: fwiw, I'll hold RC2 until Thursday | 07:32 |
| bauzas | heh ok | 07:32 |
| gibi | that was the last thing you pinged me with :) | 07:32 |
| bauzas | I need to prepare the release rc2 patch | 07:32 |
| bauzas | but now I have some internal tool I need to run locally :D | 07:32 |
| bauzas | joys of flask apps | 07:33 |
| gibi | dont we have a container image published somewhere just to run it locally? | 07:42 |
| bauzas | gibi: my yearly compliance training tells me I shouldn't leak any internal tooling in an upstream chan that's logged :p | 07:49 |
| gibi | then dont :) | 08:04 |
| opendevreview | junbo proposed openstack/nova master: Test free memory if ram is not overcommit. https://review.opendev.org/c/openstack/nova/+/858495 | 08:27 |
| sean-k-mooney[m] | but but but what if we want too | 08:30 |
| sean-k-mooney[m] | stupid rules | 08:30 |
| sean-k-mooney[m] | ill be starting work in a bit but assuming my laptop has not disconnected i have that tool running locally on my laptop and i pinged you with the url yesterday bauzas if you just want to use my copy | 08:31 |
| * sean-k-mooney[m] goes to get coffee | 08:32 | |
| bauzas | I'll leave the Zanata patch up for reviews but if nobody looks at it until tonight, I'll fast-approve it as we always usually do https://review.opendev.org/c/openstack/nova/+/858232 | 09:44 |
| bauzas | tl;dr: updated translations for the Zed release | 09:44 |
| sean-k-mooney | hume the have a en_GB one i can review that at least | 09:45 |
| sean-k-mooney | im wondering if they actully change anything | 09:45 |
| sean-k-mooney | so far no | 09:46 |
| bauzas | no, in general this is chinese | 09:47 |
| bauzas | I updated one french translation iirc | 09:47 |
| bauzas | oh, actually, this is purely french :) | 09:49 |
| sean-k-mooney | the updates in the english one just moved words to differnt lines there is actully no change | 09:51 |
| sean-k-mooney | but anyway i +2w'd it | 09:51 |
| sean-k-mooney | i knwo the actual review of this happens else where so was just wondering what was changed | 09:51 |
| sean-k-mooney | i still kind of wish that this was done in a sperat repo so that project teams did not have to basically blinly apporve text changes to our repos without the ablity to ask for the content to be updated | 09:53 |
| opendevreview | Sahid Orentino Ferdjaoui proposed openstack/nova master: compute: enhance compute evacuate instance to support target state https://review.opendev.org/c/openstack/nova/+/858383 | 09:58 |
| opendevreview | Sahid Orentino Ferdjaoui proposed openstack/nova master: api: extend evacuate instance to support target state https://review.opendev.org/c/openstack/nova/+/858384 | 09:58 |
| opendevreview | Artem Goncharov proposed openstack/nova stable/yoga: DNM test openstacksdk project cleanup https://review.opendev.org/c/openstack/nova/+/858512 | 10:14 |
| opendevreview | Merged openstack/nova master: Imported Translations from Zanata https://review.opendev.org/c/openstack/nova/+/858232 | 10:15 |
| *** amorin_ is now known as amorin | 12:07 | |
| *** tosky is now known as Guest1012 | 12:14 | |
| *** tosky__ is now known as tosky | 12:14 | |
| *** tosky is now known as Guest1013 | 12:30 | |
| *** tosky__ is now known as tosky | 12:30 | |
| * bauzas goes paperworking on launchpad for the antelope series... | 12:53 | |
| bauzas | cores, easy peasy for an approval here https://review.opendev.org/c/openstack/osc-placement/+/856787 (osc-placement antelope python testing job) | 12:58 |
| bauzas | gibi: sean-k-mooney: ^ | 12:58 |
| sean-k-mooney | didnt i review that already | 13:00 |
| sean-k-mooney | ill look at it now | 13:00 |
| sean-k-mooney | i guess not | 13:00 |
| sean-k-mooney | bauzas: done | 13:00 |
| bauzas | thanks | 13:00 |
| bauzas | sean-k-mooney: we had a shit ton of identical patches against all our repos | 13:01 |
| bauzas | sean-k-mooney: that's probably why you had the feeling you did it already | 13:01 |
| sean-k-mooney | i think it was for os-vif | 13:04 |
| auniyal | how to check VM swap size ? | 13:04 |
| sean-k-mooney | in tempest? | 13:05 |
| auniyal | $ free -m | 13:05 |
| auniyal | total used free shared buffers cached | 13:05 |
| auniyal | Mem: 3936 63 3872 0 5 15 | 13:05 |
| auniyal | -/+ buffers/cache: 41 3894 | 13:05 |
| auniyal | Swap: 0 0 0 | 13:05 |
| sean-k-mooney | ssh to the vm and use lsblk | 13:05 |
| sean-k-mooney | well free -m will work if and only if you have done swap on | 13:05 |
| auniyal | yes, in tempest | 13:05 |
| sean-k-mooney | so would proably check if there is a disk with a swap partaion and or check its size if that is impoatnt to the test | 13:06 |
| auniyal | lsblk, gives size, but no column for swap | 13:07 |
| sean-k-mooney | auniyal: by the way you need to check if there is a an addtional disk (not the root disk) with a swap partion | 13:07 |
| sean-k-mooney | you would need to look at the filesystem/paretitio type | 13:08 |
| sean-k-mooney | with somethign like fdisk | 13:08 |
| sean-k-mooney | but i think lsblk can include that info | 13:08 |
| auniyal | $ cat /proc/swaps | 13:09 |
| auniyal | FilenameTypeSizeUsedPriority | 13:09 |
| auniyal | $ | 13:09 |
| auniyal | $ lsblk | 13:09 |
| auniyal | NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT | 13:09 |
| auniyal | vda 252:0 0 40G 0 disk | 13:09 |
| auniyal | |-vda1 252:1 0 40G 0 part / | 13:09 |
| auniyal | `-vda15 252:15 0 8M 0 part | 13:09 |
| auniyal | vdb 252:16 0 1G 0 disk | 13:09 |
| sean-k-mooney | that will only show swap if you did swapon | 13:09 |
| sean-k-mooney | to activate the swap | 13:09 |
| sean-k-mooney | lsblk -f | 13:09 |
| sean-k-mooney | will list the filesystem | 13:10 |
| auniyal | lsblk -f: it's showing, use and available, but nothing swap | 13:12 |
| auniyal | blkid, t | 13:16 |
| auniyal | blkid, this returns disk, and their type, if we have swap in flavor it show else not, | 13:17 |
| auniyal | @sean-k-mooney, we can use right ? | 13:17 |
| opendevreview | Merged openstack/osc-placement master: Switch to 2023.1 Python3 unit tests and generic template name https://review.opendev.org/c/openstack/osc-placement/+/856787 | 13:18 |
| auniyal | server with swap | 13:18 |
| auniyal | $ blkid | grep swap | 13:18 |
| auniyal | $ blkid | grep swap | 13:18 |
| auniyal | $ | 13:18 |
| auniyal | $ blkid | grep swap | 13:19 |
| auniyal | $ | 13:19 |
| auniyal | not sure,why its not coming here | 13:19 |
| auniyal | """$ blkid | grep swap | 13:19 |
| auniyal | $ """ | 13:19 |
| bauzas | auniyal: you need sudo rights | 13:21 |
| bauzas | but agreed with sean, best is to check the partitions | 13:21 |
| bauzas | some guest could swapoff | 13:21 |
| bauzas | I mean, some image | 13:22 |
| auniyal | oh, thanks bauzas, I was not using sudo with lsblk | 13:24 |
| bauzas | auniyal: you can also fdisk -l the partitions but you'll only get the devname | 13:27 |
| auniyal | can we use blkid, there also it shows dev name- http://pastebin.test.redhat.com/1074402 | 13:27 |
| bauzas | that's why blkid is better as you see this is swap | 13:28 |
| bauzas | yeah, as said, blkid is better for exactly knowing the partition type | 13:28 |
| auniyal | ack | 13:28 |
| bauzas | fdisk -l just shows you the device names | 13:28 |
| *** dasm|off is now known as dasm | 13:30 | |
| sean-k-mooney | blkid is ok | 13:30 |
| sean-k-mooney | we use it in tempest already | 13:30 |
| sean-k-mooney | blkid in cirros might however have less info | 13:31 |
| sean-k-mooney | so check it there too | 13:31 |
| bauzas | sean-k-mooney: do you know if cirros supports POSIX ? | 13:35 |
| auniyal | cirros has blkid, it showing swap | 13:35 |
| sean-k-mooney | bauzas: it uses busybox | 13:35 |
| sean-k-mooney | for many of the unitls | 13:35 |
| bauzas | I know | 13:35 |
| sean-k-mooney | blkid i dont think is part of posix | 13:35 |
| sean-k-mooney | but even if it is the options we need might not be | 13:35 |
| sean-k-mooney | i know for example the cirros imple of lspic is much more limited | 13:36 |
| sean-k-mooney | auniyal: ok if blkid is showing swap | 13:36 |
| sean-k-mooney | then all you have to do is assert the swap disk exsit seperatly from the root disk | 13:36 |
| sean-k-mooney | or not | 13:36 |
| sean-k-mooney | depending on the flavor | 13:37 |
| sean-k-mooney | some cloud image have swap baked into them | 13:37 |
| sean-k-mooney | so checking that the swap partion is not on the root image might be imporant | 13:37 |
| bauzas | https://man7.org/linux/man-pages/man8/blkid.8.html#AVAILABILITY | 13:37 |
| bauzas | so blkid is indeed in busybox | 13:37 |
| sean-k-mooney | https://github.com/brgl/busybox/blob/master/util-linux/blkid.c | 13:40 |
| sean-k-mooney | https://github.com/brgl/busybox/blob/abbf17abccbf832365d9acf1c280369ba7d5f8b2/util-linux/volume_id/get_devname.c#L231-L249 | 13:40 |
| sean-k-mooney | so it will print the type if the type is compiled in | 13:41 |
| sean-k-mooney | but it does nto actully use the args you pass | 13:41 |
| sean-k-mooney | unlikel the real blkid | 13:41 |
| bauzas | anyway, it should print the types exactly like linux | 13:41 |
| bauzas | so a grep on swap is doable | 13:42 |
| sean-k-mooney | yes but you cant contol the output or pass any flags | 13:42 |
| bauzas | yes | 13:42 |
| bauzas | but, pipe ftw ! | 13:42 |
| sean-k-mooney | well you can passs them it wont do anything so we shoudl keep it genic | 13:42 |
| sean-k-mooney | yep | 13:42 |
| bauzas | sean-k-mooney: agreed, just using the standard libs | 13:43 |
| bauzas | and the "posix" format | 13:43 |
| bauzas | (note the quotes) | 13:43 |
| bauzas | basically "blkid | grep swap" is portable | 13:43 |
| sean-k-mooney | ya | 13:43 |
| sean-k-mooney | although that may not work probely if the root disk has a swap partion | 13:44 |
| sean-k-mooney | i guess we dont care | 13:44 |
| sean-k-mooney | cirros does not i belive | 13:44 |
| sean-k-mooney | and ubunut/rhel i belive also do not have swap partions | 13:44 |
| sean-k-mooney | but if you use tempest with a vm image that does it would fail in that case | 13:45 |
| sean-k-mooney | anyway if we want to do more then "blkid | grep swap" | 13:45 |
| sean-k-mooney | i would instead just do "blkid" and do the rest in python | 13:46 |
| sean-k-mooney | in tempest | 13:46 |
| jkulik | melwitt: how come Nova depends on the unified-limits API while it's still marked as experimental in keystone docs? https://docs.openstack.org/keystone/latest/admin/unified-limits.html does that mean, we would need to upgrade Keystone and Nova in lockstep after yoga? | 13:48 |
| opendevreview | Stephen Finucane proposed openstack/nova stable/zed: Remove mentions of removed scheduler filters https://review.opendev.org/c/openstack/nova/+/858534 | 13:50 |
| opendevreview | Stephen Finucane proposed openstack/nova stable/yoga: Remove mentions of removed scheduler filters https://review.opendev.org/c/openstack/nova/+/858025 | 13:50 |
| opendevreview | Stephen Finucane proposed openstack/nova stable/xena: Remove mentions of removed scheduler filters https://review.opendev.org/c/openstack/nova/+/858024 | 13:51 |
| bauzas | stephenfin: hah | 13:52 |
| opendevreview | Stephen Finucane proposed openstack/nova stable/wallaby: Remove mentions of removed scheduler filters https://review.opendev.org/c/openstack/nova/+/858050 | 13:52 |
| bauzas | stephenfin: hold you brace and wait for Zed GA, my dear | 13:52 |
| bauzas | your* | 13:52 |
| stephenfin | eh, those shouldn't go into merge conflict. They can sit for a week or two. They're only docs | 13:52 |
| bauzas | reminder : nova meeting in 50 mins | 15:09 |
| bauzas | here* | 15:09 |
| opendevreview | Merged openstack/python-novaclient master: Remove unnecessary testing code https://review.opendev.org/c/openstack/python-novaclient/+/852949 | 15:10 |
| bauzas | cores, a review of https://review.opendev.org/c/openstack/nova-specs/+/856173 would be appreciated (moving implemented specs to the right path) | 15:33 |
| bauzas | last reminder : nova meeting in 9 misn | 15:51 |
| bauzas | (and I have a physical meetup just after the meeting, I'd appreciate if we could end early | 15:51 |
| bauzas | ) | 15:51 |
| bauzas | actually, this is a Java User Group, but I won't nitpick about it, if I'm able to get food, drink and see colleagues there | 15:52 |
| sean-k-mooney | bauzas: o sorry still didnt get to review that properly ill try and do it be fore the meeting | 15:55 |
| bauzas | sean-k-mooney: np at all | 15:55 |
| bauzas | we don't have a deadline | 15:56 |
| sean-k-mooney | i like to see it done before we start the new cycle properly | 15:59 |
| bauzas | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue Sep 20 16:00:47 2022 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 | hey all | 16:00 |
| gibi | o/ | 16:00 |
| elodilles | o/ | 16:00 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:01 |
| bauzas | let's start, people will come | 16:01 |
| bauzas | #topic Bugs (stuck/critical) | 16:01 |
| bauzas | #info No Critical bug | 16:02 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 5 new untriaged bugs (+0 since the last meeting) | 16:02 |
| bauzas | #link https://storyboard.openstack.org/#!/project/openstack/placement 26 open stories (+0 since the last meeting) in Storyboard for Placement | 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 |
| bauzas | sean-k-mooney: any bug you want to discuss here ? | 16:02 |
| bauzas | I saw you triaged some | 16:02 |
| sean-k-mooney | am not spcificaly | 16:03 |
| Uggla | o/ | 16:03 |
| bauzas | cool | 16:03 |
| sean-k-mooney | https://bugs.launchpad.net/nova/+bug/1989894 is a tirival fix | 16:03 |
| sean-k-mooney | 2 invalid and one incomplte | 16:04 |
| sean-k-mooney | i looked at the open bugs yesterday | 16:04 |
| sean-k-mooney | i have not looked today | 16:04 |
| bauzas | sean-k-mooney: thanks for your work | 16:04 |
| bauzas | sean-k-mooney: nothing changed | 16:04 |
| sean-k-mooney | cool | 16:04 |
| bauzas | elodilles: fancy getting the baton this week ? | 16:04 |
| elodilles | well, there are release duties, but let's try | 16:04 |
| sean-k-mooney | bauzas: actully one i should highligh breilfy | 16:05 |
| sean-k-mooney | https://bugs.launchpad.net/nova/+bug/1989357 is an rfe | 16:05 |
| sean-k-mooney | or rfe request | 16:05 |
| bauzas | you mean a blueprint request :) | 16:05 |
| sean-k-mooney | yes | 16:05 |
| sean-k-mooney | it shoudl be a spec | 16:05 |
| bauzas | we name it Wishlist :) | 16:05 |
| sean-k-mooney | desginate would like changing the instnace.hostname via an update | 16:05 |
| sean-k-mooney | to porpagate to the neutron ports/floating ip | 16:06 |
| dansmith | o/ | 16:06 |
| sean-k-mooney | and therefor into designate | 16:06 |
| bauzas | that reminds me a story :) | 16:06 |
| sean-k-mooney | so i think this could a use case to consider in the fqdn saga | 16:06 |
| sean-k-mooney | thats all i wanted to say on that | 16:06 |
| bauzas | agreed and we have a PTG topic for this | 16:07 |
| sean-k-mooney | so really a highlight to artom | 16:07 |
| * artom meerkats | 16:07 | |
| bauzas | sean-k-mooney: you'd be gentle if you could mention the fact we will discuss the usecase at the PTG | 16:07 |
| artom | Eh, wha, who, when? | 16:07 |
| bauzas | artom: it's all your fault, tl;dr | 16:07 |
| artom | It usually is | 16:08 |
| bauzas | sean-k-mooney: but I can write this in the bug report | 16:08 |
| sean-k-mooney | bauzas: well i could but its a new usecase to include in the discussion | 16:08 |
| bauzas | I guess they'd be interested in sharing their usecase | 16:08 |
| sean-k-mooney | but yes ill file in artom later | 16:08 |
| bauzas | sean-k-mooney: I don't disagree | 16:08 |
| sean-k-mooney | i think we can move on for the meeting | 16:08 |
| bauzas | yup | 16:08 |
| bauzas | elodilles: so, about your release duties, yeah that doesn't really help | 16:09 |
| bauzas | we can flip if you wish | 16:09 |
| elodilles | bauzas: probably no need to flip | 16:09 |
| * bauzas goes looking at the next person in the roster | 16:09 | |
| elodilles | i'll try | 16:09 |
| bauzas | oh heh, that's me | 16:09 |
| bauzas | elodilles: we can flip if you wish | 16:10 |
| elodilles | OK, thanks, if you insist :D | 16:10 |
| bauzas | elodilles: just because I want you having no reason to punt this | 16:11 |
| bauzas | :p | 16:11 |
| bauzas | ok, then | 16:11 |
| bauzas | #info bug baton is being passed to bauzas | 16:11 |
| elodilles | thanks o/ | 16:11 |
| bauzas | next, | 16:11 |
| bauzas | #topic Gate status | 16:11 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:11 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly Placement periodic job status | 16:11 |
| bauzas | #link https://zuul.openstack.org/builds?job_name=tempest-integrated-compute-centos-9-stream&project=openstack%2Fnova&pipeline=periodic-weekly Centos 9 Stream periodic job status | 16:12 |
| bauzas | #link https://zuul.opendev.org/t/openstack/builds?job_name=nova-emulation&pipeline=periodic-weekly&skip=0 Emulation periodic job runs | 16:12 |
| bauzas | all of the above is solid green | 16:12 |
| bauzas | so, moving on ? | 16:12 |
| bauzas | looks so | 16:13 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:13 |
| bauzas | #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures | 16:13 |
| bauzas | voila | 16:13 |
| bauzas | next, | 16:14 |
| bauzas | #topic Release Planning | 16:14 |
| bauzas | #link https://releases.openstack.org/zed/schedule.html | 16:14 |
| bauzas | even if we opened the Antelope series, we're still officially on Zed :) | 16:14 |
| bauzas | #info RC1 was last Thursday | 16:15 |
| bauzas | #info RC2 is planned this Thursday as we found one regression | 16:15 |
| bauzas | as said, the regression was identified and the bugfix delivered on time | 16:15 |
| elodilles | \o/ | 16:15 |
| bauzas | the stable/zed backport is merged, so this is now just a matter of holding the RC2 patch until a bit of time | 16:15 |
| gibi | and that bug is slipped becuse we don't test our lower constraints | 16:15 |
| bauzas | gibi: good point | 16:16 |
| elodilles | hmmm | 16:16 |
| gibi | we forgot to bump os-trait deps when we started depeding on 2.8.0 from it | 16:16 |
| bauzas | as a reminder, the master branch is now the antelope series | 16:16 |
| bauzas | as a reminder too, backports to stable/zed and later releases are consequently held until Zed is officially released in two weeks (Oct 5th) | 16:17 |
| bauzas | gibi: let's discuss this at the PTG | 16:17 |
| gibi | bauzas: good point, I can add a topic | 16:17 |
| bauzas | gibi: appreciated, thanks | 16:17 |
| bauzas | any question about RCs or anything else ? | 16:18 |
| bauzas | hah, also, I created the Launchpad antelope series | 16:18 |
| bauzas | (still TBD for novaclient) | 16:18 |
| bauzas | specs also have their antelope directory | 16:19 |
| bauzas | so, even if we aren't officially on Antelope, people shouldn't feel constrained by discussing next release | 16:19 |
| sean-k-mooney | well we are | 16:19 |
| sean-k-mooney | master is Antelope currently | 16:20 |
| bauzas | sean-k-mooney: from a git PoV, yes | 16:20 |
| sean-k-mooney | and form a schdule point of view | 16:20 |
| bauzas | sean-k-mooney: from an official release calendar, we aren't :D | 16:20 |
| sean-k-mooney | that is why i asked you to update launachpad | 16:20 |
| bauzas | https://releases.openstack.org/antelope/schedule.html | 16:20 |
| bauzas | we're in a grey period of time | 16:20 |
| bauzas | but anyway | 16:21 |
| bauzas | we're in a strong consensus, nothing prevents us to move forward and propose specs and blueprints | 16:21 |
| bauzas | this is said | 16:21 |
| sean-k-mooney | yep and even merging things but hold off on large refactors | 16:21 |
| bauzas | (personnally, I should try to write some spec next week) | 16:22 |
| sean-k-mooney | with that said i want to merge the new defaults change soon | 16:22 |
| gibi | +1 to land the default changes soo | 16:22 |
| gibi | n | 16:22 |
| bauzas | we're officially entering the tick-tock cadence btw. | 16:22 |
| sean-k-mooney | ill try and update that this week https://review.opendev.org/c/openstack/nova/+/830829 | 16:22 |
| bauzas | so yeah, config changes seem appropriate to be done in Antelope | 16:22 |
| bauzas | anyway, moving on | 16:23 |
| bauzas | #link https://etherpad.opendev.org/p/nova-zed-rc-potential Zed RC tracking etherpad | 16:23 |
| bauzas | I'll continue to ping a few people begging for reviews | 16:23 |
| bauzas | but should be seamless | 16:23 |
| bauzas | (just paperworking) | 16:24 |
| bauzas | next topic, | 16:24 |
| bauzas | #topic PTG planning | 16:24 |
| bauzas | as a reminder | 16:24 |
| bauzas | #link https://etherpad.opendev.org/p/nova-antelope-ptg Antelope PTG etherpad | 16:24 |
| bauzas | #link https://ptg.opendev.org/ptg.html PTG schedule | 16:24 |
| bauzas | people are welcome to add any topic they want to address at the PTG | 16:25 |
| bauzas | the earlier we have a solid list of things to discuss, the better it will be for planning in advance when to discuss those | 16:25 |
| bauzas | I have a question, | 16:26 |
| bauzas | shall we use a separate etherpad for ops-friendly sessions on Tuesday and Wednesday ? | 16:26 |
| bauzas | for the moment, in the list of etherpads, we have a specific etherpad for the nova-operator-hours https://etherpad.opendev.org/p/oct2022-ptg-operator-hour-nova | 16:26 |
| bauzas | of course, I can rename it, change it... or point to our developer etherpad | 16:26 |
| bauzas | I personnally feel a separate etherpad would be less scary for ops | 16:27 |
| gibi | if we expect a lot of operator feedback than I think it is better to have it on a separate etherpad | 16:27 |
| gibi | crosslinked with the main nova one | 16:27 |
| bauzas | but in this case, that means we need to come up in advance with a list of topics to address | 16:27 |
| bauzas | gibi: yup, I was thinking this | 16:27 |
| bauzas | ok, looks like it's sold | 16:28 |
| bauzas | noone is arguing | 16:28 |
| bauzas | but, | 16:28 |
| bauzas | this also means I feel we should do a bit of team brainstorm about what we'd like to discuss with ops at those hours | 16:28 |
| bauzas | don't tell me "pain points" this is the easiest | 16:29 |
| gibi | <del> <del> <del> | 16:29 |
| bauzas | anyway, I'll draft something before next week | 16:29 |
| bauzas | and we could discuss this then | 16:29 |
| gibi | open an etherpad and ping us with it I can put in some questions | 16:30 |
| bauzas | #action bauzas to draft some agenda for nova-operator-hours etherpad | 16:30 |
| bauzas | gibi: etherpad is already created, I just left the standard url | 16:30 |
| gibi | ack | 16:30 |
| bauzas | (the foundation pre-creates all the PTG project etherpads) | 16:30 |
| bauzas | well, "precreates" is actually just a matter of generating an URL | 16:31 |
| bauzas | anyway, moving on | 16:31 |
| bauzas | #topic Review priorities | 16:31 |
| 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:31 |
| bauzas | I'm happy to see sean-k-mooney using it :) | 16:32 |
| bauzas | and takashi too | 16:32 |
| sean-k-mooney | i have it as a review dashboard in gerrit | 16:33 |
| bauzas | you're more than encouraged to do as well ! | 16:33 |
| bauzas | sean-k-mooney: yeah, that's one possibility | 16:33 |
| sean-k-mooney | i have two i use commonly to look for reviews | 16:33 |
| bauzas | anyway, nothing to mention here ? | 16:33 |
| sean-k-mooney | the nova-priorty one and another one i got form stephen year ago | 16:34 |
| sean-k-mooney | nothing that cant wait until we are out of rc period | 16:34 |
| bauzas | cool | 16:34 |
| bauzas | #topic Stable Branches | 16:35 |
| bauzas | elodilles: shoot | 16:35 |
| elodilles | yes | 16:35 |
| elodilles | i had a quick look, | 16:35 |
| elodilles | so here is a quick update :) | 16:35 |
| elodilles | #info stable/yoga is blocked by openstacksdk-functional-devstack job -- proposed fix: https://review.opendev.org/c/openstack/openstacksdk/+/858268 | 16:35 |
| bauzas | :) | 16:35 |
| elodilles | new fix ^^^ | 16:35 |
| elodilles | #info stable/stein (and older) are blocked: grenade and other devstack based jobs fail with the same timeout issue as stable/train was previously | 16:35 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:35 |
| elodilles | and that's it :X | 16:35 |
| bauzas | thanks | 16:36 |
| elodilles | np | 16:36 |
| bauzas | last topic | 16:37 |
| bauzas | #topic Open discussion | 16:37 |
| bauzas | Add support for setting min/max unit for the VCPU and MEMORY_MB resource-providers in placement to values other than 1/all. Can configuration-options be OK for this, or are other approaches prefferred? See suggested use of configuration-options at https://review.opendev.org/c/openstack/nova/+/857595 | 16:37 |
| bauzas | unfortunately, the write hasn't written his nick | 16:37 |
| bauzas | but we can guess | 16:37 |
| obre | Its me :) | 16:37 |
| gibi | obre: o/ | 16:38 |
| bauzas | obre: yeah I was looking for your nick | 16:38 |
| obre | The use-case is basicly to allow restricting some compute-nodes to not get VM's using too many of its VCPU's. | 16:38 |
| obre | To better spread out load. | 16:38 |
| obre | I tested that changing these values give the desired outcome. | 16:39 |
| gibi | so I quickly dicussed with obre before and suggested extending provider.yaml but that might be a bigger work than what obre's use case needs | 16:39 |
| bauzas | I'm not fan of adding yet another knob to this | 16:39 |
| bauzas | so, yeah, provider.yaml or accepting that inventories can change from a client perspective | 16:39 |
| obre | It is a similar knob to the one we have setting over-provisioning of resources. | 16:40 |
| bauzas | obre: sure, but we designed placement for avoiding such knobs :) | 16:40 |
| sean-k-mooney | so we really shoudl not allow this to be configurable | 16:40 |
| gibi | bauzas: I'm not sure but I assume that today nova would periodically overwirte max_unit in placement for inventories its own | 16:40 |
| bauzas | gibi: correct | 16:41 |
| obre | I can confirm that assumption :) | 16:41 |
| gibi | obre: thanks :) | 16:41 |
| obre | So that logic needs to change then; in addition to allowing setting other inventorys than CUSTOM_* | 16:41 |
| sean-k-mooney | so the usecase here is to limit the max size of a flavor | 16:41 |
| bauzas | gibi: that's why I was saying that if operators want this to be tunable thru API calls, some efforts have to be done | 16:41 |
| sean-k-mooney | that can land on a host | 16:41 |
| obre | Either max or min. | 16:41 |
| sean-k-mooney | so we can do that today | 16:42 |
| sean-k-mooney | using provider.yaml | 16:42 |
| obre | No? | 16:42 |
| sean-k-mooney | to set those values no | 16:42 |
| bauzas | correct ^ | 16:42 |
| bauzas | we have a configurable | 16:42 |
| gibi | I think we cannot set those value on standard resources | 16:42 |
| bauzas | not an API call | 16:42 |
| obre | You are only allowed to set CUSTOM_*. Setting VCPUs for instance would make nova-compute refuse to start. | 16:42 |
| sean-k-mooney | gibi: i would be ok with lifting that restriction | 16:42 |
| bauzas | hah, my bad then | 16:43 |
| sean-k-mooney | but not adding a new config to nova for this | 16:43 |
| bauzas | sean-k-mooney: yeah, me too | 16:43 |
| bauzas | and yeah | 16:43 |
| bauzas | if operators want to play with nova inventories, I'm OK with this | 16:43 |
| gibi | sean-k-mooney: yepp, that was my suggestion to obre too, lift the provider.yamls restriction | 16:43 |
| bauzas | placement was designed for such usecases | 16:43 |
| obre | But then you would like to lift that restriction, and then have nova-compute check its inventories before setting the default-values if none exists? | 16:43 |
| sean-k-mooney | yes nova compute | 16:44 |
| sean-k-mooney | would instead of hardcoding its min/max/step values | 16:44 |
| obre | Basicly similar to how we do allocation_ratios; just without the config-file option. | 16:44 |
| gibi | yepp | 16:44 |
| sean-k-mooney | get tehm form provider.yaml | 16:44 |
| obre | Im not entirly sure I am able to figure all this out by myself; but Ill give it a try; and see if I can manage to write such a patch :) | 16:45 |
| gibi | obre: feel free to ping me here with questions. I can try to look at the code and help | 16:45 |
| obre | gibi: Thanks! | 16:46 |
| obre | gibi: I probably will. | 16:46 |
| gibi | I'm sure we have some unit / functional test coveragae on provider.yaml to play with | 16:46 |
| sean-k-mooney | we will need to modify the schma | 16:47 |
| bauzas | looks like we have an agreement and further steps to | 16:47 |
| sean-k-mooney | and introduce a new adjective(exisitng) https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/provider-config-file.html#provider-config-file-schema | 16:47 |
| bauzas | obre: the next step for you I guess is to write a blueprint | 16:47 |
| sean-k-mooney | and then lift the resticion on the resouce_class startign with CUSTOM_ | 16:48 |
| sean-k-mooney | so this would likely need a spec | 16:48 |
| bauzas | I was debating it | 16:48 |
| sean-k-mooney | to spell it out clearly | 16:48 |
| sean-k-mooney | it will need a new schema_version at a minium | 16:48 |
| gibi | I agree to have a small spec if we need to figure out a new schema | 16:49 |
| sean-k-mooney | i think there is enough of a change required that a spec would be helpful for documentation if nothing elses | 16:49 |
| bauzas | #agreed sounds a valid usecase that requires a blueprint and a spec to be filled in order to address how to properly manage inventories override by placement.yaml file | 16:49 |
| bauzas | obre: do you feel comfortable with this process ? do you need help ? | 16:49 |
| bauzas | or is that whole think old greek to you ? | 16:49 |
| bauzas | thing* | 16:49 |
| obre | bauzas: Ill probably need a bit of help yes. | 16:50 |
| bauzas | obre: you got my nick | 16:50 |
| obre | bauzas: Im not really a developer; more a sysadmin :P | 16:50 |
| bauzas | obre: ping me tomorrow and I'll point you some docs and examples | 16:50 |
| obre | bauzas: Whats your timezone? | 16:50 |
| bauzas | obre: well, specs are formal textfiles, so you shouldn't be afraid :) | 16:50 |
| bauzas | obre: CEST | 16:50 |
| * gibi is in CEST too | 16:50 | |
| * obre as well. | 16:51 | |
| bauzas | that matches then | 16:51 |
| obre | So then the workdays probably sync up :P | 16:51 |
| bauzas | I'm more than happy to help you | 16:51 |
| obre | bauzas: Great! | 16:51 |
| bauzas | our processes can look a bit scary but those are just design documents | 16:51 |
| bauzas | basically, the idea is just to identify all potential design concerns (upgrades or others) before they come up at review time | 16:52 |
| obre | Ill sorta understand why we need the formal process; Its just that I would have preffered an easier solution for _my_ problems :P | 16:52 |
| obre | But its fine :P | 16:52 |
| gibi | :) | 16:52 |
| bauzas | obre: you're litterally at the very beginning of the cycle :) | 16:52 |
| bauzas | so, you wouldn't hear 'sorry, too late' | 16:52 |
| bauzas | the point is, you have gibi and me for helping you out | 16:53 |
| obre | \o/ | 16:53 |
| sean-k-mooney | obre: one thing to think about is do you want this to be config driven. api driven or both | 16:53 |
| sean-k-mooney | we will need to document tha tin the spec | 16:53 |
| bauzas | sean-k-mooney: I tought we said config-driven | 16:53 |
| bauzas | as provider.yaml | 16:53 |
| sean-k-mooney | yes but provide.yaml can say -1 | 16:53 |
| sean-k-mooney | which means this is api contoled | 16:53 |
| sean-k-mooney | or something like that if we care about that usecase | 16:53 |
| bauzas | making it api-driven means we accept our inventories to be changed thru osc-placement | 16:54 |
| sean-k-mooney | so im assuming config driven is enough | 16:54 |
| obre | I think it makes sense to be as close to the way we do CUSTOM_* today as possible? | 16:54 |
| sean-k-mooney | and if so the that simple | 16:54 |
| bauzas | stick to the bare minimum requirements :) | 16:54 |
| bauzas | people could come up with api-driven needs later if they want to :) | 16:54 |
| sean-k-mooney | ok just that was going to be one of the question si would ask in the spec review | 16:54 |
| sean-k-mooney | so i didnt want it to come out of the blue | 16:55 |
| bauzas | sean-k-mooney good point, stating that api-driven is out of the spec seems reasonable | 16:55 |
| sean-k-mooney | yep we can state is as not a usecase we want to enabel now in the alternitives | 16:55 |
| bauzas | anyway, we're approaching end of time and we have a way forward | 16:55 |
| sean-k-mooney | obre: anyway as bauzas said keep it simple for now | 16:55 |
| obre | sean-k-mooney: Ack. | 16:55 |
| bauzas | anything to else to bring before we call it out ? | 16:56 |
| bauzas | looks not | 16:57 |
| bauzas | so, I hereby officially declare the meeting as over. | 16:57 |
| bauzas | thanks all | 16:57 |
| bauzas | #endmeeting | 16:57 |
| opendevmeet | Meeting ended Tue Sep 20 16:57:18 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:57 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-20-16.00.html | 16:57 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-20-16.00.txt | 16:57 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-20-16.00.log.html | 16:57 |
| elodilles | thanks bauzas o/ | 16:57 |
| gibi | thank you folks | 16:57 |
| gibi | I sign off for today now o/ | 16:57 |
| bauzas | me too | 16:57 |
| bauzas | Java time ! | 16:57 |
| sean-k-mooney | bauzas: gibi im going to push the default change | 16:57 |
| sean-k-mooney | shortly just an fyi | 16:57 |
| sean-k-mooney | runnign test now but ye can get to it tommorw or whenever | 16:58 |
| bauzas | sean-k-mooney: then, ping me once it's done | 16:58 |
| sean-k-mooney | sure | 16:58 |
| bauzas | sean-k-mooney: fwiw, I'll also try to reconnect with the tick-tock cadence | 16:58 |
| * sean-k-mooney currently cpu is sitting at a load average for 13.57 | 16:59 | |
| sean-k-mooney | this is not really impacted by tick-tock cadance | 16:59 |
| * bauzas thinks it's a good opportunity for sausage grill | 16:59 | |
| bauzas | sean-k-mooney: correct, that's what I was recollecting | 16:59 |
| bauzas | that's only B relnotes | 17:00 |
| bauzas | that need to be forward-ported to C | 17:00 |
| bauzas | IIRC | 17:00 |
| sean-k-mooney | am no it would be if it was a deprecation | 17:00 |
| sean-k-mooney | to remove a config option we would have to deprecate in A and then could remove in B | 17:00 |
| sean-k-mooney | but we cant depcreate in B and remove in C | 17:01 |
| bauzas | anyway, I'll be late for listening about microservices and serverless knative :) | 17:01 |
| sean-k-mooney | ack chat to you tomorrow | 17:01 |
| * bauzas shutdowns for the day | 17:01 | |
| sean-k-mooney | artom: you should read over https://bugs.launchpad.net/nova/+bug/1989357 | 17:04 |
| sean-k-mooney | as a potential usecase for the fqdn work | 17:04 |
| artom | sean-k-mooney, instance.hostname never changes, does it? | 17:05 |
| sean-k-mooney | it can | 17:05 |
| sean-k-mooney | in the micoversion that allowed you to set it in server create | 17:05 |
| sean-k-mooney | we also allowed it to be update with server update | 17:05 |
| sean-k-mooney | before 2.90 it cant | 17:05 |
| artom | Ah | 17:06 |
| johnsom | Oh, a new hostname chain. Will have to read the scrollback | 17:06 |
| sean-k-mooney | johnsom: you have not missed much | 17:06 |
| artom | Sounds like they're asking for https://review.opendev.org/c/openstack/neutron-specs/+/832658 to incorporate the possibility of the hostname changing | 17:06 |
| artom | Ah, hold no, no | 17:07 |
| artom | That's only for the domain | 17:07 |
| sean-k-mooney | https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/855870/2/neutron_tempest_plugin/scenario/test_dns_integration.py | 17:07 |
| sean-k-mooney | they wanted to change the server hostanme and see it refect in the ports | 17:07 |
| sean-k-mooney | the current test is changein displayname | 17:07 |
| artom | sean-k-mooney, it's still kinda different though | 17:08 |
| sean-k-mooney | that form the bug | 17:08 |
| sean-k-mooney | they are trying to make that work | 17:08 |
| artom | So there's 1. (the Neutron spec) Expose port/network/subnet's dns_domain to guest via DHCP | 17:08 |
| sean-k-mooney | yep | 17:09 |
| artom | 2. (Nova spec) Expose FQDN (instance.hostname + network dns_domain) in metadata | 17:09 |
| sean-k-mooney | yep | 17:09 |
| artom | 3. If any of the dns_ fields are updated, notify Designate | 17:09 |
| artom | Which... I'm not even sure how. | 17:09 |
| sean-k-mooney | no 3 | 17:09 |
| sean-k-mooney | is if i update the instnace.host in nova | 17:09 |
| sean-k-mooney | nova should update teh dns_ field in neutron | 17:10 |
| sean-k-mooney | and that should update desginate | 17:10 |
| artom | Wait, does the port store the *hostname*? | 17:10 |
| sean-k-mooney | yes | 17:10 |
| johnsom | yep | 17:10 |
| artom | Ah OK, that's easy enough then | 17:10 |
| artom | Why was it out of scope for stephenfin's initial spec? | 17:10 |
| sean-k-mooney | but so does the floating ip | 17:10 |
| sean-k-mooney | and they want that to work too | 17:11 |
| sean-k-mooney | and the port and floating ip can be differnt | 17:11 |
| johnsom | Almost always will be different | 17:11 |
| sean-k-mooney | typically just the domain but yes | 17:11 |
| sean-k-mooney | it can be both | 17:11 |
| sean-k-mooney | they are not ment to be linked | 17:11 |
| johnsom | right | 17:11 |
| sean-k-mooney | so in https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/855870/2/neutron_tempest_plugin/scenario/test_dns_integration.py | 17:12 |
| sean-k-mooney | they were trying to assert that updatign the server name update the name of the fip | 17:12 |
| sean-k-mooney | and that the old name was not found anymore | 17:12 |
| sean-k-mooney | line 145 and 146 | 17:13 |
| sean-k-mooney | im not conviced we shoudl do that | 17:13 |
| sean-k-mooney | but i wanted to highlight this usecase so we can definitly say nova should not do this or not in the spec | 17:13 |
| sean-k-mooney | i stongly feel like this is somethign you shoudl update in neutron and or desginate seperatly | 17:14 |
| johnsom | IMO nova should not "know" about floating IPs in neutron. | 17:15 |
| artom | IOO as well ;) | 17:16 |
| opendevreview | sean mooney proposed openstack/nova master: update default overcommit https://review.opendev.org/c/openstack/nova/+/830829 | 17:23 |
| sean-k-mooney | johnsom: ack there is a question of shoudl nova update the value on ports it created | 17:23 |
| sean-k-mooney | i.e. where you specified --network rather then a port uuid | 17:24 |
| sean-k-mooney | btu i agree on floating ips | 17:24 |
| johnsom | Yeah, I think an updated hostname field in nova should push down to those ports created for it. That makes sense. Though the guest won't get updated, but that is kind of expected. | 17:25 |
| sean-k-mooney | so there are 2 nova related feature propoasl that interacat with it | 17:25 |
| sean-k-mooney | artom is looking at maybe updating the metadata again | 17:25 |
| sean-k-mooney | and there is a user data update feature | 17:26 |
| sean-k-mooney | so if artoms feature is doen the metadata api woudl be updated | 17:26 |
| sean-k-mooney | wether the guest woudl actully use that i dont know | 17:26 |
| johnsom | Yeah, in the current reality, a guest wouldn't pick it up until a reboot. | 17:27 |
| sean-k-mooney | or later if the agent is not run on each reboot | 17:28 |
| sean-k-mooney | so i would like to know why they tohght that tempest test shoudl pass today | 17:29 |
| sean-k-mooney | i.e. updating vm name (hostname or dispaly name) would have any impact on neutron port or floating ips | 17:30 |
| johnsom | It certainly should not impact floating IPs. I guess ports makes sense if nova created the port, but I don't think it's implemented today. | 17:32 |
| sean-k-mooney | its not | 17:32 |
| sean-k-mooney | nova will only ever set this once | 17:32 |
| johnsom | Yeah, so sounds like an RFE | 17:32 |
| sean-k-mooney | and then never touch it again | 17:32 |
| sean-k-mooney | yep thats why i closed it as invlaid but even as an RFE request without more context im not really seing a usecase that would entiese me to add this to nova | 17:33 |
| sean-k-mooney | it in the nova should not do netowrking or orchstration bucket for me | 17:34 |
| johnsom | Oh, now there is a statement! grin | 17:34 |
| sean-k-mooney | partly because if we do we will likely get it wrong form someones perspective | 17:34 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!