Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-09
16:38:11 mriedem cdent: tidy and powerful for now, until we use it in practice and start to have all sorts of weird complicated things we didn't envision
16:38:13 cdent Yeah, perhaps. In my head, though, aggregates are difficult (I'm not sure why, they just are) to manage and reason about.
16:38:44 cdent Like I said, I don't have a strong opinion, just trying to see if the picture is clear.
16:38:53 leakypipes I don't really see why aggregates are involved here.
16:39:05 mriedem because cdent was trying to answer my question,
16:39:17 mriedem about why we'd explicitly ignore traits that nova-compute is reporting
16:41:17 leakypipes mriedem: I'm still unsure how you're proposing to solve the "a overwrites b overwrites a" problem. can you elaborate more on that?
16:41:45 mriedem stop overwriting. merge the traits. who is doing the overwriting?
16:42:18 leakypipes how do you "merge traits" when one of them has been manually deleted and the compute node keeps adding the same trait?
16:42:33 leakypipes admin deletes AVX2. virt driver keeps adding it.
16:42:40 mriedem and now we're back to my question about why would someone manually delete a trait that nova-compute is reporting
16:42:47 mriedem which cdent was trying to answer
16:44:37 mriedem i just feel like we're debating a solution for a problem that doesn't yet exist
16:44:54 mriedem the trait override / manual removal part i mean
16:44:58 mriedem the CN uuid discovery stuff i get
16:46:09 mriedem maybe we should agree to table this for today, and do a hangout next week, when efried is also back to weigh in
16:46:37 leakypipes mriedem: fine by me.
16:56:11 mriedem i'm sorry for my initial reaction to the spec, i just want to understand the problem better, which we can talk about next week
16:58:37 leakypipes mriedem: thx, it's cool. we can chat about it next week.
16:59:35 mdbooth superdan: Can I mark an object field 'dirty' so if I call save() it will be written again?
17:01:03 mriedem mdbooth: think you have to change it's value
17:01:25 mdbooth mriedem: So obj.foo = obj.foo?
17:01:33 mriedem i'm not sure if that would work
17:01:42 mdbooth Right.
17:01:54 mriedem if it's not changing, why do you need to write it again?
17:01:58 mdbooth I can fetch them again and update specific values from the stashed object
17:02:02 mdbooth But that just seems inefficient
17:02:13 mdbooth The LM thing I was talking about yesterda
17:02:15 mdbooth y
17:02:29 mriedem sure, but if the values don't change, why do we need to write it again?
17:02:37 mdbooth If I stash the BDMs on the source then call pre_live_migration on the dest
17:02:43 superdan mdbooth: there's no interface for marking a thing as dirty, no
17:03:04 mdbooth The dest updates the BDMs, but that doesn't affect my stashed list because I (deliberately) haven't gone back to the db
17:03:23 mriedem oh i see
17:03:33 mdbooth Just wondering if I can do bdm.poke(connection_info, attachment_id); bdm.save()
17:03:51 mdbooth If I have to refetch the object and update fields that's not terrible
17:03:51 mriedem you'd have to fetch/update from stash/save
17:03:59 mdbooth Just wonder if I would be missing a trick
17:04:00 superdan mdbooth: setting it to the same thing should re-add it to the dirty list though I think
17:04:03 superdan from looking at the code
17:04:34 superdan mdbooth: i.e. obj.foo = obj.foo
17:04:42 mdbooth superdan: Is that an interface you'd want to rely on? Or best to refetch anyway?
17:04:51 mriedem make sure you leave a note :)
17:04:58 mdbooth mriedem: Hehe, yeah
17:04:59 superdan mdbooth: I mean, it could change I guess, but hasn't in a long time
17:05:18 mdbooth superdan: Ok, I'll do that and leave a comment
17:43:35 openstackgerrit Matthew Booth proposed openstack/nova master: Avoid redundant initialize_connection on source post live migration https://review.openstack.org/551302
17:47:00 openstackgerrit Matthew Booth proposed openstack/nova master: Avoid redundant initialize_connection on source post live migration https://review.openstack.org/551302
17:58:58 leakypipes finucannot: so, finally getting to your NUMA vSwitch spec...
17:59:33 leakypipes finucannot: is Neutron cool with embedding so much mapping information info neutron.conf files?
18:00:40 leakypipes finucannot: in particular, I think it will get unwieldy to store *tenant-specific* mappings for things in the neutron.conf. for example, this refers to a project-specific setup, right?
18:00:41 leakypipes backend_mapping = {
18:00:41 leakypipes "name": "tenant_tunneled_data_0",
18:00:41 leakypipes "physnet": None,
18:00:41 leakypipes "tunnel_provider": True,
18:00:42 leakypipes "numa_nodes": [0,1],
18:00:44 leakypipes }
18:01:15 leakypipes finucannot: or does the above refer to a *non-tenant-specific* thing?
18:01:48 leakypipes finucannot: lemme put my question another way...
18:02:28 leakypipes finucannot: directly above the backend_mapping example, you write: "we propose adding a new configuration option, [neutron] backend_mapping, which defines a mapping for a given physical network (phynet) to a NUMA node. For example:"
18:02:53 leakypipes finucannot: but the backend_mapping has a physical network of "None", so what exactly is it describing?
18:03:43 andreaf mriedem question on nova services - clarkb asked me a valid question about https://review.openstack.org/#/c/546765/34/.zuul.yaml - do we need to run n-api-meta and n-novnc by default in the integration gate base job?
18:12:02 openstackgerrit Matthew Booth proposed openstack/nova master: WIP: Restore connection_info after live migration rollback https://review.openstack.org/551349
18:59:20 mriedem andreaf: replied
19:00:02 andreaf mriedem thanks
19:00:22 mriedem like most things, you'd probably need a devstack DNM patch to tinker and see what breaks
19:00:53 andreaf mriedem yeah but I think we skip the vnc tests in the main gate today, and only run them in the multinode job, and I was wondering if there was a special reason for that
19:01:09 mriedem andreaf: i don't think that's true
19:01:32 mriedem i remember testing some new vnc proxy code in nova with the tempest full py35 job
19:02:23 mriedem https://review.openstack.org/#/c/513160/
19:04:40 andreaf mriedem: uh ok, sorry I was confused by the multinode job setting some novnc specific settings that I did not see in other jobs
19:04:52 andreaf mriedem: anyways that answers the question for novnc
19:05:07 andreaf mriedem: I will test the meta api
19:05:17 mriedem as for n-api-meta you can run w/o that under a separate service,
19:05:24 mriedem but i just don't know if devstack requires extra config for it
19:23:42 mriedem what's that thing in python where you pass a function along with it's args as a parameter?
19:24:31 mriedem functools.partial...
19:30:46 openstackgerrit Matthew Edmonds proposed openstack/nova master: remove unnecessary conf imports https://review.openstack.org/539314
19:34:53 edmondsw finucannot ^ I had to manually rebase and undo one change since someone made a change to a file such that it now does need CONF
19:58:03 leakypipes cdent: around still?
20:01:14 cdent oh hi
20:01:30 cdent leakypipes: yuppers
20:26:33 cdent I guess you wandered off leakypipes? I'm still around for a while longer
20:32:51 leakypipes cdent: no worries, we can chat next Monday
20:34:22 cdent leakypipes: cool, I'm probably not super coherent now, but potentially pliant
20:35:19 leakypipes cdent: heh :)
20:35:21 mriedem sean-k-mooney: might have hit a snag on the port binding stuff during live migration wrt the migrate data we're passing around
20:36:12 mriedem at least if we plan on using the libvirt vif driver to get the vif config for the vifs on the destination host - because it takes a Host object from the dest host, which we won't have on the source when getting the updated domain xml
20:36:32 mriedem https://github.com/openstack/nova/blob/fcda5c2d1a8653242e580cc2c00d130a5d4f4e2e/nova/virt/libvirt/vif.py#L537
20:36:53 mriedem so what we might need to do is generate the vif configs *while on the dest host* and send those back to the source via the migrate_data object
20:38:36 mriedem ovs and lb don't care about the host, but others like vhostuser do
20:42:39 mriedem alternatively we could just punt for now and assume that the versions of libvirt between the source and dest are the same...but that kind of sucks
21:20:51 openstackgerrit Matt Riedemann proposed openstack/nova master: Add check if neutron "binding-extended" extension is available https://review.openstack.org/523548
21:20:51 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Add code to bind a port against a dest host during live migration https://review.openstack.org/523604
21:20:52 openstackgerrit Matt Riedemann proposed openstack/nova master: Add VIFMigrateData object for live migration https://review.openstack.org/515423
21:20:52 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP Use port binding exteded API in conductor during live migrate https://review.openstack.org/522537
21:20:53 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: libvirt: use dest host vif migrate details for live migration https://review.openstack.org/551370
21:20:54 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Use neutron port binding extended API during live migration https://review.openstack.org/551371
21:29:02 openstackgerrit Matt Riedemann proposed openstack/nova master: Add VIFMigrateData object for live migration https://review.openstack.org/515423
21:29:03 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: libvirt: use dest host vif migrate details for live migration https://review.openstack.org/551370

Earlier   Later