Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-04
15:28:21 dansmith nobody is asking to be lied to :)
15:28:44 sean-k-mooney dansmith: well im jsut saying we can always use the resources that correspond to the placmenet allcaotion and expose a different virtual numa toplogy if we were willing to not require the 1:1 mapping unless you said you cared about numa
15:28:54 dansmith efried: no, that's not flexibility
15:29:10 dansmith efried: nobody is asking for "show me one numa node even though that's not the truth"
15:29:11 sean-k-mooney efried: lie to it yes
15:29:19 mriedem ignorance is bliss
15:29:31 efried If I ask for a sausage, I'm going to be fine if the sausage is beef or pork.
15:29:31 efried If I ask for a kosher sausage, I'm going to be upset if it's pork.
15:29:33 dansmith sean-k-mooney: gotcha
15:29:56 efried It's not about being lied to. It's about not caring.
15:30:05 dansmith sigh
15:30:08 efried I'm not convinced that everyone cares.
15:30:34 dansmith if we lie to the guest, then the guest *os* is *going* to make bad decisions that don't represent what is actually being offered
15:30:38 dansmith nobody wants that,
15:30:48 dansmith they're opting into that over the more painful "care about this in extreme detail"
15:31:35 sean-k-mooney efried: if you add hw:numa_nodes=1 to a random flavor we normaly expepct about a 20-30% performance improvment
15:31:39 efried then isn't it the responsibility of the libvirt driver (not the scheduler) to take a generic simple request and make a real numa topo out of it?
15:31:51 sean-k-mooney even thoughg it is still floating over cores and using 4k small pages
15:32:09 sean-k-mooney just becuase the memroy and cpus all come form a single numa node
15:33:19 efried iow if my host is configured monolithically in placement and my VM requests simply VCPU=N,MEMORY_MB=M, we'll place the VM even if (and without knowing) the resources have to be spread across NUMA nodes.
15:33:19 efried Now it's the job of the driver (via the overloaded NTF, presumably?) to carve those N VCPUs and M MEMORY_MBs out of whatever NUMA nodes they're available in, and create the appropriate topo for the guest, no matter how many nodes that happens to be?
15:34:21 dansmith no? the virt driver doesn't have visibility into enough of the (nova) system to make those kinds of decisions I don't think
15:34:37 sean-k-mooney if we model numa in placment then the rps the allcoation come form force the dirver to allcoate the resouces form spefici host numa nodes
15:34:54 efried yes, but then we *must* frame the request accordingly.
15:35:01 sean-k-mooney yes
15:35:02 efried that's the whole problem we're trying to avoid
15:35:26 sean-k-mooney the only way to avoid that is to not repor tnuma in placment
15:35:27 efried because, once again, the VM didn't care about the specifics of the NUMA topology. By making it a real one, of whatever shape, we're still conferring the perf advantages to the VM. But we would do that at the host, having decided there are enough resources in total.
15:35:42 dansmith efried: the request is the important part here because we're talking about multiple computers.. the scheduler is looking for something that fits best amongst the options, not "well, we're on this host how do we best cram this into the hole we have"
15:36:09 efried right, I'm saying from the perspective of the scheduler, any number of fits can be considered "best".
15:36:27 sean-k-mooney right we use weighers to determin what best is
15:36:45 sean-k-mooney we have disused the idea of have a weigher based on the allcoation candiate in the past
15:36:47 dansmith which is why the scheduler doesn't pick actual resources, it picks hosts, and why before placement, we got that wrong a *lot*
15:36:53 dansmith which means we reschedule, which is super expensive
15:37:00 sean-k-mooney but that still does not change the fact that the placment query is the import thing to get right
15:37:06 dansmith sean-k-mooney: agreed
15:37:47 sean-k-mooney in the non numa case if we had a weigher and we had 1 allcoation candiate with 1 numa node and another with 2 we could chosse the singel numa node
15:38:00 sean-k-mooney but i dont know how to allow that today with the /ac api
15:38:38 sean-k-mooney that is kind fo what can_split was ment to solve but that is not a thing currnly
15:39:17 sean-k-mooney in the non numa case we would jsut lump everything in the un numberd group and say you can split the vcpus and ram
15:39:44 sean-k-mooney then weigh by the least number of numa nodes
15:40:00 sean-k-mooney but i dont see that happening anytime soon
15:45:07 efried Agreed.
15:45:16 efried So barring the ideal
15:45:28 efried we agreed on this 80/20 approach
15:45:44 sean-k-mooney with the partioning of the cloud
15:45:50 efried yes
15:46:42 sean-k-mooney ya so you know way way way back before numa and pinning was merged they was a counter propoal to make them host wide config options
15:46:50 sean-k-mooney we are slowly getting back to that
15:47:11 efried so that we can have one simple placement query for non-NUMA
15:47:11 efried and one complex strict placement query for NUMA
15:47:11 efried and almost never have to reschedule in either case.
15:47:39 sean-k-mooney yes although i think at some point we will want to have 1 code path
15:47:48 efried That's the 20
15:48:10 sean-k-mooney yes but it could also be a refinment of scope
15:48:20 efried a refinement of scope for Ussuri?
15:48:37 efried or adding restrictions in future releases?
15:48:46 sean-k-mooney no. if we say all vms are numa vms in the future we reduce fucntionality as we did with cpu pinning
15:48:49 sean-k-mooney but make this all simpler
15:49:14 sean-k-mooney efried: to model PCPUs in placment we reduced the funcatiolity of the thread policies
15:49:30 sean-k-mooney we could in a future relase consider the same here
15:49:42 stephenfin ralonsoh: One more question regarding this comment -> "The same patch also introduced an error when retrieving the network ID. The network ID is stored in a key named 'floating_network_id'"
15:50:05 sean-k-mooney every time we try to do that we end up makeing no progress at all
15:50:20 sean-k-mooney so im saying defer to V+ and take the incremental improvment in U
15:50:23 ralonsoh stephenfin, you don't have the network name, only the network ID in this key 'floating_network_id'"
15:51:12 stephenfin ralonsoh: Ah, so I don't think that's an issue since I'm building that field myself https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2593-L2600
15:51:48 stephenfin ralonsoh: My question is would that make a good extension for neutron (adding 'network_details' to complement 'port_details')
15:52:09 sean-k-mooney stephenfin: you should proably swap to using .get() for all those filed lookups by the way
15:52:09 ralonsoh stephenfin, ahhhhh ok. BTW, do you really need to make this call? This is expensive and the ID, IMO, is good enough
15:52:17 stephenfin tbf, we only need that information for this one (deprecated) API, but maybe it would be useful for others
15:52:19 ralonsoh stephenfin, unless you specifically need the name
15:53:00 ralonsoh this could be an optimization, avoiding this "show_network" call
15:53:15 stephenfin ralonsoh: Unfortunately, yes. It's a deprecated API but we expect to return network names first
15:53:31 ralonsoh stephenfin, okidoki
15:53:44 stephenfin I could probably make it optional for this deprecated API. Let me investigate that
15:57:10 stephenfin ralonsoh: Wait, I lied. I've another question :) The 'alias' field will always be present in the 'GET /v2.0/extensions' response, right? https://docs.openstack.org/api-ref/network/v2/?expanded=list-extensions-detail#id5
15:57:37 ralonsoh stephenfin, let met check
15:58:15 stephenfin We're caching the extension name and I've no idea why, because the alias seems a lot better to use a reference constant https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L1254-L1255
16:05:36 ralonsoh stephenfin, sorry, I took my a while, this is not a regular DB call
16:05:59 ralonsoh stephenfin, the call returns a list of this
16:06:00 ralonsoh <class 'dict'>: {'name': 'Address scope', 'alias': 'address-scope', 'description': 'Address scopes extension.', 'updated': '2015-07-26T10:00:00-00:00', 'links': []}
16:06:11 ralonsoh (this is one element of the list)
16:06:22 stephenfin okay, so alias will always be there
16:06:30 stephenfin I'll rework that to use aliases so
16:06:35 stephenfin much clearer, IMO
16:06:36 ralonsoh yes and this is something static
16:06:46 ralonsoh sure, you can consider the alias as a constant
16:06:50 ralonsoh and it's in neutron-lib
16:06:57 stephenfin Bug fix done too. Just fixing up tests
16:20:39 huaqiang stephenfin: for the mixed vCPU instance spec https://review.opendev.org/#/c/668656/, do you have more comments?
16:20:58 huaqiang I know there is no concensus now
16:21:41 huaqiang should I raise a discussion in Thursday's team meeting?
16:21:49 huaqiang which way is better for you?
16:22:40 kashyap stephenfin: That rST thing on line-38 didn't work out, afraid; going to revert to using explicit references (https://review.opendev.org/#/c/693844/5/specs/ussuri/approved/allow-secure-boot-for-qemu-kvm-guests.rst)
16:41:26 huaqiang which way is better for you?
16:52:00 stephenfin huaqiang: Sorry, been working on a bug. I'll try look at that before the meeting but it would be good to bring up anyway
16:52:13 openstackgerrit Stephen Finucane proposed openstack/nova master: Handle neutron without the fip-port-details extension https://review.opendev.org/705760
16:52:15 stephenfin ralonsoh: ^
16:52:25 ralonsoh stephenfin, reviewing it
16:52:35 stephenfin efried, dansmith, bauzas: Apparently this is breaking neutron's gate so we should get this in once it's green

Earlier   Later