Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-06-27
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
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 sean-k-mooney ack
16:52:09 dansmith I've heard you say that, but I've never heard that before
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
16:53:47 gibi \o/
16:53:55 bauzas I guess we can continue this in gerrit :!)
16:53:57 bauzas :)
16:54:34 bauzas okay, so I don't see any other item
16:54:42 bauzas anyone wanting to discuss on something ?
16:55:41 bauzas thanks :)
16:55:50 Uggla_ :)
16:56:01 bauzas I guess I'll need to stop sooner than later
16:56:06 bauzas anyway
16:56:09 bauzas thanks all
16:56:11 bauzas #endmeeting
16:56:11 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:11 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-06-27-16.01.html
16:56:11 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-06-27-16.01.txt
16:56:11 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-06-27-16.01.log.html
16:57:10 bauzas three machines and two screens running in a 9m2 room doesn't help with the temperature FWIW :)
17:30:14 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:35:24 elodilles gmann: ack, thanks for the info!
17:35:59 dansmith ++
17:37:14 gibi gmann: thanks
17:42:17 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:45:12 NobodyCam I found them "rescue.start" & "rescue.end"
17:48:02 dansmith NobodyCam: this might help: https://github.com/openstack/nova/tree/master/doc/notification_samples
17:49:42 NobodyCam Thank you dan. that is very helpful!

Earlier   Later