Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-03
16:13:38 stephenfin sean-k-mooney: so rely on the fact they'll land on NUMA node #0?
16:13:41 artom sean-k-mooney, and hope they both land on the "same" NUMA node on each host?
16:13:55 sean-k-mooney we use functools.permuations to iterate over the compute nodes in the same order
16:14:08 sean-k-mooney artom: the current libvirt code will
16:14:17 artom I suppose we could fail the test if we detect one of the instances went to NUMA node 1
16:14:17 sean-k-mooney but its an implemenation detial
16:14:30 sean-k-mooney if we ever break that the fucntest will fail
16:14:35 sean-k-mooney but its valid for the current code
16:14:42 stephenfin I though we made a point of not making that contract, but that would work for me to keep this moving
16:14:53 stephenfin just stick the note in that we're making assumptions
16:14:56 sean-k-mooney oh actuly that wil break potentally with placment in the future
16:15:04 stephenfin we can rework the test then
16:15:10 sean-k-mooney yep
16:15:12 artom And re-visit this conversation?
16:15:14 artom Ugh
16:15:44 stephenfin artom: But we'll all be rich and living in Barbados or somewhere by then
16:15:47 sean-k-mooney artom: without the ablity to pass differnt configs i think that is the simplest thing we can do at the momemt
16:15:48 stephenfin so what does it matter
16:16:03 artom stephenfin, *glare*
16:16:04 sean-k-mooney :)
16:40:53 openstackgerrit Mykola Yakovliev proposed openstack/nova master: Fix boot_roles in InstanceSystemMetadata https://review.opendev.org/698040
17:09:02 artom sean-k-mooney, stephenfin, I *really* don't like relying on both VMs landing on NUMA node #0, because you made the very good point that it could change with placement
17:09:11 artom And I *don't* think pushing this conversation down the line is fair
17:09:32 artom So I'll got with my "change vcpu_dedicated_set" for both computes idea
17:10:33 bauzas sean-k-mooney: efried: trying to decode() https://review.opendev.org/#/c/552924/
17:10:48 bauzas in particular what's written on https://etherpad.openstack.org/p/mem_page_size_and_placement
17:11:17 efried bauzas: Sure, ask away.
17:11:57 sean-k-mooney ill be back in two seconds just getting water
17:11:58 bauzas efried: so, the current proposal was nacked because of two things :
17:11:59 efried TL;DR: Memory in "grandchild" providers according to page size.
17:12:05 bauzas 1/ the memory split case
17:12:27 bauzas 2/ the group_policy=isolate issue
17:12:56 bauzas for 1/, IIUC the alternative that seems to have consensus is to have a grand-child RP
17:12:58 efried If you see it that crisply, cool. For me it was more a nebulous mess of "lots of things are hard to do"
17:13:14 efried Yes
17:13:15 bauzas I need to process this information but that seems reasonable to me
17:13:29 bauzas but for 2/, I don't see any counter-proposal
17:13:34 efried For 2/, the grandchild concept makes group_policy *moot*
17:13:56 efried meaning we can ignore it and let the other parts of the code (e.g. bandwidth stuff) set it as needed.
17:13:58 bauzas ah cool, I missed the whole point
17:14:12 sean-k-mooney bauzas: becasue of how it modeled in the tree with same_tree we dont care what group_policy is set to
17:14:14 bauzas ok, I'll sharp my pen and write a new rev
17:14:14 efried btw, this was one of the things we noticed when we were working on the 'nested magic' design for placement.
17:14:20 sean-k-mooney in the 3 level proposal
17:14:42 efried ...that group_policy no longer really makes sense.
17:14:44 bauzas that's a very good alternative then, thanks both of you for the better proposal
17:24:10 sean-k-mooney efried: one minor point. so we have same_subtree=!NUMA_1,NUMA_2
17:24:18 sean-k-mooney right
17:24:49 sean-k-mooney we technically should be doing that for each of the multi numa ones if we want to skip that in the numa filter
17:24:50 efried I don't believe so, no.
17:25:42 sean-k-mooney ok then without group_policy=isolate we are not guarenteed that we get the correct behavior
17:26:30 sean-k-mooney that said the numa toplogy filter could do the check
17:26:41 efried sean-k-mooney: See https://docs.openstack.org/placement/train/specs/train/implemented/2005575-nested-magic-1.html#default-group-policy-to-none
17:26:43 sean-k-mooney so i dont see it as a blocker
17:27:11 efried Though that asserts that we did default it. We didn't.
17:28:04 efried anyway, yeah, I think you're right.
17:28:10 efried And the bw code defaults it to 'none' https://docs.openstack.org/releasenotes/nova/train.html#other-notes
17:28:19 sean-k-mooney yes
17:28:34 efried gibi: I can't remember what the motivation was for that ^
17:28:56 efried whether there was a strong reason for it to be 'none', or if it was more or less a coin toss just so we didn't bounce the placement request.
17:29:07 sean-k-mooney so with out support for not same_subtree we cant fully express the constratis without group_policy=isolate
17:29:20 efried Because this (numa stuff) gives a decent motivation to "default" (conceivably even enforce) isolate.
17:29:25 sean-k-mooney efried: none is the correct default
17:29:44 sean-k-mooney efried: if we default to isolate you cant have two ports with a bandwith request
17:29:55 sean-k-mooney form the same backend
17:30:11 sean-k-mooney e.g. you cant booth a vm with two ovs ports with min bandwith
17:30:22 efried mm, so that would be a limitation if we always set it to 'isolate' for NUMA
17:30:28 sean-k-mooney yes
17:30:37 sean-k-mooney which is why we cant do that
17:30:46 efried well
17:30:50 sean-k-mooney and why im saying the numa toplogy filter should handel it
17:30:55 efried we would have to weigh whether it's better or worse to have that limitation vs using the ntf
17:31:21 sean-k-mooney e.g. filter based on the allcoation and ensure there are the expecte number of numa nodes or we addn "same_subtree=!...."
17:31:33 efried yeah, I think that's probably the right call. Perhaps we should look into designing the granular isolation thing suggested in the spec.
17:32:03 sean-k-mooney we could
17:32:27 sean-k-mooney but i think for this case the not same_subtree is more useful
17:32:28 efried It won't be simple, I'm afraid. Which is why we didn't do it yet.
17:32:59 sean-k-mooney the not_same_subtree is usful for nic for bonding reasons too
17:33:15 efried Yeah, there's all kinds of anti-affinity use cases
17:33:17 sean-k-mooney so you can ask for VFs from different PFs
17:33:23 sean-k-mooney yep
17:34:12 spatel sean-k-mooney: I have question, i have project name foo and it has bunch of instance and now i want to rename foo project to "bar" is that possible?
17:34:33 sean-k-mooney i think so
17:34:41 sean-k-mooney you do that in keystone
17:34:49 sean-k-mooney we just recorred the uuid in nova i think
17:35:05 sean-k-mooney so the uuid wont change but the name that is shown to the user should be able too
17:35:16 sean-k-mooney that siad i have never tried it
17:36:21 spatel sean-k-mooney: interesting... let me try and see..
17:36:51 spatel i am trying to standardize name across multiple openstack cloud
17:37:58 spatel sean-k-mooney: does cellv2 technology stable enough to deploy? I am tried of managing isolated cloud :(
17:38:17 spatel tired*
17:38:34 sean-k-mooney it is enabled by default on all clouds after pike
17:38:39 sean-k-mooney so yes
17:38:58 sean-k-mooney all deployment are cellv2 deployment with 1 cell
17:39:07 openstackgerrit Stephen Finucane proposed openstack/nova master: tox: Integrate mypy https://review.opendev.org/676208
17:39:07 openstackgerrit Stephen Finucane proposed openstack/nova master: mypy: Add type annotations to 'nova.pci' https://review.opendev.org/676209
17:39:29 spatel sean-k-mooney: default 1 Cell and if i want to add more cell i can do that right without major changes
17:39:35 spatel right?
17:40:43 sean-k-mooney yep
17:44:50 spatel sean-k-mooney: Thanks!!! let me do some research :)

Earlier   Later