Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-18
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 So summarizing:
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 - Name the new ListOfUUIDField `child_rp_uuids` and it includes all & only UUIDs of child RPs like PGPUs, NICs, etc.
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 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: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: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?
13:52:29 mriedem i'm not sure i understand the question
13:52:49 mriedem you need the request spec in methods like unshelve to do the port binding in the networking api methods properly right?
13:53:27 mriedem oh,
13:53:36 mriedem you mean change all move ops to do the port binding stuff that live migration does?
13:53:39 gibi mriedem: cannot set up the portbinding in the conductor for unshelve?
13:54:04 mriedem i'd think you'd still have behavioral changes in the compute if you did that
13:54:06 gibi mriedem: yeah, do multiple portbinding in the conducotr for every move operation then the binding is created in the conductor
13:54:25 mriedem it's really hard for me to say without it being poc'ed first
13:54:36 gibi mriedem: true, we anyhow need a behavior change in the compute either due to the requestspec or due to the multiple portbinding
13:54:40 mriedem for live migration we create the port bindings in the conductor but there were changes in the compute to use those port bindings if they existed
13:54:54 gibi mriedem: yes
13:55:02 mriedem changing the compute rpc api interface is much more straightforward to me
13:55:38 gibi mriedem: OK that is the kind of input I'm looking for as for me both is blackbox now
13:55:44 gibi mriedem: thanks
13:56:17 mriedem if you haven't heard, there is some weird issue sean-k-mooney is working on with the port binding live migratoin stuff too, so until the root cause of that is figured out i'd be nervous about switching everything over
13:56:50 gibi mriedem: yeah I saw that weirdness too
13:58:51 efried Nova meeting real soon in #openstack-meeting
13:59:53 kashyap (Sigh, conflicting call)
14:00:01 openstackgerrit sean mooney proposed openstack/nova master: [WIP] Libvirt: add nfv job https://review.openstack.org/652197
14:00:59 sean-k-mooney i still have the other gate jobs disabled in ^ but if its clean ill uncomment them and drop the [WIP]
14:01:41 sean-k-mooney ... i have that emacs adds tabs...
14:03:16 efried just reprogram it
14:03:21 efried how's yer lisp?
14:04:16 openstackgerrit sean mooney proposed openstack/nova master: [WIP] Libvirt: add nfv job https://review.openstack.org/652197
14:10:24 mdbooth efried: Sorry, I did not in the end. I had good intentions :/
14:10:54 efried mdbooth: Okay. Should I keep you associated with it on my radar or no?
14:11:18 mriedem gibi: replied to the rest of your comments in your spec https://review.openstack.org/#/c/652608/ - question inline about why can't we heal the missing port allocatoins during the _heal_instance_info_cache periodic?

Earlier   Later