Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-06-27
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 bauzas gibi: good point, let's then be conservative and only EOL novaclient
16:27:02 gibi also heat probably uses nova-pythonclient
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 elodilles here the temperature is quite moderate now 21°C :)
16:30:19 bauzas I guess only nova and novaclient can be EOL now
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 gibi it is a quick and easy win
16:44:38 bauzas but it doesn't spread the hosts
16:45:11 dansmith yup
16:45:20 bauzas there is a current discussion on the already-provided code change https://review.opendev.org/c/openstack/nova/+/886232
16:46:11 bauzas the concern is that we have a negative default value for spreading
16:46:15 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:48 sean-k-mooney yep so after some other discussion i woudl just prefer you retrined the number of instance * -1.0
16:46:54 sean-k-mooney and default to 1.0
16:47:11 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:14 sean-k-mooney that is a prefernce not a blocker
16:47:34 sean-k-mooney yep which is why i provided two suggestion orginally
16:47:52 gibi hm, how the -1 relates to the max-instance?
16:48:05 sean-k-mooney it does not
16:48:11 sean-k-mooney i provided 2 suggestsions
16:48:22 sean-k-mooney return max_instace- current
16:48:32 bauzas sean-k-mooney: okay, so you would be okay if _weigh_object() would just do -1 * host_state.num_instances ?
16:48:32 sean-k-mooney or return current * -1.0
16:48:42 sean-k-mooney yep
16:48:50 sean-k-mooney tottaly fine with that
16:48:52 gibi The -1.0 one works for me. I would not complicate it with the max-instance
16:49:23 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:29 bauzas https://docs.openstack.org/nova/latest/configuration/config.html#filter_scheduler.io_ops_weight_multiplier
16:49:43 sean-k-mooney yep i pointed that out to you in the review
16:50:02 sean-k-mooney and noted that its unforturneate because its teh opisctie behavior of the cpu ram and disk weighers
16:50:17 sean-k-mooney and i didnt want to proliferate that by adding more useage

Earlier   Later