| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-09 | |||
| 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 | |
| 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: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 | |
| 21:49:20 | mriedem | so if we failed to schedule, the volume wasn't in-use | |
| 21:49:41 | mnaser | mriedem: ya but even if it never failed. if instance depends on volume, i think heat tries to delete volume first THEN instance (logically) | |
| 21:49:49 | mnaser | it wouldn't be able to delete an in-use volume | |
| 21:50:06 | mnaser | so im not even sure how it would work even if things went through correctly, unless it just bruteforces | |
| 21:50:46 | mriedem | there is a force delete and force attach action for a volume | |
| 21:50:57 | mriedem | but if heat was using those, then you shouldn't have hit any problems in pike | |
| 21:50:58 | mriedem | so idk | |
| #openstack-nova - 2018-03-10 | |||
| 00:20:44 | Spazmotic | And casual friday comes to an end | |
| 04:25:58 | Spaz-Work | Morning weekend novaers | |
| 13:29:08 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 13:30:04 | openstackgerrit | Chris Dent proposed openstack/nova master: Isolate placement database config https://review.openstack.org/541435 | |
| 13:30:26 | openstackgerrit | Chris Dent proposed openstack/nova master: Move placement exceptions into the placement package https://review.openstack.org/549862 | |
| 13:31:06 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/551537 | |
| 13:40:58 | openstackgerrit | OpenStack Proposal Bot proposed openstack/os-traits master: Updated from global requirements https://review.openstack.org/551599 | |
| 13:41:09 | openstackgerrit | OpenStack Proposal Bot proposed openstack/os-vif master: Updated from global requirements https://review.openstack.org/533918 | |