Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-10-23
20:28:42 mriedem the downside is it's more proxy stuff in the comptue API
20:28:54 mriedem they do it with metadata on the host aggregate
20:29:12 melwitt ok, I understand now
20:29:17 mriedem https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#aggregateramfilter
20:29:51 mriedem "If the host is in more than one aggregate and thus more than one value is found, the minimum value will be used."
20:29:56 mriedem i don't know if jay's spec deals with that
20:32:11 melwitt thinking...
20:32:46 melwitt if you're only interested in per aggregate ratios, then you'd only need to set them in placement and not nova, I think
20:33:30 melwitt so maybe the scenario of "set them in both nova and placement separately" would be a rare one
20:34:12 jaypipes melwitt: as long as nova doesn't overwrite them over and over again..
20:34:35 melwitt you're either going to be setting them in nova, or in placement, depending on whether you want to do it per compute (or via conf) or per aggregate (or via API)
20:34:38 mriedem right, so if you manage this via the api you don't set the config overrides (iweb case)
20:34:44 mriedem if you're cern, you only use config and not the api
20:34:48 mriedem but we don't support both
20:34:52 mriedem if set, config takes precedence
20:34:57 melwitt right. and if you're oath, you'd use only the api and not the conf
20:35:06 jaypipes mriedem, melwitt: my light at the end of this tunnel is that jules is making kielbasa and cabbage for dinner, which is one of my favorites. yum.
20:35:17 mriedem i can smell your house from here
20:35:29 jaypipes mriedem: you'll be able to smell it in the morning too.
20:35:29 melwitt ok, I see. based on this, I think maybe we shouldn't try to proxy. it doesn't seem like it would buy much even for users
20:35:34 mriedem hi-o
20:35:37 jaypipes lol
20:35:54 mriedem melwitt: well you probably want to run that by mgagne
20:36:06 melwitt and penick
20:36:43 melwitt yeah, I'm just speculating here. will definitely want to talk to them and see if they would be ok with a placement CLI that can fan out to aggregate RPs
20:37:12 melwitt or if being able to set the aggregate metadata is really that valuable to them
20:37:27 jaypipes mriedem: how will melwitt get ahold of penick, though?
20:37:39 jaypipes mriedem: he is a tough cookie to track down.
20:37:40 mriedem paper airplane?
20:37:45 jaypipes hehe
20:37:47 melwitt yeah, that part will be tough. I don't know him that well
20:38:01 jaypipes melwitt: you can set five upon him.
20:38:37 jaypipes for some reason I always think of He-Man's Attack Cat when I picture Five...
20:38:45 mriedem melwitt: it is important to mgagne because they allow non-admin users access to set host aggregate allocation ratios via the API
20:38:55 melwitt jaypipes: lol battlecat, that's awesome
20:38:56 mriedem that's why the RBAC need was big in placement for mgagne
20:39:04 jaypipes melwitt: battlecat, right :)
20:39:16 melwitt I had a battlecat, so cool
20:40:19 melwitt jaypipes: have you watched that "toys that made us" show on netflix? they have one that has the he-man toy line. I found it really interesting
20:40:44 melwitt mriedem: ahhh ok
20:42:08 jaypipes melwitt: hmm, no... sounds like it would be good to watch, though!
20:42:40 melwitt there's only like 4 episodes, I watched em all
20:44:12 melwitt the more I think about it, I'm like proxying isn't so terrible either is it? being that we're already mirroring aggregates anyway. setting the ratios would be a small extra step, it seems. but if placement has RBAC, then would mgagne be happy... hrm.
20:49:45 jaypipes all that hard work I did this morning from 3:30am - 8am in reducing my browser tab count by 63 tabs has been slowly destroyed again.
20:50:13 melwitt you were working at 3:30am??
20:51:58 mriedem cdent: if you have people internally that still care about these https://review.openstack.org/#/c/552190/ https://review.openstack.org/#/c/549067/ you might want to kick them to update them for stein
20:52:14 cdent mriedem: i've kicked them several times to no avail
20:52:23 mriedem shall i drop the abandon hammer then?
20:52:29 mriedem that way you're not the bad guy
20:52:51 cdent mriedem: meh, I'd let them ride a bit longer, might still be a chance
20:53:42 jaypipes melwitt: yeah, couldn't sleep.
20:53:59 mriedem overcommitting a dedicated pcpu... https://review.openstack.org/#/c/599957/ seems...odd
20:54:08 jaypipes BTW, I have COMPLETELY failed in my sean-k-mooney spellchecker powers today.
20:54:11 mriedem isn't that an oxymoron?
20:54:45 mriedem oxymoron = overcommitted dedicated pcpu
20:54:48 melwitt thinking about that hurts my brain
20:54:54 jaypipes mriedem: yeah, it is, and I chatted with tpatil about that in Denver
20:55:14 melwitt definitely sounds contradictory
20:55:31 jaypipes mriedem: mostly they just need the whole "allow a single compute host to have dedicated stuff and non-dedicated stuff on the same box" thing
20:55:48 jaypipes mriedem: I doubt Tushar will follow up on that spec.
20:55:53 mriedem and then PCPU inventory has an allocation_ratio>1.0?
20:56:48 mriedem b/c this spec https://review.openstack.org/#/c/599957/ is all about many new config options
20:56:54 mriedem which kinda sucks
21:00:38 melwitt they're saying two of the options (cpu_dedicated_set, cpu_shared_set) come from a different spec though, `Standardize CPU resource tracking`
21:02:22 melwitt so only the cpu_pinning_allocation_ratio would be new. which really I guess is meaning pcpu_allocation_ratio, whereas the existing cpu_allocation_ratio technically means vcpu_allocation_ratio?
21:03:18 melwitt so that they separate handling of vcpu vs pcpu
21:05:38 melwitt also interesting, it says based on the prereq spec https://review.openstack.org/#/c/555081 that PCPU inventory will be created with hardcoded allocation ratio of 1.0 and they want to be able to change it/overcommit it. so wouldn't that just be a call to the placement API?
21:06:45 melwitt but I guess they want to be able to set it the same way as is possible for VCPU
21:06:55 melwitt via nova.conf
21:36:09 mriedem edleafe: all sorts of API gross for you to munch on here https://review.openstack.org/#/c/580336/4
21:41:09 cfriesen I think my question about the "overcommit PCPUs" idea is what does it buy you that a low CPU overcommit ratio (with non-dedicated cpus) wouldn't?
21:46:40 sean-k-mooney jaypipes: haha was there a partical pharse that exausted the spellchecking ablity today :)
21:48:53 sean-k-mooney cfriesen: over commiting pinned cpus i think would be less objectionable but the fact we choose hw:cpu_policy=dedicated|shared and not hw:cpu_policy=pinned|floating makes me dislike the idea
21:49:16 edleafe mriedem: gee thanks!
21:52:29 cfriesen sean-k-mooney: once you have more than one instance using a cpu, it's shared. I don't see what this would buy us compared to just using a shared CPU
21:54:45 sean-k-mooney cfriesen: well i very limited cases it may improve you performance as pinning will result in numa affinity for leagacy reasons but i would personally prefer hw:cpu_policy=share + hw:numa_nodes=1
21:55:42 cfriesen sean-k-mooney: agreed. And if you were using hugepages you'd get the numa affinity anyways.
21:56:24 sean-k-mooney cfriesen: also since we are going to be using the dedictate_cpu_set for allocating realtime cpus i think this is likely to break that also
21:57:00 cfriesen wait...how is a realtime cpu different from a regular dedicated cpu?
21:58:36 sean-k-mooney cfriesen: realtime we set the "nice" value or whatever the priority values is on linux to realtime so it does not get premented if you have a realtime kernel
21:58:51 sean-k-mooney cfriesen: we dont set the tread prioity for dedicated cpus
22:02:33 cfriesen sean-k-mooney: that's what I thought, just making sure. if you've already got a "dedicated" cpu with nothing else running on it, what's the benefit of making the vcpu task realtime?
22:02:56 cfriesen (unless the host hasn't properly moved all kernel work off that cpu)
22:03:09 sean-k-mooney basiclly ^
22:03:25 sean-k-mooney or there is some backgound process that is on the host that is not confied properly
22:03:30 sean-k-mooney but very little
22:05:05 cfriesen but if the host hasn't moved kernel work off that cpu, and you run the qemu task as realtime, don't you risk priority inversion anyways if the guest is doing a busy-loop and never letting other tasks run?
22:05:59 jaypipes sean-k-mooney: no, just distracted generally :)
22:06:01 sean-k-mooney cfriesen: one if its actully a kernel thread then the kernel will run it if it needs too
22:06:31 sean-k-mooney cfriesen: second if its a user tread the kernel can rescudle it i think if the vm is in a busy loop
22:06:34 mriedem melwitt: can we abandon https://review.openstack.org/#/c/509042/ or are there plans to update that?
22:07:07 sean-k-mooney cfriesen: i think we tell people dont use this unless you have set up your host properly for realtime workloads and properly isolated the cores
22:07:21 melwitt mriedem: I'd like to update it but we need allocation ownership concepts in placement else it's moot
22:07:33 mriedem so is anyone driving that dependency?
22:07:37 sean-k-mooney cfriesen: at least i tell people do ues the realtime feature unless you have set up the host properly
22:08:44 cfriesen sean-k-mooney: on hosts with the RT kernel a bunch of kernel things get run in schedulable threads
22:08:55 melwitt mriedem: no, just saying, that's why it's stuck
22:09:21 melwitt and maybe, I guess I could ask jaypipes because I thought I saw mention of the idea of an owner attribute in some other spec
22:09:25 sean-k-mooney cfriesen: on https://review.openstack.org/#/c/599957 i suggested just adding a hw:cpu_policy=pinned which would pin the vm to one of the shared cpu set cores instead. does that sound better then over commiting dedicated cpus to you?
22:09:25 mriedem ok, so....if it's stuck, and no one is working on unstucking it, and it's not high enough priority to are, should we just abandon

Earlier   Later