Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-06-27
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
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 sean-k-mooney or return current * -1.0
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: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
16:50:33 sean-k-mooney but as i also said its just a prefrence if other dont mind then fine
16:50:37 bauzas okay, if really you want it to be positive, then I'll just multiply by -1.0
16:51:01 bauzas but I'm not sure it's really a problem to have a negative value for spreadinh
16:51:23 bauzas anyway, looks to me an implementation nit
16:51:24 sean-k-mooney it just makes it harder to reason about
16:51:35 sean-k-mooney if it would not break peopel i would change the io_ops_weigher
16:51:39 bauzas do people agree on having https://blueprints.launchpad.net/nova/+spec/num-instances-weigher to be specless ?
16:51:40 sean-k-mooney but its really not worth it
16:51:41 dansmith I wasn't aware we had any sort of weigher convention where one value means pack or spread
16:51:47 dansmith bauzas: yes, specless
16:51:55 sean-k-mooney ya specless is good with me
16:52:00 bauzas cool, then we'll revisit this conversation in gerrit
16:52:09 dansmith I've heard you say that, but I've never heard that before
16:52:09 sean-k-mooney ack
16:52:10 bauzas anyone fancy to review the code itself
16:52:18 dansmith I guess I'll have to go look at the existing weighers and see
16:52:23 bauzas dansmith: I can't remember it too
16:52:42 bauzas in general our weighers have different default values
16:52:45 gibi +1 on specless
16:52:59 bauzas like https://docs.openstack.org/nova/latest/configuration/config.html#filter_scheduler.build_failure_weight_multiplier
16:53:03 dansmith bauzas: yeah I thought they were all pretty much individually contextual
16:53:09 bauzas which defaults to 1000000.0
16:53:10 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:21 bauzas anyway
16:53:28 sean-k-mooney if we broke that at some poin thats unfortunet btu its what we are stuck with
16:53:39 bauzas #agreed https://blueprints.launchpad.net/nova/+spec/num-instances-weigher is approved as a specless bp

Earlier   Later