Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-09
15:14:17 mriedem hrw: hi
15:14:40 fried_rice mriedem: Roger wilco, thanks.
15:17:54 mriedem melwitt: i've updated launchpad to point rocky as the dev focus, and created the rocky milestones https://launchpad.net/nova/rocky
15:18:05 mriedem based on https://releases.openstack.org/rocky/schedule.html#r-release
15:18:19 melwitt mriedem: cool, thank you
15:18:27 mriedem i'll create a queens-rc2 milestone if we end up having one https://launchpad.net/nova/queens/
15:25:06 mriedem lyarwood: want to hit https://review.openstack.org/#/c/542323/ ?
15:26:12 openstackgerrit Stephen Finucane proposed openstack/python-novaclient master: Remove 2 redundant methods https://review.openstack.org/528325
15:30:37 lyarwood mriedem: ack done
15:35:59 openstackgerrit Balazs Gibizer proposed openstack/nova master: Poison context usage in periodic tasks https://review.openstack.org/542891
15:39:40 openstackgerrit Balazs Gibizer proposed openstack/nova master: Poison context usage in periodic tasks https://review.openstack.org/542891
15:49:57 hrw mriedem: went through your comments and pushed update to https://review.openstack.org/#/c/541728/
15:50:23 hrw mriedem: one of our team members will check for me entries I skipped
15:51:05 leakypipes fried_rice: can you give me another 30 mintues?
15:51:13 fried_rice leakypipes: Okay.
15:51:20 fried_rice leakypipes: Whyncha ping me when ready?
15:51:33 leakypipes fried_rice: yeah, thanks man
15:55:31 openstackgerrit Merged openstack/nova master: Ensure the JSON-Schema covers the legacy v2 API https://review.openstack.org/540154
16:02:59 bauwser meh, one day without being upstream
16:03:01 bauwser sad.
16:07:14 leakypipes fried_rice: https://etherpad.openstack.org/p/going-the-distance
16:07:57 leakypipes fried_rice: I'm ready when you are.
16:08:27 fried_rice leakypipes: Okay, we gonna go through this or should I pre-read?
16:08:43 edleafe fried_rice: it'll take an hour to read :)
16:09:06 leakypipes fried_rice, edleafe: please spend some time to read and then let's get on a hangout?
16:09:16 fried_rice finucannot, sean-k-mooney, edleafe, cfriesen: Heads up, we're gonna do this thing soon.
16:09:20 fried_rice leakypipes: Roger that.
16:09:41 edleafe leakypipes: can I clear the pink color?
16:11:05 leakypipes edleafe: yessir, absolutely.
16:11:20 edleafe ah, much easier on the eyes
16:11:31 fried_rice edleafe: You need to make it solarized now.
16:11:35 leakypipes edleafe: don't like the pepto-pink? :)
16:12:07 edleafe black on color == :(
16:12:41 edleafe ok, I think I have the gist of it
16:13:54 sean-k-mooney edleafe: actully black on colour is easier to read on paper then black on white if you have dislexia but on pcs not so much. thats why they make tinted glasses for peopel with dislexia
16:14:20 leakypipes sean-k-mooney: sense makes that me to.
16:14:27 edleafe sean-k-mooney: good to know
16:14:46 leakypipes finucannot: that's the GOOD stuff, man...
16:14:52 edleafe finucannot: there's not much else :)
16:14:58 finucannot leakypipes: You have a problem, sir.
16:15:04 leakypipes finucannot: yes, well aware :)
16:15:19 sean-k-mooney finucannot: so you read the titles and nothing else :P
16:15:52 sean-k-mooney sql is precise
16:17:58 cfriesen are we still planning on using this for numa as well?
16:18:10 finucannot ^ that was my question
16:18:13 leakypipes cfriesen: yes
16:18:22 fried_rice leakypipes: I'm ready. Hangout?
16:18:29 leakypipes cfriesen: though... meh? :)
16:18:43 leakypipes cfriesen: it would be a giant headache for operators to do NUMA affinity this way.
16:19:13 fried_rice oh. Well, that's a point in favor of the spec I'm writing up. It handles NUMA specifically, but not much else.
16:19:13 leakypipes cfriesen: due to the pinning logic that needs to occur in the filtering, I'd just as likely recommend keeping the NUMATopologyFilter as-is in Nova scheduler side.
16:20:15 cfriesen leakypipes: why would operators need to do anything?
16:20:25 leakypipes cfriesen: the primary use cases I've had in my mind with this are the use cases around multi-failure-domain (HA) placement as well as affinity placement for groups of instances (with tolerances for relative distances between where those instances land)
16:21:02 leakypipes cfriesen: well, perhaps the operator wouldn't... maybe the virt driver could auto-create the aggregates and set distances.
16:21:09 leakypipes cfriesen: for numa nodes, etc
16:22:01 cfriesen leakypipes: makes sense. do you see us being able to drop the server group affinity/antiaffinity filters?
16:22:44 leakypipes cfriesen, finucannot, sean-k-mooney, fried_rice, edleafe: hmm, perhaps it wasn't obvious, but I am not hardcoding the whole "region", "rack", "row", "power-unit" "power-domain" entries in that distance_types table. those would be for operators to fill in what they liked.
16:23:10 fried_rice Which would allow for "numa-node" in theory.
16:23:25 finucannot Yeah, they're all...distance_codes?
16:23:32 cfriesen leakypipes: for the numa case we'd need something like "give me cpus and ram on the same numa node, and some more cpus and ram from a different numa node of the same host, and a pci device from the same host"
16:23:49 edleafe leakypipes: so they would have to define the distance codes, as well as the value for the distances?
16:24:42 leakypipes cfriesen: re: the server group filters... maybe. the concept that I'm espousing here does away with the concept of a server group entirely and relies on point-in-time policy from the caller of nova boot. so instead a scheduler hint for the instance group, the caller is specifying "I want to be near (for *this* definition of "near") this other instance..."
16:25:07 leakypipes edleafe: yep. but keep in mind those distances are simply relative, nothing more.
16:25:50 leakypipes edleafe: we could of course provide tutorial/examples for common use cases.
16:25:50 edleafe I would certainly like to get input from operators about this, then
16:25:52 sean-k-mooney leakypipes: yes i assumed that the operator would fill thoes in but a compute driver could also in some cases
16:26:07 fried_rice One thing that concerns me is how much the operator needs to know about how resource providers are modeled by the driver.
16:26:30 leakypipes fried_rice: in what way? could you elaborate?
16:26:44 edleafe fried_rice: I was just going to say that it seems that we are making the operators fit the solution rather than the other way around
16:27:20 fried_rice If the providers are modeled in tree fashion, the operator needs to know that so she can know which provider(s) to specify what distances for.
16:27:35 leakypipes edleafe: I'm not sure how any solution that didn't rely on the operator describing the relationship of their compute nodes to their groupings of compute nodes (i.e. placement aggregates) would work.
16:27:36 sean-k-mooney leakypipes: you konw the distance types you are proposing are similar to the crush map valuse used by default in ceph
16:27:42 fried_rice Which is different if they're modeled in *this* shape tree versus *that* shape tree.
16:27:42 leakypipes edleafe: I mean, there's so many variations...
16:28:57 edleafe leakypipes: I'm not saying that this isn't acceptable. I'm just saying that it's important to get operators input on whether this is acceptable.
16:29:11 leakypipes sean-k-mooney: I'm not familiar with ceph crush maps :( however, this distance modeling is kinda similar to the distance maps for CPU cores to different levels of cache in NUMA setups, for sure.
16:29:41 leakypipes edleafe: ack, totes.
16:29:43 fried_rice leakypipes: Can you give an example (in the etherpad) for the CLI syntax that would deploy an instance which gets its storage from a sharing provider "near" its compute host?
16:30:09 leakypipes fried_rice: sure, one sec.
16:30:52 fried_rice And when you're done with that, I wouldn't mind delving a little bit into how real NUMA use cases would be modeled/expressed. Like the one cfriesen mentions above.
16:31:58 sean-k-mooney leakypipes: http://docs.ceph.com/docs/master/rados/operations/crush-map/#types-and-buckets just as an fyi. if you swap osd for RP that could work for placement too
16:34:55 sean-k-mooney by the way my brain is working at like 50% today partly due to a headache but i might still joing to listen but no going to be able to add too much.
16:35:12 leakypipes sean-k-mooney: ah, cool. thanks for the link :)
16:37:05 sean-k-mooney ceph have a very similar problem when selecting where to place data on to any give disk they control given the ha/stroage profiles requested for a given pool.
16:43:22 leakypipes fried_rice: aren't conversations on etherpad fun? ;)
16:43:48 fried_rice It's nice to be able to tie the conversation to the context from which it sprungeth.
16:44:01 finucannot Remind me: why do we need the basic NUMA stuff to be mapped this way?
16:44:20 leakypipes finucannot: we don't.
16:44:22 openstackgerrit Merged openstack/nova master: Use with method to consistent oslo timeutils usage https://review.openstack.org/542105
16:44:26 finucannot As opposed to what we normally do, namely, N guest nodes are mapped to N host nodes
16:44:27 fried_rice finucannot: I kinda don't think we do. I'm trying to get us to that conclusion...
16:44:35 finucannot Gotcha :)
16:47:14 leakypipes finucannot, cfriesen: which one of you is light green?
16:47:19 cfriesen not me
16:47:23 finucannot no me
16:47:27 finucannot *not
16:47:37 leakypipes sean-k-mooney: are you light green?
16:47:59 sean-k-mooney yes i need to add my name to a list at the top
16:48:33 leakypipes sean-k-mooney: or just set your name in the ehterpad box...
16:48:36 leakypipes top right

Earlier   Later