| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-12 | |||
| 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 | openstackgerrit | Merged openstack/python-novaclient stable/pike: Zuul: Remove project name https://review.openstack.org/541370 | |
| 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:07 | openstackgerrit | Merged openstack/python-novaclient stable/ocata: Avoid tox_install.sh for constraints support https://review.openstack.org/543114 | |
| 18:32:07 | edleafe | s/may/will | |
| 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? | |
| 18:41:48 | openstackgerrit | Mark Goddard proposed openstack/nova master: Don't JSON encode instance_info.traits for ironic https://review.openstack.org/543574 | |
| 18:42:14 | dansmith | edleafe: well, that's not the outermost group | |
| 18:42:27 | dansmith | because you'd still have potentially room, building, site, region, etc | |
| 18:42:37 | edleafe | dansmith: of course | |
| 18:43:05 | dansmith | we could define the way people have to nest things (i.e. TOR is always smaller scope than power) but that won't fly of course | |
| 18:43:07 | edmondsw | mriedem I just added the queens-rc-potential tag to https://bugs.launchpad.net/nova/+bug/1748950 | |
| 18:43:10 | edleafe | dansmith: you would define these groupings by what you care about as far as affinity is concerned | |
| 18:43:10 | openstack | Launchpad bug 1748950 in OpenStack Compute (nova) "PowerVM driver passing bad kwargs into Task init method" [Undecided,In progress] - Assigned to Eric Berglund (esberglu) | |
| 18:43:39 | mriedem | edmondsw: how did this not fail CI? | |
| 18:43:42 | dansmith | yeah, we could totally add a way to define the groupings, and a complex way to say which things you do and don't care about | |
| 18:43:59 | dansmith | all I'm saying is that distance as a simple metric to abstract that is pretty straightforward | |
| 18:44:03 | edmondsw | mriedem it only happens if you have non-ascii characters in the instance | |
| 18:44:03 | edleafe | dansmith: or we could add a simple way to say that | |
| 18:44:05 | mriedem | edmondsw: oh i see, unicode | |
| 18:44:32 | edmondsw | mriedem it actually did cause a log error in CI which is how we noticed it, on update_server_name | |
| 18:44:43 | edmondsw | but didn't fail the test | |
| 18:44:50 | edmondsw | was just on cleanup | |
| 18:45:25 | mriedem | is there no way to have a test for this fix? | |
| 18:46:54 | edmondsw | mriedem yeah, good point... I'd asked esberglu to look at test but then had a brain fart when reviewing I guess | |
| 18:47:27 | mriedem | pew | |
| 18:48:29 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Re-propose use Neutron's new port binding API https://review.openstack.org/543578 | |
| 18:50:31 | mriedem | efried: want to re-propose this for rocky? https://review.openstack.org/#/c/505209/ | |
| 18:51:48 | openstackgerrit | Dan Smith proposed openstack/nova master: Drop compute RPC 4.x compatibility https://review.openstack.org/543580 | |
| 18:52:35 | jaypipes | dansmith, mriedem: https://etherpad.openstack.org/p/going-the-distance has ideas about the distance concept... | |
| 18:52:48 | mriedem | nice pad name | |
| 18:53:26 | mriedem | dansmith: you want to -W that rpc change until we release so someone doesn't accidentally merge it? | |
| 18:53:52 | dansmith | mriedem: rc1 is tagged so we're good no? | |
| 18:54:21 | mriedem | i don't know if we'll have something that requires a backport before GA | |
| 18:54:39 | dansmith | I'm going to argue against that really hard, | |
| 18:54:42 | openstackgerrit | Merged openstack/nova master: doc: mention that --on-shared-storage is not needed with nova evacuate https://review.openstack.org/542512 | |
| 18:54:47 | dansmith | but also, it won't invalidate this | |
| 18:54:48 | mriedem | granted backporting an rpc change for rc2 would be.. | |
| 18:54:54 | dansmith | but no crazy rush so that's fine | |
| 18:55:08 | openstackgerrit | Merged openstack/nova master: Update reno for stable/queens https://review.openstack.org/542658 | |
| 18:59:12 | esberglu | edmondsw: What's the best way to test this? I can assert that the __init__ methods are being passed the right args | |