| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-06-27 | |||
| 16:22:46 | bauzas | #info stable gates should be OK (from stable/2023.1 to stable/train) | |
| 16:22:51 | bauzas | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:22:57 | bauzas | elodilles: no news is good :) | |
| 16:23:08 | bauzas | #info train-eol patch proposed https://review.opendev.org/c/openstack/releases/+/885365 | |
| 16:23:08 | elodilles | :) | |
| 16:23:14 | bauzas | elodilles: I've seen your comment | |
| 16:23:23 | elodilles | yepp, it needs an update | |
| 16:23:51 | bauzas | so you're also asking to EOL placement, os-vif, os-resource-classes, and the clients ? | |
| 16:24:04 | bauzas | I can work on it | |
| 16:24:22 | elodilles | yes, i guess those would be good to EOL together | |
| 16:24:24 | elodilles | with nova | |
| 16:24:36 | elodilles | as no reason to keep them in EM, right? | |
| 16:24:40 | elodilles | without nova... | |
| 16:24:45 | bauzas | elodilles: also, my question is, shall we abandon the changes in the stable branches, or would it be done automatically ? | |
| 16:24:58 | gibi | os-traits and os-resource classes should be tight to the placement eol | |
| 16:25:12 | elodilles | they need to be abandoned, there's no automation | |
| 16:25:14 | bauzas | elodilles: for os-vif and novaclient, sounds ok | |
| 16:25:23 | bauzas | for placement dependencies, I'm quite torn | |
| 16:25:29 | gibi | but os-traits might also be used be neutron | |
| 16:25:51 | bauzas | gibi: good call, then let's stick to os-vif and novaclient | |
| 16:26:01 | elodilles | i guess if nova eol's it's train branch then maybe other projects will do the same | |
| 16:26:06 | bauzas | we could discuss about EOLing placement and its deps on another change | |
| 16:26:20 | gibi | bauzas: os-vif is also used by neutron for sure | |
| 16:26:21 | elodilles | (and i won't insist to keep open neutron either in that case o:) | |
| 16:26:38 | bauzas | elodilles: I've heard other projects that would EOL *all* their EM branches but I haven't seen yet any change :) | |
| 16:26:49 | gibi | python-novaclient is used by cinder and neutron for the external events no? | |
| 16:26:54 | elodilles | bauzas: yes, i only seen the cinder patch yet | |
| 16:27:02 | gibi | also heat probably uses nova-pythonclient | |
| 16:27:02 | bauzas | gibi: good point, let's then be conservative and only EOL novaclient | |
| 16:27:28 | bauzas | elodilles: what have we done when we EOL'd Stein ? | |
| 16:27:30 | gibi | can we delete all the train branches at once? :D | |
| 16:27:36 | bauzas | I thought nova did it in advance | |
| 16:27:47 | elodilles | heat is already EOL'd up to ussuri | |
| 16:28:27 | elodilles | bauzas: if you ask about the open patches: i ussually abandon the patches to be able to delete the branch :) | |
| 16:28:57 | elodilles | so i can abandon them whenever there is a decision | |
| 16:28:58 | bauzas | elodilles: so I need to click on *every* open patch to abandon it ? | |
| 16:29:27 | bauzas | disclaimer, my office room is 28°C now, my brain is absolutely fried. | |
| 16:29:31 | elodilles | bauzas: i can do that (there aren't many open patches) | |
| 16:30:09 | bauzas | so, what's the outcome of this long conversation , | |
| 16:30:11 | bauzas | ? | |
| 16:30:19 | bauzas | I guess only nova and novaclient can be EOL now | |
| 16:30:19 | elodilles | here the temperature is quite moderate now 21°C :) | |
| 16:30:43 | bauzas | elodilles: it's 28°C *inside* my room (I don't have any A/C) | |
| 16:30:47 | gibi | bauzas: I'm not sure about python-novaclient | |
| 16:31:01 | bauzas | okay, so let's be strict | |
| 16:31:05 | bauzas | and only EOL nova | |
| 16:31:11 | sean-k-mooney | EOLign should not break others as we are just closing the branch and tagging it | |
| 16:31:13 | bauzas | elodilles: fancy revisiting your comment ? | |
| 16:31:22 | sean-k-mooney | and libs like os-vif are installed form pypi by default | |
| 16:32:17 | 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:19 | elodilles | bauzas: i still think it's better to EOL all the other nova projects in the same go | |
| 16:32:32 | sean-k-mooney | ya same ^ | |
| 16:32:59 | bauzas | gibi: agree then ? | |
| 16:33:02 | gibi | elodilles: sure, but then somebody need to handle the fallout | |
| 16:33:24 | elodilles | gibi: by fallout you mean? | |
| 16:33:46 | gibi | other project's job is failing to check out the deleted branch | |
| 16:34:05 | gibi | as an exmple | |
| 16:34:06 | gibi | example | |
| 16:34:34 | elodilles | yeah, that probably needs to be fixed (and honestly, more like EOL'ing everything else | |
| 16:34:43 | bauzas | I guess we need to work on this closely | |
| 16:35:15 | bauzas | AFAIK I tried to look at the jobs to find the ones that use stable/train branch of nova | |
| 16:35:29 | elodilles | btw, was there any result of the PTG forum session about the EM story? | |
| 16:35:33 | bauzas | and unfortunately, I have no crazy idea on how to get a list of such jobs | |
| 16:35:50 | elodilles | i haven't seen news on ML about that | |
| 16:36:12 | 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:29 | gibi | elodilles: the result was to follon on the ML | |
| 16:36:31 | bauzas | elodilles: about that, the conclusion is mostly that the TC will discuss this | |
| 16:36:42 | bauzas | and yeah, follow on the ML | |
| 16:37:07 | 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:21 | bauzas | tl;dr: no agreement was there to stop the EM experience, but a clarification was needed. | |
| 16:37:46 | bauzas | elodilles: you mean stein ? | |
| 16:38:07 | elodilles | bauzas: OK, so we either rush forward with the train EOL patch or wait then until tc discussion happens? | |
| 16:38:26 | bauzas | (and again, the room temperature doesn't help) | |
| 16:38:36 | sean-k-mooney | the TC discussion is about EM as a whole and would affect everythin before ZED | |
| 16:38:57 | bauzas | elodilles: not sure any conclusion would hit our EOL of train | |
| 16:38:59 | sean-k-mooney | i think we can EOL train regardless of what happens for the newer EM branchs | |
| 16:39:04 | bauzas | righjt | |
| 16:39:07 | dansmith | for sure | |
| 16:39:09 | 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:19 | bauzas | and IIRC, EM will continue to exist in some form | |
| 16:40:09 | bauzas | maybe the M of EM carries too much context, but the idea is that we'll continue to have other branches | |
| 16:40:14 | gibi | I agree to drop train regardless of the TC discussion | |
| 16:40:23 | bauzas | those branches could be somewhere else, but that's an alternative to discuss yet | |
| 16:40:44 | bauzas | elodilles: again, lost in translation but I'll ping you tomorrow about it | |
| 16:40:58 | 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:41:23 | elodilles | bauzas: sure, we can check it outside of the meeting :) | |
| 16:41:47 | bauzas | on a morning, with a fresh room temperature, a rested brain and a coffee, please. | |
| 16:42:15 | elodilles | bauzas: ++ :) | |
| 16:42:17 | bauzas | anyway, doesn't sound there is a change in direction | |
| 16:42:34 | bauzas | I guess we're done on that topic anyway | |
| 16:42:41 | elodilles | ++ | |
| 16:42:46 | bauzas | #topic Open discussion | |
| 16:42:49 | bauzas | I have one thing | |
| 16:42:55 | bauzas | (bauzas) Specless blueprint approval request for https://blueprints.launchpad.net/nova/+spec/num-instances-weigher | |
| 16:43:33 | bauzas | tl;dr: some operators said during the PTG that they were having some problems for spreading between heteregenous hardware | |
| 16:43:48 | bauzas | so we found we missed a weigher | |
| 16:44:23 | bauzas | we already have a filter for making sure a host can't have more than a max number of instances | |
| 16:44:33 | gibi | +1 to have this | |
| 16:44:38 | bauzas | but it doesn't spread the hosts | |
| 16:44:38 | gibi | it is a quick and easy win | |