| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-12 | |||
| 16:07:26 | bauzas | mriedem: https://bugs.launchpad.net/nova/+bug/1748858 | |
| 16:07:28 | openstack | Launchpad bug 1748858 in OpenStack Compute (nova) "allocation_ratio set by aggregate metadata don't work in NUMATopologyFilter" [Undecided,Won't fix] - Assigned to yangjie (yang.jie) | |
| 16:07:56 | bauzas | mriedem: we can clarify the doc, but I don't feel we should open a can of worms about aggregate ratios | |
| 16:10:49 | openstackgerrit | Eric Berglund proposed openstack/nova master: WIP: PowerVM Driver: Snapshot https://review.openstack.org/543023 | |
| 16:12:15 | mriedem | bauzas: i don't either | |
| 16:13:19 | openstackgerrit | Merged openstack/nova-specs master: Fix the names on some specs https://review.openstack.org/542504 | |
| 16:15:13 | openstackgerrit | Merged openstack/nova-specs master: Move queens implemented specs https://review.openstack.org/542505 | |
| 16:18:00 | openstackgerrit | Eric Berglund proposed openstack/nova master: Use dict.get() when accessing capabilities dict https://review.openstack.org/539715 | |
| 16:38:57 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: PUT dict format to /allocations (v1.11, v1.12) https://review.openstack.org/542819 | |
| 16:40:13 | openstackgerrit | sahid proposed openstack/nova master: libvirt: disconnect volume from host during detach https://review.openstack.org/515008 | |
| 16:46:28 | openstackgerrit | sahid proposed openstack/nova master: hardware: only take into account small pages https://review.openstack.org/532168 | |
| 16:55:15 | gibi | mriedem: Would it be OK with you cancelling the next 3 notification subteam meeting? This week I don't feel we have things to talk about and next week I will already travelling to Dublin and then there will be PTG week. | |
| 16:56:07 | mriedem | gibi: works for me | |
| 16:56:46 | gibi | mriedem: OK, cool | |
| 17:04:37 | mgariepy | is there a way to set a flavor to set the kvm=off option or i really need to pass the key from glance image ? | |
| 17:05:16 | mgariepy | referring to : https://review.openstack.org/#/c/459753 | |
| 17:06:04 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Move the nova-next job in-tree and update it https://review.openstack.org/541474 | |
| 17:06:04 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Test websocketproxy with TLS in the nova-next job https://review.openstack.org/513160 | |
| 17:06:48 | mriedem | mgariepy: looking at the code https://review.openstack.org/#/c/459753/18/nova/virt/libvirt/driver.py@4184 it only checks the image meta, not flavor extra specs | |
| 17:07:39 | mgariepy | thanks mriedem i'll add the key to an image would it be a lot of work to add that to flavor extra specs ? | |
| 17:08:35 | mriedem | probably not a lot of work, no, but generally i think we prefer image meta since those are standardized and flavor extra specs are not | |
| 17:09:33 | mriedem | i guess the flavor extra spec could maybe make sense in this case if you're using a GPU trait on the flavor or something | |
| 17:09:51 | mriedem | https://docs.openstack.org/nova/latest/admin/virtual-gpu.html#configure-a-flavor-controller | |
| 17:10:12 | mriedem | this is getting dangerously into bauzas territory though | |
| 17:12:16 | mgariepy | i define my flavor to have the gpus via pci_passthrough:alias would have liked to have the hidden kvm stuff on that flavor as well. | |
| 17:12:30 | mgariepy | but as long as it works i guess i'll use the workaround. | |
| 17:13:24 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/pike: Do not attempt volume swap when guest is stopped/suspended https://review.openstack.org/533733 | |
| 17:15:11 | mriedem | mgariepy: ok, i guess it's unclear to me if that's only an issue for windows guests as the commit message implies | |
| 17:15:33 | mgariepy | i need that for linux guest as well. | |
| 17:15:33 | mriedem | in that case it makes sense to me to be tied to the image | |
| 17:15:37 | mriedem | oh | |
| 17:15:56 | mgariepy | nvidia driver don't like kvm guest. | |
| 17:16:47 | mriedem | i'm just amazed the thing is documented https://docs.openstack.org/python-glanceclient/latest/cli/property-keys.html | |
| 17:16:52 | jaypipes | efried: where is that Numbered Request Group Affinity spec? | |
| 17:17:17 | efried | jaypipes: It's not a spec... yet. It's a subsection under Alternatives. | |
| 17:17:39 | efried | jaypipes: I'm considering writing a spec for it, though. It would be largely the same as the one you're looking at. | |
| 17:57:19 | openstackgerrit | Merged openstack/nova-specs master: Granular Resource Request Syntax (Rocky) https://review.openstack.org/540179 | |
| 17:58:34 | edleafe | jaypipes: Did we ever answer the question about whether we need "distance" to be continuous or binary? IOW, do we need "at least 2 away" or "closer than 5", or do we just need "is/isn't in the same grouping"? | |
| 17:58:52 | edleafe | jaypipes: you mentioned some HA use cases that I'm not familiar with | |
| 18:08:14 | openstackgerrit | Merged openstack/nova master: Add regression test for BFV+IsolatedHostsFilter failure https://review.openstack.org/543257 | |
| 18:08:31 | openstackgerrit | Merged openstack/nova master: Handle volume-backed instances in IsolatedHostsFilter https://review.openstack.org/543263 | |
| 18:08:56 | openstackgerrit | Merged openstack/nova master: Fix docs for IsolatedHostsFilter https://review.openstack.org/543264 | |
| 18:13:22 | jaypipes | edleafe: well, the HA use cases are more about anti-affinity... i.e. "make sure the three nodes of my cluster are running in separate failure domains (or groups, or racks, or whatever)" | |
| 18:14:57 | edleafe | jaypipes: thanks. Are there any cases that you know of that don't boil down to yes/no? Like, are X and Y in the same "thing" (rack, row, etc.) or aren't they | |
| 18:15:36 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/pike: libvirt: Block swap_volume attempts with encrypted volumes https://review.openstack.org/543569 | |
| 18:17:38 | jaypipes | edleafe: yeah. the whole "soft affinity" is what those use cases are about. | |
| 18:17:52 | jaypipes | edleafe: in "soft affinity", it's a preference vs. yes/no | |
| 18:18:22 | jaypipes | edleafe: i.e. "place these things *as near to each other* as possible" or "place these related things as far away as possible" | |
| 18:18:51 | jaypipes | edleafe: in the soft affinity cases, the distance being relative and not yes/no enables that sorting of potential destinations | |
| 18:19:59 | edleafe | jaypipes: how widespread is that need? IOW, 20% of use cases? 1%? | |
| 18:20:14 | jaypipes | edleafe: the soft affinity thing? | |
| 18:20:57 | edleafe | jaypipes: yeah. It seems like overkill to build all our affinity/anti stuff to handle these types of things | |
| 18:21:09 | jaypipes | edleafe: BTW, the "soft" stuff is also interpreted as "if the strict condition doesn't hold, then just get me the thing that closest matches my condition" -- i.e. sorting.. | |
| 18:21:25 | edleafe | jaypipes: when the vast majority just want yes/no | |
| 18:21:28 | jaypipes | edleafe: it may indeed be overkill. but it's what we currently have. | |
| 18:21:43 | edleafe | jaypipes: where do we have it? | |
| 18:22:24 | jaypipes | edleafe: the soft affinity "filters" are implemented as weighers. | |
| 18:22:28 | openstackgerrit | Matthew Edmonds proposed openstack/nova master: improve support matrix notes https://review.openstack.org/540534 | |
| 18:22:38 | jaypipes | edleafe: https://github.com/openstack/nova/blob/master/nova/scheduler/weights/affinity.py | |
| 18:24:01 | edleafe | jaypipes: that doesn't use any sort of "distance" concept. It just favors those things that meet (anti)affinity | |
| 18:24:39 | jaypipes | edleafe: correct. | |
| 18:26:10 | jaypipes | edleafe: the distance thing is something we need in order to understand the difference between various failure domain sizes. it's also necessary for informing placement about the different "levels" of affinity. right now, Nova only knows one level (the compute *host* (note: *not* the compute *node*). In other words, Ironic can't use the existing affinity filters/weights in Nova. | |
| 18:26:31 | jaypipes | edleafe: this is partly to address that issue: https://review.openstack.org/#/c/529135/ | |
| 18:27:52 | edleafe | jaypipes: yeah, I like that | |
| 18:28:15 | openstackgerrit | Eric Berglund proposed openstack/nova master: Use correct arguments in task inits https://review.openstack.org/543571 | |
| 18:28:59 | jaypipes | edleafe: of course, that doesn't touch placement... | |
| 18:29:11 | edleafe | jaypipes: understood | |
| 18:30:16 | edleafe | jaypipes: my concern is that adding the new tables and relations you proposed on Friday would not be necessary for the vast majority of (anti)affinity cases. We could do it with placement aggs | |
| 18:31:20 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Enable test_volume_backed_live_migration in tempest https://review.openstack.org/528104 | |
| 18:31:35 | mriedem | edleafe: we don't really know what the vast majority of anything is | |
| 18:31:36 | mriedem | usage wise | |
| 18:31:37 | openstackgerrit | Merged openstack/python-novaclient stable/pike: Avoid tox_install.sh for constraints support https://review.openstack.org/543115 | |
| 18:32:04 | edleafe | mriedem: and what we do know may change | |
| 18:32:06 | mriedem | i want a minimum of 3 DB servers, put on different hosts if you can, but don't fail if you can't | |
| 18:32:06 | openstackgerrit | Merged openstack/python-novaclient stable/pike: Zuul: Remove project name https://review.openstack.org/541370 | |
| 18:32:07 | edleafe | s/may/will | |
| 18:32:07 | openstackgerrit | Merged openstack/python-novaclient stable/ocata: Avoid tox_install.sh for constraints support https://review.openstack.org/543114 | |
| 18:32:36 | mriedem | we're going to be proposing a spec for something that builds on the soft affinity stuff | |
| 18:32:44 | mriedem | to put a limit on the softness | |
| 18:32:51 | edleafe | mriedem: sure. The complicating part is I want three servers, at least two racks away from each other | |
| 18:33:07 | edleafe | not just on different racks | |
| 18:33:22 | mriedem | yeah the distance concept is complicated | |
| 18:35:34 | cdent | what does "two rack away" even mean? | |
| 18:36:48 | edleafe | cdent: it would depend on the operator mapping out their DC, and assigning values to each "location" | |
| 18:36:50 | dansmith | cdent: separated by power and TOR switch | |
| 18:37:09 | dansmith | cdent: so two adjacent racks might share a power domain, but not TOR switch, | |
| 18:37:27 | cdent | dansmith: I understand why people want what you just described in terms of "power" and "TOR" but don't see how that is a "distance of 2" | |
| 18:37:28 | dansmith | so two away would mean not adjacent at the next level up in separation | |
| 18:37:45 | cdent | so "2" is something the operator is defining? | |
| 18:37:46 | dansmith | cdent: it's a simpler way to accomplish the same thing | |
| 18:37:51 | dansmith | yeah | |
| 18:38:06 | dansmith | I think we said we'd try to work up some guidelines | |
| 18:38:19 | dansmith | that they could follow to try to have some sort of a uniform idea about said things, | |
| 18:38:25 | edleafe | dansmith: couldn't it be simplified to "not in the same power domain"? | |
| 18:38:42 | dansmith | but at the end of the day, it'll come down to your layout | |
| 18:39:24 | dansmith | edleafe: sure, but then you start providing the "not power domain and not network domain and not cooling domain", and distance is a simpler way to describe relative closeness of two thngs | |
| 18:40:15 | edleafe | dansmith: I'm not following. Are those domains nested? | |
| 18:40:19 | dansmith | I believe that was jaypipes' original intent, to provide a way to use a simple metric for such things instead of requiring the user to know about and upload a full map | |
| 18:40:42 | dansmith | edleafe: in my example yeah | |
| 18:41:32 | edleafe | dansmith: ok, so that could be simplified to "not in the outermost grouping I care about", right? | |