| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-02-04 | |||
| 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 | and almost never have to reschedule in either case. | |
| 15:47:11 | efried | and one complex strict placement query for NUMA | |
| 15:47:11 | efried | so that we can have one simple placement query for non-NUMA | |
| 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 | 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:09 | sean-k-mooney | stephenfin: you should proably swap to using .get() for all those filed lookups by the way | |
| 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 | |
| 16:52:45 | bauzas | mmmm ok | |
| 16:52:52 | stephenfin | I ran/fixed a subset of tests that I though might break | |
| 16:52:57 | stephenfin | *thought | |
| 16:53:03 | efried | sounds like a review for gibi | |
| 16:53:13 | stephenfin | oh, how'd I forget gibi | |
| 16:54:13 | gibi | ack | |
| 16:54:28 | gibi | but in 5 minutes it is beertime here | |
| 16:54:50 | stephenfin | I bet you can get this done in 4 though | |
| 16:54:56 | stephenfin | ;) | |
| 16:54:56 | efried | heh | |
| 16:55:18 | openstackgerrit | Sasha Andonov proposed openstack/nova master: rbd_utils: increase _destroy_volume timeout https://review.opendev.org/705764 | |
| 16:55:53 | gibi | working on it ... | |
| 16:58:41 | gibi | done. | |
| 16:58:44 | gibi | in 3 | |
| 16:58:46 | gibi | :D | |
| 17:14:21 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova-specs master: Re-propose "Secure Boot support for KVM & QEMU guests" for Ussuri https://review.opendev.org/693844 | |
| 17:35:05 | gmann | stephenfin: cmurphy melwitt alex_xu this is ready to re-review now. - https://review.opendev.org/#/c/701624/ | |
| 17:35:29 | cmurphy | thanks gmann | |
| 17:38:00 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Handle neutron without the fip-port-details extension https://review.opendev.org/705760 | |
| 17:38:01 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Avoid calling neutron for N networks https://review.opendev.org/705784 | |
| 17:38:03 | stephenfin | ralonsoh: ^ | |
| 17:38:40 | ralonsoh | stephenfin, I'm on it now | |
| 18:09:43 | openstackgerrit | Vladyslav Drok proposed openstack/nova master: Minor improvements to cell commands https://review.opendev.org/698053 | |
| 18:22:10 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Use extension aliases, not names https://review.opendev.org/705792 | |
| 18:34:32 | gmann | melwitt: this is ready from gate side to change your vote from +1 -> +2 - https://review.opendev.org/#/c/705135/4 | |
| 18:35:10 | gmann | you can see the tests of other-projects-context working as expected in https://review.opendev.org/#/c/705126/7 | |
| 18:49:35 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in os-attach-interfaces https://review.opendev.org/705799 | |