Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-26
14:59:57 bauzas that's what I wrote :p
15:00:21 sahid :)
15:00:21 bauzas the brackets could have confused you but it's not a list of tuples
15:00:40 bauzas I'll remove them to clarify
15:01:09 sahid no no it's your comment the example which confused me, but it's my mistake I should have read better than that
15:01:56 bauzas I do wonder if I should use a namedtuple
15:02:08 bauzas but let's see what other think
15:02:12 bauzas others*
15:03:24 mriedem edleafe: bauzas: dansmith: jaypipes: a shmorgasbord of comments in the Selection object patch https://review.openstack.org/#/c/499239/
15:03:38 mriedem edleafe: wondering if we should use the existing SchedulerLimits object to contain the limits/numa_limit fields
15:03:41 mriedem like the reqspec
15:04:18 openstackgerrit Merged openstack/nova master: Accept all standard resource classes in flavor extra specs https://review.openstack.org/514942
15:04:25 edleafe mriedem: things have come full circle :)
15:04:34 mriedem you started with that?
15:04:49 edleafe Is the plan that limits would be something that is not going away?
15:05:10 mriedem they aren't going away in the near future
15:05:14 mriedem why does that matter?
15:05:26 bauzas -ETOOMANYTHINGSTODO
15:06:11 edleafe It was Jay's comment that limits are going away that got me to drop limits
15:07:08 dansmith what does that have to do with how we put it in the object, if we know we need them for the short term?
15:07:19 mriedem right - we need to pass limits down either way
15:07:24 mriedem we are still supporting the caching scheduler
15:07:39 mriedem so do we pass them differently from the requestspec when we already have an object that handles the exact same thing?
15:07:45 mriedem i'd rather just re-use SchedulerLimits
15:08:27 edleafe ok, if that's the current feeling
15:08:35 edleafe I'll get started on that soon
15:09:10 mriedem cool. i also tried to document some of the discussion we had in irc with dansmith a week or two ago about how redundant this all is with passing limits to compute in 3 different ways now,
15:09:16 mriedem and that there isn't really a way around that for the time being
15:09:25 mriedem and eventually the legacy filter props *should* go away
15:09:45 dansmith ah
15:10:09 dansmith edleafe: that SchedulerLimits object calls out the few limits we have specifically, which is better than just a dict of ints, yeah
15:10:12 dansmith even more confined
15:10:19 dansmith I didn't realize we had this
15:10:24 edleafe dansmith: gotcha
15:10:33 edleafe dansmith: I didn't know about it either
15:14:14 jaypipes mriedem: so this one of your comments on a previous patchset should be ignored? "Given that, I think it's OK to restrict the limits field value to only things that we know about for in-tree filters and how limits are used in the claim/resource tracker code. Filters are pluggable, but the resource tracker is not."
15:15:14 dansmith no?
15:15:35 dansmith we're still talking about restricting the limits to the ones we know about
15:15:40 dansmith we just can't get rid of them just yet
15:15:43 jaypipes dansmith: ok.
15:16:08 jaypipes dansmith: but we're only keeping them for the caching scheduler users, *not* because of out of tree filters. correct?
15:16:20 edleafe dansmith: question: if SchedulerLimits is already part of the reqspec object, why is it needed in the Seleciton object at all?
15:16:21 dansmith jaypipes: that's what his comment is saying
15:16:26 jaypipes dansmith: ok.
15:16:34 dansmith edleafe: because it differs per host
15:17:06 dansmith edleafe: and because we have to pass at least ten copies of limits to the compute node or we lose our heavyweight championship title
15:18:15 edleafe dansmith: more is better!
15:18:29 dansmith obvi
15:21:13 jaypipes dansmith, mriedem: so I'm confused. if the RequestSpec and legacy filter properties are always passed to the compute service during a build operation, and those things contain the limits cruft, why do we want to pass limits information in the Selection object?
15:21:15 mriedem sorry, was trying to cleanup reqspec madness in compute while it's fresh in my mind - sounds like we're all good?
15:21:28 mriedem jaypipes: different limits per alternate
15:21:33 dansmith that ^
15:21:36 jaypipes mriedem: gah. ok.
15:21:39 jaypipes ack
15:21:46 mriedem plus, the request spec is not passed back to the cell conductor during reschedules,
15:21:51 mriedem so it won't be there for alternates
15:21:54 mriedem i'm just noticing...
15:22:00 jaypipes k, another good point, thanks.
15:22:11 mriedem i'm going to polish some turds this morning
15:23:46 mriedem oh i forgot,
15:23:49 mriedem dansmith: :)
15:24:02 mriedem limits are also passed as a direct kwarg from conductor to compute.build_and_run_instance
15:24:03 dansmith ?
15:24:09 mriedem 1. requestspec.limits
15:24:14 mriedem 2. filterproperties.limits
15:24:16 mriedem 3. direct limits kwarg
15:24:22 mriedem 4. selection.limits
15:24:24 dansmith and once per alternate
15:24:29 dansmith because we rock
15:24:36 mriedem * 4. selection.limits * max_attempts
15:24:51 dansmith actually it's max_attempts +1 I think
15:24:56 dansmith well, maybe not
15:24:57 dansmith whatever
15:24:59 dansmith too fucking many
15:25:01 mriedem i mean seriously, can i just get some limits please
15:25:03 openstackgerrit Artom Lifshitz proposed openstack/nova master: WIP: proper fix for Quobyte CI https://review.openstack.org/515447
15:25:08 mriedem unlimited ways to get the limits
15:25:09 artom_ kaisers_, still around?
15:25:10 dansmith we should limit our limits
15:25:31 mriedem "nova: blowing up your rpc queue with limits since 2014"
15:27:46 efried mriedem If your req spec turd polishing overlaps with https://review.openstack.org/#/c/515223/2/nova/scheduler/utils.py please let me know.
15:28:15 mriedem right now it doesn't
15:28:22 mriedem just going to try and clean up some things in the compute
15:28:47 mriedem so that maybe by S we can stop passing at least limits and filter_properties down to the compute
15:29:38 kaisers_ artom: yep, few mins
15:29:46 kaisers_ artom: saw the cl
15:30:54 kaisers_ artom: I'll check that out in detail tomorrow
15:31:48 artom kaisers_, aha, thanks! This is very very very preliminary
15:32:09 artom kaisers_, but if we could get a quobyte CI run against that without dynamic_ownership = 0, it would be a first step
15:32:30 artom And ideally a way to recheck, still without dynamic_ownership = 0
15:32:51 kaisers_ artom: exactly. I'll spin up a manual instance and run tests, etc.
15:33:21 kaisers_ that related to the previous comment... :)
15:35:24 kaisers_ artom: not sure about the automated recheck, I'll comment in the CL
15:35:35 artom kaisers_, fantastic, thanks
15:36:00 artom To be honest it might fail Jenkins CI
15:36:31 artom So maybe wait for that to at least be sure we can still boot generic VMs with that patch ;)
15:50:42 mriedem bauzas: why does RequestSpec._from_hints turn the key=value from filter_properties into a key=[value] ?
15:53:06 openstackgerrit Merged openstack/nova master: Move project_id and user_id to Allocation object https://review.openstack.org/500410
15:54:27 mriedem i guess because you can pass in hints like key=value1 key=value2 and the CLI will convert those to a key=[value1,value2]
15:55:43 mriedem seems that _validate_instance_group_policy in the compute manager doesn't handle the hint value being a list at all

Earlier   Later