opendevreview | melanie witt proposed openstack/nova-specs master: Propose tooling and docs for unified limits https://review.opendev.org/c/openstack/nova-specs/+/887014 | 01:52 |
---|---|---|
opendevreview | Ghanshyam proposed openstack/nova-specs master: Re-propose "Policy service role spec" https://review.opendev.org/c/openstack/nova-specs/+/881880 | 04:33 |
opendevreview | Amit Uniyal proposed openstack/os-vif stable/wallaby: set default qos policy https://review.opendev.org/c/openstack/os-vif/+/886778 | 05:39 |
opendevreview | Amit Uniyal proposed openstack/os-vif stable/wallaby: Move mtu update request into ovsdb transaction https://review.opendev.org/c/openstack/os-vif/+/887017 | 05:39 |
bauzas | happy spec review day everyone | 07:13 |
*** elodilles_pto is now known as elodilles | 07:22 | |
opendevreview | Amit Uniyal proposed openstack/os-vif stable/wallaby: set default qos policy https://review.opendev.org/c/openstack/os-vif/+/886778 | 07:30 |
*** efried1 is now known as efried | 07:47 | |
zigo | sean-k-mooney[m]: bauzas: You guys remember I reported that some of my bullseye instances wouldn't live-migrate with an issue in virtio? It appears that the Qemu package in Bullseye has the typo described here: | 09:07 |
zigo | https://bugzilla.redhat.com/show_bug.cgi?id=1984401#c34 | 09:07 |
zigo | I'm currently rebuilding a new version of the Qemu package with the fix, I'll let you know if this really fixes the issue ! :) | 09:07 |
zigo | Gosh, all this for just one char ... | 09:07 |
bauzas | ok | 09:10 |
opendevreview | Sylvain Bauza proposed openstack/nova-specs master: Re-propose spec for ephemeral storage encryption https://review.opendev.org/c/openstack/nova-specs/+/887011 | 09:15 |
opendevreview | Merged openstack/nova-specs master: Re-propose spec for ephemeral encryption for libvirt https://review.opendev.org/c/openstack/nova-specs/+/887012 | 09:29 |
opendevreview | John Garbutt proposed openstack/nova master: Add nova-manage ironic-compute-node-move https://review.opendev.org/c/openstack/nova/+/886989 | 09:46 |
sean-k-mooney1 | "vitio-balloon-device/page-poison", | 09:49 |
sean-k-mooney1 | i see | 09:49 |
*** sean-k-mooney1 is now known as sean-k-mooney | 09:53 | |
opendevreview | John Garbutt proposed openstack/nova master: Deprecate ironic.peer_list https://review.opendev.org/c/openstack/nova/+/883346 | 10:06 |
opendevreview | John Garbutt proposed openstack/nova master: Limit nodes by ironic shard key https://review.opendev.org/c/openstack/nova/+/886980 | 10:06 |
opendevreview | John Garbutt proposed openstack/nova master: Add nova-manage ironic-compute-node-move https://review.opendev.org/c/openstack/nova/+/886989 | 10:06 |
*** tobias-urdin is now known as tobias-urdin-pto | 10:43 | |
opendevreview | Amit Uniyal proposed openstack/os-vif stable/wallaby: set default qos policy https://review.opendev.org/c/openstack/os-vif/+/886778 | 10:58 |
sahid | o/ qucik question guys, have we a tool to clean old deleted instances in database? some sort of housecleaning job | 11:55 |
sahid | hum looks like nova-manage is the tool that i'm looking for | 11:59 |
sean-k-mooney | yep the archive-delete-rows and prune commands | 12:06 |
sean-k-mooney | we generally recommend runing those in a corn job using --before | 12:06 |
sean-k-mooney | so arcive all delete insace ofver 30ds and pruge them after 90 days | 12:07 |
sean-k-mooney | run that at least daily in cron | 12:07 |
sean-k-mooney | with max rows set high enogugh to ensure there is no build up over time | 12:07 |
sean-k-mooney | https://docs.openstack.org/nova/latest/cli/nova-manage.html#db-archive-deleted-rows and https://docs.openstack.org/nova/latest/cli/nova-manage.html#db-purge | 12:08 |
sahid | i was actually scary to set a max rows too high, and falldown in a timeout, perhaps having the cron running several times a day with max rows small is better, no? | 12:09 |
sean-k-mooney | you should not hit any time out but it will lod the db | 12:09 |
sean-k-mooney | you can do it severlal timees a day but honestly if thise casus an issue on your cloud you have undersided your DB | 12:10 |
sahid | yes that is right, we perhaps have to care of that the first time | 12:12 |
sean-k-mooney | i wourd personlaly do something like nova-manage db archive_deleted_rows --until-complete --before $(date -I -d '-1 month') --all-cells --task-log | 12:12 |
opendevreview | Pierre Libeau proposed openstack/nova master: Use admin_client to allocate port for instance https://review.opendev.org/c/openstack/nova/+/861172 | 12:14 |
zigo | I can confirm that the one char patch that I decribed at https://bugs.debian.org/1039567 fixes the live-migration of VMs with page_poison activated. | 13:06 |
zigo | :) | 13:06 |
*** blarnath is now known as d34dh0r53 | 13:26 | |
sean-k-mooney | zigo: congrats sorry it took so long to figure it out but good to know that is coming to repo near by soon | 13:59 |
zigo | I already upgraded the unofficial debian.net repo with my custom patched qemu, and will try to upgrade official Bullseye! :) | 13:59 |
sahid | sean-k-mooney: ack thanks ! | 14:28 |
opendevreview | Amit Uniyal proposed openstack/os-vif stable/yoga: set default qos policy https://review.opendev.org/c/openstack/os-vif/+/886710 | 14:30 |
opendevreview | Amit Uniyal proposed openstack/os-vif stable/yoga: set default qos policy https://review.opendev.org/c/openstack/os-vif/+/886710 | 14:45 |
opendevreview | Amit Uniyal proposed openstack/os-vif stable/xena: set default qos policy https://review.opendev.org/c/openstack/os-vif/+/886716 | 14:49 |
opendevreview | Amit Uniyal proposed openstack/os-vif stable/yoga: set default qos policy https://review.opendev.org/c/openstack/os-vif/+/886710 | 15:01 |
bauzas | reminder : nova meeting in 55 mins here | 15:06 |
opendevreview | Amit Uniyal proposed openstack/os-vif stable/xena: set default qos policy https://review.opendev.org/c/openstack/os-vif/+/886716 | 15:10 |
opendevreview | Amit Uniyal proposed openstack/nova master: Added context manager for instance lock https://review.opendev.org/c/openstack/nova/+/873648 | 15:17 |
opendevreview | Amit Uniyal proposed openstack/nova master: Disconnecting volume from the compute host https://review.opendev.org/c/openstack/nova/+/877446 | 15:17 |
bauzas | #startmeeting nova | 16:01 |
opendevmeet | Meeting started Tue Jun 27 16:01:26 2023 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:01 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:01 |
opendevmeet | The meeting name has been set to 'nova' | 16:01 |
bauzas | hey folks \o | 16:01 |
elodilles | o/ | 16:01 |
auniyal | o/ | 16:01 |
gibi | o\ | 16:01 |
bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:01 |
bauzas | ok let's start while the folks are arriving :) | 16:02 |
bauzas | #topic Bugs (stuck/critical) | 16:03 |
bauzas | #info No Critical bug | 16:03 |
bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 31 new untriaged bugs (+4 since the last meeting) | 16:03 |
Uggla_ | o/ | 16:03 |
bauzas | I only had time to look at two bugs this week | 16:03 |
bauzas | sorriy | 16:03 |
bauzas | I can try to look at the bugs this new week | 16:03 |
bauzas | okay, nobody is against | 16:05 |
bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:05 |
bauzas | #info bug baton is being passed to bauzas | 16:05 |
gibi | I would be super suprised if somebody want to stole the baton :D | 16:05 |
bauzas | do people want to discuss on bugs ? | 16:05 |
bauzas | gibi: :) | 16:05 |
bauzas | looks not | 16:06 |
bauzas | #topic Gate status | 16:06 |
bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:06 |
bauzas | it looks to me we have a new bug :( | 16:07 |
bauzas | #link https://bugs.launchpad.net/nova/+bug/2025096 | 16:07 |
dansmith | it's been skipped for now, | 16:07 |
dansmith | but that appears to just have not been tested on ceph and something is wrong with it in that environment | 16:07 |
dansmith | I'm not sure about the non-ceph assertion in the comment, I'll have to look | 16:08 |
bauzas | dansmith: ack | 16:08 |
dansmith | but that's a test we should have landed a year ago | 16:08 |
dansmith | and it just got merged | 16:08 |
bauzas | I was looking at Zuul | 16:08 |
bauzas | anyway, like you say, the job is not failed https://zuul.openstack.org/builds?job_name=nova-ceph-multistore&skip=0 | 16:09 |
bauzas | dansmith: https://b932a1446345e101b3ef-4740624f0848c8c3257f704064a4516f.ssl.cf5.rackcdn.com/883557/2/check/nova-ceph-multistore/d7db64f/testr_results.html | 16:10 |
bauzas | the test is not skipped | 16:10 |
dansmith | https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/887003 | 16:11 |
dansmith | we should be inheriting from that afaik | 16:11 |
bauzas | ahah | 16:12 |
bauzas | ok | 16:12 |
dansmith | why do you say it's not skipped? | 16:12 |
bauzas | gmann: could you add a new change for skipping test_rebuild_volume_backed_server on nova-ceph-multistore | 16:12 |
bauzas | ? | 16:12 |
bauzas | dansmith: oh wait, verifying | 16:13 |
dansmith | the patch specifically calls out the nova job | 16:13 |
bauzas | yeah, you're right, the test is now skipped | 16:14 |
bauzas | gmann: nevermind what I said | 16:14 |
bauzas | https://6354f24cae23db064c15-540aa9666e0f6140cd4132fd113878d1.ssl.cf5.rackcdn.com/876075/14/check/nova-ceph-multistore/617bfe5/testr_results.html I don't see the test | 16:14 |
bauzas | dansmith: sorry, I misunderstood what you said | 16:14 |
dansmith | ..okay | 16:15 |
bauzas | dansmith: sometimes my brain doesn't run correctly | 16:15 |
bauzas | :( | 16:16 |
bauzas | anyway, moving on | 16:16 |
bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | 16:16 |
bauzas | nothing to relate | 16:16 |
bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:16 |
bauzas | #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures | 16:16 |
bauzas | (I could remove this note next week) | 16:17 |
bauzas | moving on then, unless folks want to discuss on some other CI failures | 16:17 |
bauzas | #topic Release Planning | 16:17 |
bauzas | #link https://releases.openstack.org/bobcat/schedule.html | 16:18 |
bauzas | #info Nova deadlines are set in the above schedule | 16:18 |
bauzas | #info Nova spec review day today (June 27th) | 16:18 |
bauzas | I started to review a few specs | 16:18 |
bauzas | I approved one | 16:18 |
bauzas | I still have two other specs to look at | 16:18 |
bauzas | if I don't have time to look at them today, I'll continue to review the specs tomorrow | 16:19 |
bauzas | and tomorrow, I'll add an etherpad about the already merged specs and their code | 16:19 |
bauzas | as an important reminder, | 16:19 |
bauzas | #link https://releases.openstack.org/bobcat/schedule.html#b-nova-spec-freeze Nova Spec Freeze on July 6th ! | 16:20 |
bauzas | which is next week | 16:20 |
bauzas | most of the specs I've seen already have implementation changes | 16:20 |
bauzas | so thanks folks for that | 16:20 |
bauzas | anything anyone that wants to discuss on either specs or our release planning ? | 16:21 |
bauzas | - | 16:21 |
bauzas | moving on then | 16:22 |
bauzas | #topic Stable Branches | 16:22 |
bauzas | elodilles: wants to discuss anything ? | 16:22 |
elodilles | bauzas: nope, actually | 16:22 |
bauzas | cool cool | 16:22 |
elodilles | not much happened recently | 16:22 |
elodilles | around stable | 16:22 |
bauzas | #info stable gates should be OK (from stable/2023.1 to stable/train) | 16:22 |
bauzas | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:22 |
bauzas | elodilles: no news is good :) | 16:22 |
elodilles | :) | 16:23 |
bauzas | #info train-eol patch proposed https://review.opendev.org/c/openstack/releases/+/885365 | 16:23 |
bauzas | elodilles: I've seen your comment | 16:23 |
elodilles | yepp, it needs an update | 16:23 |
bauzas | so you're also asking to EOL placement, os-vif, os-resource-classes, and the clients ? | 16:23 |
bauzas | I can work on it | 16:24 |
elodilles | yes, i guess those would be good to EOL together | 16:24 |
elodilles | with nova | 16:24 |
elodilles | as no reason to keep them in EM, right? | 16:24 |
elodilles | without nova... | 16:24 |
bauzas | elodilles: also, my question is, shall we abandon the changes in the stable branches, or would it be done automatically ? | 16:24 |
gibi | os-traits and os-resource classes should be tight to the placement eol | 16:24 |
elodilles | they need to be abandoned, there's no automation | 16:25 |
bauzas | elodilles: for os-vif and novaclient, sounds ok | 16:25 |
bauzas | for placement dependencies, I'm quite torn | 16:25 |
gibi | but os-traits might also be used be neutron | 16:25 |
bauzas | gibi: good call, then let's stick to os-vif and novaclient | 16:25 |
elodilles | i guess if nova eol's it's train branch then maybe other projects will do the same | 16:26 |
bauzas | we could discuss about EOLing placement and its deps on another change | 16:26 |
gibi | bauzas: os-vif is also used by neutron for sure | 16:26 |
elodilles | (and i won't insist to keep open neutron either in that case o:) | 16:26 |
bauzas | elodilles: I've heard other projects that would EOL *all* their EM branches but I haven't seen yet any change :) | 16:26 |
gibi | python-novaclient is used by cinder and neutron for the external events no? | 16:26 |
elodilles | bauzas: yes, i only seen the cinder patch yet | 16:26 |
bauzas | gibi: good point, let's then be conservative and only EOL novaclient | 16:27 |
gibi | also heat probably uses nova-pythonclient | 16:27 |
bauzas | elodilles: what have we done when we EOL'd Stein ? | 16:27 |
gibi | can we delete all the train branches at once? :D | 16:27 |
bauzas | I thought nova did it in advance | 16:27 |
elodilles | heat is already EOL'd up to ussuri | 16:27 |
elodilles | bauzas: if you ask about the open patches: i ussually abandon the patches to be able to delete the branch :) | 16:28 |
elodilles | so i can abandon them whenever there is a decision | 16:28 |
bauzas | elodilles: so I need to click on *every* open patch to abandon it ? | 16:28 |
bauzas | disclaimer, my office room is 28°C now, my brain is absolutely fried. | 16:29 |
elodilles | bauzas: i can do that (there aren't many open patches) | 16:29 |
bauzas | so, what's the outcome of this long conversation , | 16:30 |
bauzas | ? | 16:30 |
elodilles | here the temperature is quite moderate now 21°C :) | 16:30 |
bauzas | I guess only nova and novaclient can be EOL now | 16:30 |
bauzas | elodilles: it's 28°C *inside* my room (I don't have any A/C) | 16:30 |
gibi | bauzas: I'm not sure about python-novaclient | 16:30 |
bauzas | okay, so let's be strict | 16:31 |
bauzas | and only EOL nova | 16:31 |
sean-k-mooney | EOLign should not break others as we are just closing the branch and tagging it | 16:31 |
bauzas | elodilles: fancy revisiting your comment ? | 16:31 |
sean-k-mooney | and libs like os-vif are installed form pypi by default | 16:31 |
sean-k-mooney | at most we would need a overdied-checkout for os-vif to poitn to the eol tag unless i missed something | 16:32 |
elodilles | bauzas: i still think it's better to EOL all the other nova projects in the same go | 16:32 |
sean-k-mooney | ya same ^ | 16:32 |
bauzas | gibi: agree then ? | 16:32 |
gibi | elodilles: sure, but then somebody need to handle the fallout | 16:33 |
elodilles | gibi: by fallout you mean? | 16:33 |
gibi | other project's job is failing to check out the deleted branch | 16:33 |
gibi | as an exmple | 16:34 |
gibi | example | 16:34 |
elodilles | yeah, that probably needs to be fixed (and honestly, more like EOL'ing everything else | 16:34 |
bauzas | I guess we need to work on this closely | 16:34 |
bauzas | AFAIK I tried to look at the jobs to find the ones that use stable/train branch of nova | 16:35 |
elodilles | btw, was there any result of the PTG forum session about the EM story? | 16:35 |
bauzas | and unfortunately, I have no crazy idea on how to get a list of such jobs | 16:35 |
elodilles | i haven't seen news on ML about that | 16:35 |
bauzas | since the job definitions are in the project repos, I would have to discover every single git repo in order to ensure this isn't the case :( | 16:36 |
gibi | elodilles: the result was to follon on the ML | 16:36 |
bauzas | elodilles: about that, the conclusion is mostly that the TC will discuss this | 16:36 |
bauzas | and yeah, follow on the ML | 16:36 |
elodilles | bauzas: yes, looking for those jobs is a bit tricky, the "easiest" maybe to compare with ussuri's .zuul.yaml and what jobs were removed there | 16:37 |
bauzas | tl;dr: no agreement was there to stop the EM experience, but a clarification was needed. | 16:37 |
bauzas | elodilles: you mean stein ? | 16:37 |
elodilles | bauzas: OK, so we either rush forward with the train EOL patch or wait then until tc discussion happens? | 16:38 |
* bauzas is lost in translation | 16:38 | |
bauzas | (and again, the room temperature doesn't help) | 16:38 |
sean-k-mooney | the TC discussion is about EM as a whole and would affect everythin before ZED | 16:38 |
bauzas | elodilles: not sure any conclusion would hit our EOL of train | 16:38 |
sean-k-mooney | i think we can EOL train regardless of what happens for the newer EM branchs | 16:38 |
bauzas | righjt | 16:39 |
dansmith | for sure | 16:39 |
elodilles | bauzas: not stein, ussuri. the job, that is removed in ussuri probably was last used in train, thus its definition can be deleted (if it is outside of nova repo) | 16:39 |
bauzas | and IIRC, EM will continue to exist in some form | 16:39 |
bauzas | maybe the M of EM carries too much context, but the idea is that we'll continue to have other branches | 16:40 |
gibi | I agree to drop train regardless of the TC discussion | 16:40 |
bauzas | those branches could be somewhere else, but that's an alternative to discuss yet | 16:40 |
bauzas | elodilles: again, lost in translation but I'll ping you tomorrow about it | 16:40 |
elodilles | OK, anyway, i think the 'fallout' will happen regardless we EOL only nova. EM / EOL'ing would be confusing if even within a project would be mixed | 16:40 |
elodilles | bauzas: sure, we can check it outside of the meeting :) | 16:41 |
bauzas | on a morning, with a fresh room temperature, a rested brain and a coffee, please. | 16:41 |
elodilles | bauzas: ++ :) | 16:42 |
bauzas | anyway, doesn't sound there is a change in direction | 16:42 |
bauzas | I guess we're done on that topic anyway | 16:42 |
elodilles | ++ | 16:42 |
bauzas | #topic Open discussion | 16:42 |
bauzas | I have one thing | 16:42 |
bauzas | (bauzas) Specless blueprint approval request for https://blueprints.launchpad.net/nova/+spec/num-instances-weigher | 16:42 |
bauzas | tl;dr: some operators said during the PTG that they were having some problems for spreading between heteregenous hardware | 16:43 |
bauzas | so we found we missed a weigher | 16:43 |
bauzas | we already have a filter for making sure a host can't have more than a max number of instances | 16:44 |
gibi | +1 to have this | 16:44 |
gibi | it is a quick and easy win | 16:44 |
bauzas | but it doesn't spread the hosts | 16:44 |
dansmith | yup | 16:45 |
bauzas | there is a current discussion on the already-provided code change https://review.opendev.org/c/openstack/nova/+/886232 | 16:45 |
bauzas | the concern is that we have a negative default value for spreading | 16:46 |
sean-k-mooney | whihc is not realted to if we shoudl have the weigher. im ok wigher jsut dislike that we have to default to -1 to spread when positive multipes are normally spread since we spread by default | 16:46 |
sean-k-mooney | yep so after some other discussion i woudl just prefer you retrined the number of instance * -1.0 | 16:46 |
sean-k-mooney | and default to 1.0 | 16:46 |
bauzas | sean-k-mooney: yeah and I understand your concern but my point is that I don't want to have a max-instances value that would be the same for all hosts | 16:47 |
sean-k-mooney | that is a prefernce not a blocker | 16:47 |
sean-k-mooney | yep which is why i provided two suggestion orginally | 16:47 |
gibi | hm, how the -1 relates to the max-instance? | 16:47 |
sean-k-mooney | it does not | 16:48 |
sean-k-mooney | i provided 2 suggestsions | 16:48 |
sean-k-mooney | return max_instace- current | 16:48 |
bauzas | sean-k-mooney: okay, so you would be okay if _weigh_object() would just do -1 * host_state.num_instances ? | 16:48 |
sean-k-mooney | or return current * -1.0 | 16:48 |
sean-k-mooney | yep | 16:48 |
sean-k-mooney | tottaly fine with that | 16:48 |
gibi | The -1.0 one works for me. I would not complicate it with the max-instance | 16:48 |
bauzas | sean-k-mooney: as I said in https://review.opendev.org/c/openstack/nova/+/886232/comment/565abda0_70ab7fde/ we already have negative values for spreading | 16:49 |
bauzas | https://docs.openstack.org/nova/latest/configuration/config.html#filter_scheduler.io_ops_weight_multiplier | 16:49 |
sean-k-mooney | yep i pointed that out to you in the review | 16:49 |
sean-k-mooney | and noted that its unforturneate because its teh opisctie behavior of the cpu ram and disk weighers | 16:50 |
sean-k-mooney | and i didnt want to proliferate that by adding more useage | 16:50 |
sean-k-mooney | but as i also said its just a prefrence if other dont mind then fine | 16:50 |
bauzas | okay, if really you want it to be positive, then I'll just multiply by -1.0 | 16:50 |
bauzas | but I'm not sure it's really a problem to have a negative value for spreadinh | 16:51 |
bauzas | anyway, looks to me an implementation nit | 16:51 |
sean-k-mooney | it just makes it harder to reason about | 16:51 |
sean-k-mooney | if it would not break peopel i would change the io_ops_weigher | 16:51 |
bauzas | do people agree on having https://blueprints.launchpad.net/nova/+spec/num-instances-weigher to be specless ? | 16:51 |
sean-k-mooney | but its really not worth it | 16:51 |
dansmith | I wasn't aware we had any sort of weigher convention where one value means pack or spread | 16:51 |
dansmith | bauzas: yes, specless | 16:51 |
sean-k-mooney | ya specless is good with me | 16:51 |
bauzas | cool, then we'll revisit this conversation in gerrit | 16:52 |
sean-k-mooney | ack | 16:52 |
dansmith | I've heard you say that, but I've never heard that before | 16:52 |
bauzas | anyone fancy to review the code itself | 16:52 |
dansmith | I guess I'll have to go look at the existing weighers and see | 16:52 |
bauzas | dansmith: I can't remember it too | 16:52 |
bauzas | in general our weighers have different default values | 16:52 |
gibi | +1 on specless | 16:52 |
bauzas | like https://docs.openstack.org/nova/latest/configuration/config.html#filter_scheduler.build_failure_weight_multiplier | 16:52 |
dansmith | bauzas: yeah I thought they were all pretty much individually contextual | 16:53 |
bauzas | which defaults to 1000000.0 | 16:53 |
sean-k-mooney | in generall they all spread by default and positive measn spread. those are the two ruels of tumb i learend early on | 16:53 |
bauzas | anyway | 16:53 |
sean-k-mooney | if we broke that at some poin thats unfortunet btu its what we are stuck with | 16:53 |
bauzas | #agreed https://blueprints.launchpad.net/nova/+spec/num-instances-weigher is approved as a specless bp | 16:53 |
gibi | \o/ | 16:53 |
bauzas | I guess we can continue this in gerrit :!) | 16:53 |
bauzas | :) | 16:53 |
bauzas | okay, so I don't see any other item | 16:54 |
bauzas | anyone wanting to discuss on something ? | 16:54 |
* gibi sends the nice cool weather towards France | 16:55 | |
bauzas | thanks :) | 16:55 |
Uggla_ | :) | 16:55 |
bauzas | I guess I'll need to stop sooner than later | 16:56 |
bauzas | anyway | 16:56 |
bauzas | thanks all | 16:56 |
bauzas | #endmeeting | 16:56 |
opendevmeet | Meeting ended Tue Jun 27 16:56:11 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:56 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-06-27-16.01.html | 16:56 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-06-27-16.01.txt | 16:56 |
opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-06-27-16.01.log.html | 16:56 |
bauzas | three machines and two screens running in a 9m2 room doesn't help with the temperature FWIW :) | 16:57 |
gmann | bauzas: sean-k-mooney elodilles gibi: about EM, TC will be discussing about EM as concept and how to solve the issue of maintenance expectation. Oldest/er EM branch(es) moving to EOL as per normal process/some blocker or project decision is all good to go. | 17:30 |
elodilles | gmann: ack, thanks for the info! | 17:35 |
dansmith | ++ | 17:35 |
gibi | gmann: thanks | 17:37 |
NobodyCam | Good morning Nova folks, Would anyone happen to know if there is a list of status messages emitted by Nova??? I am look to see if there are events for rescue | 17:42 |
NobodyCam | I found them "rescue.start" & "rescue.end" | 17:45 |
dansmith | NobodyCam: this might help: https://github.com/openstack/nova/tree/master/doc/notification_samples | 17:48 |
NobodyCam | Thank you dan. that is very helpful! | 17:49 |
NobodyCam | s/d/D/ | 17:49 |
opendevreview | Amit Uniyal proposed openstack/os-vif stable/wallaby: Move mtu update request into ovsdb transaction https://review.opendev.org/c/openstack/os-vif/+/887017 | 18:39 |
opendevreview | Amit Uniyal proposed openstack/os-vif stable/wallaby: set default qos policy https://review.opendev.org/c/openstack/os-vif/+/886778 | 18:39 |
opendevreview | Dan Smith proposed openstack/nova master: DNM: Test reimage-timeout change https://review.opendev.org/c/openstack/nova/+/887112 | 19:21 |
dansmith | bauzas: this ^ is the end of the chain to fix that rebuild timeout issue (we think) | 19:22 |
opendevreview | Merged openstack/nova stable/xena: Reproduce live migration rollback w/o multi port bindings error https://review.opendev.org/c/openstack/nova/+/843336 | 19:24 |
opendevreview | Merged openstack/nova stable/xena: Fix LM rollback w/o multi port bindings extension https://review.opendev.org/c/openstack/nova/+/843337 | 21:48 |
opendevreview | melanie witt proposed openstack/nova-specs master: Propose tooling and docs for unified limits https://review.opendev.org/c/openstack/nova-specs/+/887014 | 22:23 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!