Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-09
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 mriedem you'd have to fetch/update from stash/save
17:03:51 mdbooth If I have to refetch the object and update fields that's not terrible
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 "tunnel_provider": True,
18:00:41 leakypipes "physnet": None,
18:00:41 leakypipes "name": "tenant_tunneled_data_0",
18:00:41 leakypipes backend_mapping = {
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: WIP: Add code to bind a port against a dest host during live migration https://review.openstack.org/523604
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: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:52 openstackgerrit Matt Riedemann proposed openstack/nova master: Add VIFMigrateData object for live migration https://review.openstack.org/515423
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: Use neutron port binding extended API during live migration https://review.openstack.org/551371
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
21:29:04 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP Use port binding exteded API in conductor during live migrate https://review.openstack.org/522537
21:46:49 mnaser mriedem: not sure if you missed my fun rant but our fixes didnt end up fixing my issue unfortunately lol
21:47:26 mnaser because the volume is stuck in attaching, and the instance depends on the volume, heat tries to delete the volume first, but its stuck in attaching because nova hasnt released it yet
21:47:36 mnaser and then it fails/stop because it cant delete the volume
21:47:56 mriedem so it's a heat problem
21:48:19 mnaser i guess we could say so, i guess it should try to delete the instance THEN delete the volume
21:48:24 mnaser which goes back to .. i have no idea how heat even worked before
21:48:32 mnaser because if it always tries to delete the in-use volume, it would never work...
21:49:10 mriedem before pike, nova-api didn't reserve the volume though

Earlier   Later