Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-09
16:26:41 leakypipes mriedem: we absolutely *do* have a REST API for manipulating things. the provider config YAML stuff is a proposal for how to solve two primary problems: 1) notifying external agents about the identifier for a provider it needs to know about and 2) resolving the "admin set this thing and agent overwrote it" problem.
16:27:14 mriedem leakypipes: i'm talking about different rest apis
16:27:19 openstackgerrit Merged openstack/nova master: Fix indentation in doc/source/cli/* https://review.openstack.org/549166
16:27:36 mriedem my point is that since we do have a placement rest api to set traits on a provider, we do'nt need nova to proxy that information via a yaml file
16:28:05 mriedem i get (1)
16:28:13 leakypipes mriedem: and what happens with the compute node auto-discover traits stuff?
16:28:21 mriedem for (2) if we simply merge the traits set externally with the traits that nova-compute reports, then we should be fine
16:28:53 leakypipes mriedem: somebody is going to overwrite somebody else. the provider config file is a solution to instruct things not to overwrite (or to always overwrite) certain attributes.
16:29:24 mriedem why does somebody need to overwrite somebody else?
16:29:39 mriedem that's what we do today, yes, but we can change that to merge
16:29:48 leakypipes mriedem: let's say the virt driver reports AVX2 trait and somebody removed that trait. the virt driver will just continue to report that trait if we "merge traits".
16:29:59 mriedem right
16:30:09 openstackgerrit Lee Yarwood proposed openstack/nova master: trivial: Rename reboot kwarg to hard_reboot https://review.openstack.org/551289
16:30:15 leakypipes mriedem: so we need a way of instructing the virt driver not to report that trait.
16:30:25 mriedem why would someone remove it, is what i'm trying to get at
16:31:10 leakypipes mriedem: ok, let's use allocation ratio as a different example. say the virt driver uses an allocation ratio, but an admin has externally set the allocation ratio. who wins?
16:31:56 leakypipes mriedem: superdan's proposal was to add 3 more default_xxx_allocation_ratio CONF options to control this behaviour. My proposal is put all these things into a single provider config file format.
16:32:20 mriedem i'm not sure if we'd be able to tell if the allocation ratio was changed externally
16:32:34 mriedem we would see that it's different,
16:32:44 mriedem but it could be different because of a config change and restart of nova-compute
16:32:51 leakypipes mriedem: the absence of an allocation_ratio attribute on an inventory record int he provider config file format means "don't change this".
16:33:04 kaisers_ Hi! Can somebody pls. point me to where the QEMU_VERSION var in nova/virt/images.py is set from? I've an env running qemu-img 2.5.0 but nova (master) keeps on identifying this as 2010001 (which seemingly is 2.10.something) at that point which breaks things... :)
16:33:23 cdent (I think the trait removal is likely going to be pretty common (If I'm understanding it right): you buy some hardware that exposes cpus traits that you don't want to allow to limit or drive scheduling, so you need to say "on this machine turn off cpu trait barney")
16:33:23 mriedem kaisers_: nova.virt.libvirt.driver
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:"

Earlier   Later