| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-30 | |||
| 19:14:29 | efried | jaypipes So first of all I'd like to set the baseline that what I've got proposed thus far is what's described in the spec. | |
| 19:14:39 | efried | jaypipes Then we can go into whether the spec is wrong, and what to do about that. | |
| 19:14:54 | efried | jaypipes I was just going over the comments on the spec myself... | |
| 19:14:59 | efried | https://review.openstack.org/#/c/510244/ | |
| 19:16:14 | efried | jaypipes Unfortunately I realize that this spec was basically written, reviewed, and approved while you were out. (I do remember you acking it when you got back, but I recognize that's not the same thing as being involved in the review process.) | |
| 19:19:59 | jaypipes | efried: the only difference I see between the resources= key that exists now and the resourcesN= keys that are in that spec is that the resources= key can have part of its request satisfied by a sharing provider. | |
| 19:21:04 | efried | jaypipes In which case we nevertheless need to keep them semantically separate when processing them, nah? | |
| 19:21:50 | efried | jaypipes I mean, I think we still wanted to get narrower than that, but that at the very least should be enough motivation to have a distinction. | |
| 19:22:00 | jaypipes | efried: sure, but I'd prefer we just annotate the RequestGroup with a "can_use_shared_resources" attribute or similar | |
| 19:22:42 | efried | jaypipes Oh, rather than calling it 'numbered' vs 'unnumbered', sure I'm open to better ways of describing. | |
| 19:22:45 | jaypipes | right | |
| 19:22:57 | efried | jaypipes But IIUC, we can't share an object between the scheduler side and the placement side, can we? | |
| 19:23:06 | jaypipes | cuz numbered and unnumbered doesn't indicate what the diff is. | |
| 19:23:11 | jaypipes | that was my complaint. | |
| 19:23:59 | jaypipes | efried: no, we can't share an object, but that's not the point. The point is to have an attribute that indicates what the difference between the things is. "numbered" and "unnumbered" doesn't do that. | |
| 19:24:06 | jaypipes | that's what I was trying to say | |
| 19:24:18 | efried | jaypipes Cool, I'm good with that for sure. | |
| 19:24:30 | efried | jaypipes Back to the other issue... | |
| 19:24:52 | jaypipes | efried: the over-the-HTTP-wire syntax of using numbers is fine. I'm just saying when creating objects that represent these things, let's not call them "unnumbered" or "numbered" | |
| 19:25:00 | efried | jaypipes Dig | |
| 19:25:03 | jaypipes | k, cool. | |
| 19:25:09 | openstackgerrit | Andreas Jaeger proposed openstack/nova master: DNM - testing check-requirements https://review.openstack.org/516195 | |
| 19:25:22 | efried | jaypipes So the "non-sharing" group can get resources from any RP in the tree or any RP in the same aggregate. We're agreed on that. | |
| 19:25:31 | efried | jaypipes Bah, I meant the "sharing" group. | |
| 19:25:38 | efried | Cause this wasn't confusing enough. | |
| 19:26:30 | efried | jaypipes Per the spec, the "non-sharing" group is limited to getting its resources from exactly one RP. No trees, sub-branches, etc. | |
| 19:27:12 | jaypipes | efried: ok, if that's what was agreed to in the spec, cool. | |
| 19:27:50 | efried | jaypipes Okay, good deal. I think the thing about using branches *might* work, but only because we can't think of a case right now where a parent and child would both provide inventory in the same RC. | |
| 19:27:58 | efried | Cleaner to keep it same-RP. | |
| 19:28:20 | jaypipes | right | |
| 19:29:13 | jaypipes | efried: how about RequestGroup.use_same_provider as the attribute name and make the parser set that to True for any request group with a number in the query param. | |
| 19:29:27 | efried | jaypipes Dig. | |
| 19:29:31 | jaypipes | coolio. | |
| 19:29:49 | efried | jaypipes So do you want me to have a (separately-defined) RequestGroup class on the placement side of the world as well? | |
| 19:30:03 | efried | Not a DB object, obviously; just a util/helper. | |
| 19:33:39 | mriedem | sdague: want to send this through? https://review.openstack.org/#/c/508271/ | |
| 19:33:45 | mriedem | otherwise i'm just going to self approve | |
| 19:35:19 | dansmith | mriedem: I got it | |
| 19:35:25 | mriedem | thanks | |
| 19:35:27 | dansmith | sorry I wasn't paying attention to that | |
| 19:36:12 | openstackgerrit | Matt Riedemann proposed openstack/nova master: DNM: Run test_volume_backed_live_migration and iscsi test https://review.openstack.org/508163 | |
| 19:38:49 | jaypipes | efried: yeah, prolly. | |
| 19:39:01 | efried | jaypipes ight. | |
| 19:39:02 | jaypipes | efried: you can put it in nova/api/openstack/placement/ | |
| 19:39:06 | efried | ack | |
| 19:39:18 | jaypipes | efried: and the other in /nova/scheduler/ somewhere | |
| 19:39:28 | efried | jaypipes It's in utils at the moment, will leave it there. | |
| 19:39:31 | jaypipes | efried: should just be a POD object (plain ol' data) | |
| 19:39:37 | jaypipes | efried: sure, that's cool | |
| 19:39:38 | efried | yuh | |
| 19:40:06 | sdague | mriedem: is ceph going to eventually work on the super conductor stuff? | |
| 19:40:24 | mriedem | sdague: the problem isn't superconductor + ceph, | |
| 19:40:24 | sdague | oh, I guess the issue is grenade doesn't do that yet | |
| 19:40:27 | mriedem | the problem there is grenade | |
| 19:40:29 | mriedem | yup | |
| 19:41:12 | mriedem | sdague: which i half heartedly posted https://review.openstack.org/#/c/509803/ just to see how bad things blew up | |
| 19:41:17 | mriedem | but didn't really dig into it | |
| 19:41:35 | mriedem | appears to be a discover_hosts issue | |
| 19:41:49 | mriedem | http://logs.openstack.org/03/509803/1/check/gate-grenade-dsvm-neutron-ubuntu-xenial/d8414a5/logs/grenade.sh.txt.gz | |
| 19:44:07 | mriedem | yeah the configs don't get set properly, because e.g. nova-cpu.conf has api_database stuff in it http://logs.openstack.org/03/509803/1/check/gate-grenade-dsvm-neutron-ubuntu-xenial/d8414a5/logs/etc/nova/nova-cpu.conf.txt.gz | |
| 19:46:32 | openstackgerrit | Merged openstack/nova master: Pass the correct image to build_request_spec in conductor.rebuild_instance https://review.openstack.org/515530 | |
| 19:52:04 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: add nested resource providers https://review.openstack.org/377138 | |
| 19:52:05 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: allow filter providers in tree https://review.openstack.org/377215 | |
| 19:52:05 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807 | |
| 19:52:06 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693 | |
| 19:52:36 | jaypipes | cdent: turned out that you identified some useless code that should be removed. so I did. ^ | |
| 20:02:07 | sdague | mriedem: yeh, let me try a thing with that | |
| 20:02:49 | cdent | jaypipes: yay less code! | |
| 20:08:36 | cfriesen | when live-migrating with block-migration = "auto", does anyone know offhand where we do the check to see if block migration is needed or not? | |
| 20:10:51 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Add _get_providers_with_any_resource method https://review.openstack.org/514197 | |
| 20:10:51 | openstackgerrit | Eric Fried proposed openstack/nova master: _get_usages_by_provider_and_rc not filter on RC ID https://review.openstack.org/514649 | |
| 20:10:52 | openstackgerrit | Eric Fried proposed openstack/nova master: Add _get_traits_by_rp_ids method https://review.openstack.org/511184 | |
| 20:10:52 | openstackgerrit | Eric Fried proposed openstack/nova master: Add ProviderSummaryList object https://review.openstack.org/514198 | |
| 20:10:53 | openstackgerrit | Eric Fried proposed openstack/nova master: More caches: ProviderSummary, ProviderSummaryList https://review.openstack.org/514199 | |
| 20:10:53 | openstackgerrit | Eric Fried proposed openstack/nova master: Add AggregatedProviderSummary[List] objects https://review.openstack.org/514200 | |
| 20:10:54 | openstackgerrit | Eric Fried proposed openstack/nova master: Add has_resources to AggregatedProviderSummary https://review.openstack.org/514650 | |
| 20:10:54 | openstackgerrit | Eric Fried proposed openstack/nova master: AggregatedProvierSummary.as_allocation_request_obj https://review.openstack.org/514651 | |
| 20:10:55 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: rewrite AllocationCandidates.get_by_filters https://review.openstack.org/479766 | |
| 20:10:58 | efried | jaypipes In other news, if you have some time to look at this WIP patch ^ there's either a SQL bug or a test case bug. | |
| 20:11:14 | efried | jaypipes This one: https://review.openstack.org/514197 | |
| 20:11:54 | jaypipes | efried: wasn't that alex_xu's? | |
| 20:12:05 | efried | jaypipes alex_xu and I have been pair programming it. | |
| 20:12:11 | jaypipes | cfriesen: mriedem would know best. | |
| 20:12:18 | jaypipes | efried: k. | |
| 20:12:47 | mriedem | ummm | |
| 20:12:53 | efried | jaypipes Gah, pair "developing", per edleafe | |
| 20:12:59 | efried | which is different. | |
| 20:13:05 | mriedem | cfriesen: you're going to have to check the code | |
| 20:13:49 | jaypipes | mriedem: you're all about that flag. | |
| 20:14:37 | cfriesen | jaypipes: mriedem: heh...I think I found it. git history is my friend | |
| 20:14:59 | cfriesen | efried: someone's developing a pair? | |
| 20:16:20 | efried | cfriesen It's a slow process. But actually more efficient than one at a time. | |
| 20:17:09 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-ref: document caveats with scheduler hints https://review.openstack.org/516442 | |
| 20:17:13 | mriedem | sdague: how is this for documented ambiguity? :) ^ | |
| 20:18:02 | sdague | mriedem: yeh, pretty much | |
| 20:18:10 | mriedem | mordred: do you ever have to rely on scheduler hints? | |
| 20:19:26 | clarkb | mriedem: I think any of that would be largely transparent to infra at least since we are just "public" cloud ocnsumers for the most part. and since infracloud is single tenant we don't need any special scheduling we just schedule to any of our nodes | |
| 20:20:40 | mriedem | clarkb: ok. i just figure anyone that is a user of openstack and has to rely on scheduler hints for their app to work, probably has a hell of a time making that app work across different clouds - but i have no idea if something like that exists in the wild | |
| 20:21:16 | clarkb | I know ovh schedules us to dedicate resources so we don't noisy neighbor their customers | |
| 20:21:25 | clarkb | they do this with a flavor just for us not sure if that involves scheduler hints | |