| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-18 | |||
| 09:25:22 | plestang | | 1 | SIMPLE | migrations | ALL | <null> | <null> | <null> | <null> | 261177 | Using where | | |
| 09:25:24 | plestang | +------+---------------+------------+--------+-----------------+--------+-----------+--------+--------+-------------+ | |
| 09:25:57 | plestang | I was asking if it were a good idea to set the read_deleted to no instead of yes | |
| 09:26:40 | plestang | it would make the MariaDB query plan use one of the index that use the delete column | |
| 09:27:52 | plestang | if I add "and deleted=0" the query plan becomes | |
| 09:27:54 | plestang | +------+---------------+------------+--------+---------------------------------------------------------------------------------+-----------------------------------------+-----------+-------+--------+------------------------------------+ | |
| 09:27:57 | plestang | | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | | |
| 09:27:59 | plestang | |------+---------------+------------+--------+---------------------------------------------------------------------------------+-----------------------------------------+-----------+-------+--------+------------------------------------| | |
| 09:28:01 | plestang | | 1 | SIMPLE | migrations | ref | migrations_by_host_nodes_and_status_idx,migrations_instance_uuid_and_status_idx | migrations_instance_uuid_and_status_idx | 5 | const | 23610 | Using index condition; Using where | | |
| 09:28:03 | plestang | +------+---------------+------------+--------+---------------------------------------------------------------------------------+-----------------------------------------+-----------+-------+--------+------------------------------------+ | |
| 09:28:54 | plestang | in other word the question is what is the idea behind requesting finished migration in deleted status for compute host | |
| 10:35:00 | aspiers | plestang: you might have more luck when the Americans come online | |
| 10:35:15 | aspiers | kashyap: any thoughts on how to split the getDomainCapabilities() patch up? | |
| 10:35:34 | kashyap | aspiers: Hiya, I want to spend some careful time on it | |
| 10:35:58 | kashyap | aspiers: Right now, I'm chugging through a few things that I "need" to finish | |
| 10:36:03 | aspiers | I guess I could manufacture something to test which isn't ever used in the real world | |
| 10:36:07 | kashyap | aspiers: Rest assured, since I have a "vested interest" in it | |
| 10:36:08 | aspiers | OK np | |
| 10:36:14 | aspiers | Sure, I noticed ;-) | |
| 10:36:19 | kashyap | Hehe | |
| 10:36:22 | aspiers | In the mean time I guess I can rebase at least | |
| 10:36:30 | kashyap | Let me quickly re-read it, actually | |
| 10:36:44 | aspiers | Need to fix the merge conflicts | |
| 10:47:32 | openstackgerrit | Ivaylo Mitev proposed openstack/nova master: VMware: Attach volumes using adapter type from instance https://review.openstack.org/616599 | |
| 10:51:33 | stephenfin | dansmith: When you're about, this is probably worth you looking at https://review.openstack.org/#/c/651296/ | |
| 11:00:29 | openstackgerrit | Stephen Finucane proposed openstack/nova master: tests: autospecs all the mock.patch usages https://review.openstack.org/470775 | |
| 11:00:48 | openstackgerrit | Stephen Finucane proposed openstack/nova master: hyper-v: autospec classes before they are instantiated https://review.openstack.org/342211 | |
| 11:16:17 | kashyap | aspiers: Responded on the change. I can understand if my response is not fully satisfying... | |
| 11:17:04 | aspiers | kashyap: thanks! | |
| 11:17:51 | kashyap | First see if I make sense :-) Free to correct me if I didn't consider something else. | |
| 11:19:04 | aspiers | sure | |
| 11:41:40 | openstackgerrit | Hamdy Khader proposed openstack/nova master: Do not perform port update in case of baremetal instance. https://review.openstack.org/649345 | |
| 12:05:51 | plestang | aspiers: ok thx waiting a couple of hours | |
| 12:12:40 | openstackgerrit | Lee Yarwood proposed openstack/nova master: fixtures: Return a mocked class instead of method within fake_imagebackend https://review.openstack.org/619804 | |
| 12:43:32 | openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA affinity for vGPUs https://review.openstack.org/650963 | |
| 12:44:03 | bauzas | dansmith: efried: thanks for commenting the vGPU affinity spec, I made it way simplier ^ | |
| 12:45:14 | bauzas | efried: about your comment on the new field name, I just wanted to make this field as arbitrary as possible, since other features could want to affinitize it too (think of... network ports :) heh gibi) | |
| 13:02:37 | efried | bauzas: But you're already calling it "devices". The part that makes it clearer is the "rp_uuids" bit. Otherwise the only thing you have to go on is the fact that it's a UUIDField. Are you saying it could include UUIDs *other* than RP UUIDs? How would the code know which is which?? | |
| 13:03:07 | bauzas | ok, we can call it rp_uuids if so | |
| 13:03:18 | bauzas | or related_rp_uuids | |
| 13:03:27 | bauzas | FWIW, I'm very bad at naming things but my children | |
| 13:03:28 | sean-k-mooney | bauzas: ya i think rp_uuids is good | |
| 13:03:40 | sean-k-mooney | -1 to related_rp_uuids | |
| 13:03:50 | sean-k-mooney | too much typeing | |
| 13:05:01 | openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA affinity for vGPUs https://review.openstack.org/650963 | |
| 13:05:02 | bauzas | sean-k-mooney: efried: my pleasure ^ | |
| 13:06:13 | efried | bauzas: So now does it include the UUID of the NUMA cell RP? | |
| 13:06:44 | sean-k-mooney | no | |
| 13:07:14 | sean-k-mooney | maybe child_rps woould be better... | |
| 13:07:30 | sean-k-mooney | actully it could | |
| 13:07:32 | efried | Yeah, good idea, child_rp_uuids | |
| 13:07:47 | sean-k-mooney | we coudl do it either way | |
| 13:08:04 | sean-k-mooney | if it doen not include it we shoudl have a field for the numa node RP | |
| 13:08:21 | efried | I don't love including the NUMA cell RP UUID, because how would you tell which one that is. But yes, this ^ | |
| 13:08:27 | sean-k-mooney | but this spec does not depend on have numa nodes as RPs in placment | |
| 13:08:41 | efried | then make the field nullable | |
| 13:09:03 | efried | or set it to the compute RP UUID. | |
| 13:09:21 | efried | um, not that second thing - because there can still be more than one, eh? | |
| 13:10:02 | sean-k-mooney | so in this spec i think have it as just child_rp_uuids makes sense | |
| 13:10:25 | sean-k-mooney | and if we also do the numa in placement spec add a rp_uuid filed for the numa node RP | |
| 13:11:41 | efried | - Name the new ListOfUUIDField `child_rp_uuids` and it includes all & only UUIDs of child RPs like PGPUs, NICs, etc. | |
| 13:11:41 | efried | - Add rp_uuid (the UUID of the NUMA cell) as a nullable UUIDField, only set if the NUMA cell is represented as a nested RP | |
| 13:11:41 | efried | So summarizing: | |
| 13:12:06 | sean-k-mooney | +1 | |
| 13:12:18 | sean-k-mooney | bauzas: what do you think ^ | |
| 13:14:27 | bauzas | efried: I don't want the vGPU affinity spec to tell about any NUMA node being a nested RP | |
| 13:14:31 | bauzas | it's a different spec | |
| 13:14:58 | bauzas | for the moment, pGPUs are a specific RP, sure, but NUMA nodes are just using the root RP | |
| 13:15:11 | sean-k-mooney | bauzas: well you could leave adding the the nullable rp_uuid fiedl to the other spec | |
| 13:15:58 | bauzas | sean-k-mooney: maybe, I'm not sure we need it | |
| 13:16:13 | openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA affinity for vGPUs https://review.openstack.org/650963 | |
| 13:16:14 | bauzas | bikeshed update ^ | |
| 13:17:00 | sean-k-mooney | :) that looks fine too me | |
| 13:17:55 | sean-k-mooney | the other thing i wanted to point out is if we did not have the numa-as-nested-rp spec then this is enought to do numa with placement in general | |
| 13:18:51 | openstack | Launchpad bug 1823251 in OpenStack Compute (nova) "Spike in TestNovaMigrationsMySQL.test_walk_versions/test_innodb_tables failures since April 1 2019 on limestone-regionone" [High,Confirmed] | |
| 13:18:51 | efried | mdbooth: https://bugs.launchpad.net/nova/+bug/1823251 <== have you had a chance to look into this? (weird db race brought up two nova meetings ago) | |
| 13:18:52 | sean-k-mooney | take sriov as an example if we just model the pfs as RPs of the compute node and add the rps to the child_rp_uuids then it will work | |
| 13:19:21 | sean-k-mooney | well we will need to do a few tweeks but the datamdoel will support it | |
| 13:20:05 | sean-k-mooney | so if we dont make progress on the richer query syntax this cycle then we can atleast model the capasity with placement and use the numa toplogy filter to track the numa locality | |
| 13:21:41 | efried | sean-k-mooney: Can you give me a rundown of the reviews you have open for CI-ish stuff? | |
| 13:22:06 | efried | Is it just this one https://review.openstack.org/#/c/652197/ ? | |
| 13:22:34 | sean-k-mooney | that is the main one | |
| 13:22:52 | efried | can I call on you in the nova meeting to give a brief summary of that effort? | |
| 13:23:05 | sean-k-mooney | am sure | |
| 13:23:22 | sean-k-mooney | i plan to allso add a tempest-dpdk job | |
| 13:23:42 | sean-k-mooney | and i might work with the ovn folk to create a tempest-dpdk-ovn job after | |
| 13:24:05 | sean-k-mooney | i have a dpdk job in my thirdparty ci just need to port it | |
| 13:24:23 | efried | cool. You can say all of that again for the crowd :) | |
| 13:24:37 | sean-k-mooney | hehe yes we have a topic at the ptg too | |
| 13:24:53 | sean-k-mooney | there are related things to talk about but ill give a summary in the meeting | |
| 13:25:10 | openstackgerrit | ya.wang proposed openstack/nova-specs master: Expose auto converge and post copy https://review.openstack.org/651681 | |
| 13:26:03 | efried | mriedem: https://review.openstack.org/#/q/project:openstack/nova+branch:stable/pike+topic:bug/1669054 merged, are we ready to update the pike-em patches and make them go or are we waiting for other things? | |
| 13:27:42 | efried | https://review.openstack.org/#/c/613263/ ? | |
| 13:28:33 | mriedem | i personally don't think we need that change, it was only noticed on newer branches related to some other changes in the RT which aren't backported to queens, not sure why rado is backporting it to pike | |
| 13:28:53 | mriedem | mel wants https://review.openstack.org/#/c/653514/ | |
| 13:29:18 | mriedem | dansmith: this is quite old and we talked about this fix at the last ptg in denver - would be nice to flush it https://review.openstack.org/#/c/581912/ | |
| 13:29:50 | mriedem | efried: so yeah there are still more changes we want in pike | |
| 13:29:57 | mriedem | i'm working on it | |
| 13:30:14 | mriedem | i might just start approving things | |
| 13:30:39 | efried | mriedem: ack; should we make a pike-em-potential etherpad or something, or is it okay for this to be all in your head? | |