| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-09 | |||
| 16:33:27 | mriedem | somewhere in init_host or something | |
| 16:33:36 | kaisers_ | mriedem: thanks | |
| 16:34:35 | mriedem | cdent: wouldn't the operator just not configure the flavor to require trait barney? | |
| 16:35:00 | cdent | there are other flavors that do want barney | |
| 16:35:13 | cdent | but these machines are not for that | |
| 16:35:18 | mriedem | aggregates then | |
| 16:35:19 | mriedem | ? | |
| 16:35:39 | cdent | or turn off the traits? | |
| 16:35:50 | mriedem | your barney flavors are tied to the aggregates that allow barney | |
| 16:36:19 | mriedem | i just think the idea of masking inventory reporting is weird, | |
| 16:36:27 | mriedem | if the inventory is there, you can use it, or don't | |
| 16:36:39 | mriedem | inventory/trait/whatever | |
| 16:37:06 | mriedem | and it would further complicate the ways to isolate hosts and restrict flavors to them | |
| 16:37:16 | mriedem | b/c you could do it with aggregates, or with disabling traits, or whatever else | |
| 16:37:25 | cdent | yeah, I can that position too, I'm just trying to point out what I saw as one of the aspects of "why" this. My initial reaction was "oh god, yet another file" but then started to see how it was fairly tidy and powerful. | |
| 16:37:37 | mriedem | why not just have one way (that people are already used to) and make that work well | |
| 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 | 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 | |