| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-18 | |||
| 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? | |
| 13:31:26 | efried | mmedvede: I've noticed http://ciwatch.mmedvede.net/project?project=nova&time=7+days is a little wonky lately, some rows seem to be duplicated, are you aware? | |
| 13:31:54 | mriedem | efried: i can do that - one might already exist | |
| 13:32:14 | efried | thanks | |
| 13:32:17 | mriedem | elod: did you create a pike-em potential etherpad for each project? | |
| 13:32:21 | mriedem | or one that was tracking all projects/ | |
| 13:32:22 | mriedem | ? | |
| 13:32:41 | mriedem | ah yes https://etherpad.openstack.org/p/pike-final-release-before-em | |
| 13:32:47 | mriedem | https://etherpad.openstack.org/p/nova-stable-pike-em | |
| 13:34:14 | dansmith | mriedem: hmm, that im=None isn't used huh? | |
| 13:34:32 | openstackgerrit | Ivaylo Mitev proposed openstack/nova master: VMware VMDK detach: get adapter type from instance VM https://review.openstack.org/653738 | |
| 13:36:26 | mriedem | dansmith: been awhile but the logic i think is if we have the api db and get the not found, we should raise b/c that shouldn't happen. if we don't have the api db configured, we assume we're in the cell conductor and we don't need to target the context anyway. | |
| 13:37:14 | mriedem | the latter is the devstack case, the former is like everyone else in real life right now | |
| 13:37:40 | dansmith | mriedem: okay I'm not sure I follow that, but also not sure that's what is here | |
| 13:37:50 | dansmith | not found does not raise | |
| 13:37:56 | gibi | bauzas: I left a question about the GPU weigher in https://review.openstack.org/#/c/650963 | |
| 13:38:17 | mriedem | sorry not the not found, the CantStartEngineError | |
| 13:38:35 | dansmith | mriedem: right, I get that logic, I'm just talking about the line you removed | |
| 13:38:37 | mriedem | if we're in the cell conductor with no api db config, like devstack, reschedules will fail b/c of CantStartEngineError | |
| 13:38:44 | mriedem | that's dead code | |
| 13:38:45 | dansmith | mriedem: the im=None, but I don't know why that was there in the first place | |
| 13:38:57 | mriedem | it's dead, my ide shows it as dead so i removed it most likely | |
| 13:39:24 | dansmith | "my ide made me do it".. jesus, these kids. | |
| 13:40:19 | mriedem | "my text based terminal editor doesn't show me fun stuff like this" jesus these oldies | |
| 13:40:37 | mriedem | <3 | |
| 13:41:08 | dansmith | heh | |
| 13:42:07 | bauzas | gibi: ack, will look | |
| 13:51:27 | gibi | mriedem, dansmith: about the https://review.openstack.org/#/c/652608/4/specs/train/approved/server-move-operations-with-ports-having-resource-request.rst@190 do you have a feeling which one is easier: 1) implement multiple portbinding usage for every server move operation 2) pass around the RequestSpec in the compute RPC API? | |