| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-02-04 | |||
| 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 | |
| 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 | efried | heh | |
| 16:54:56 | stephenfin | ;) | |
| 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 | |
| 20:24:59 | openstackgerrit | Mykola Yakovliev proposed openstack/nova master: Fix boot_roles in InstanceSystemMetadata https://review.opendev.org/698040 | |
| 21:38:06 | openstackgerrit | Michael Bayer proposed openstack/nova master: remove DISTINCT ON SQL instruction that does nothing on MySQL https://review.opendev.org/705850 | |