| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-30 | |||
| 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 | |
| 20:21:32 | clarkb | but ya we don't directly interact with scheduler hints at least | |
| 20:21:54 | mriedem | clarkb: yeah that wouldn't be scheduler hints, just extra specs and host aggregates | |
| 20:22:25 | openstackgerrit | Eric Fried proposed openstack/nova master: Parse granular resources/traits from extra_specs https://review.openstack.org/515151 | |
| 20:22:25 | openstackgerrit | Eric Fried proposed openstack/nova master: Granularize resources_from_{flavor|request_spec} https://review.openstack.org/515223 | |
| 20:22:26 | openstackgerrit | Eric Fried proposed openstack/nova master: ResourceRequest.to_querystring() https://review.openstack.org/515811 | |
| 20:23:26 | mriedem | i need to know if cloud x has a scheduler hint so i can tell it which lpar i want my powervm instance on | |
| 20:23:32 | mriedem | because lpar 44 is the one i want | |
| 20:26:41 | jaypipes | mriedem: and how would a cloud user know that lpar 44 is the one they want? :) | |
| 20:27:45 | sdague | jaypipes: probably the same way they'd know which az they wanted, it was documented somewhere. | |
| 20:28:28 | jaypipes | sdague: heh | |
| 20:29:10 | jaypipes | sdague: my point is that the AZ is a publicly-visible grouping construct that OpenStack exposes. LPARs are not publicly-visible constructs... | |
| 20:30:05 | jaypipes | sdague: in the same sense that on AWS I cannot request a particular compute host (because, well, as a cloud user, I don't *know* what the compute hosts are...) | |
| 20:30:48 | jaypipes | sdague: but maybe you're just pulling my leg... I can't tell :) | |
| 20:31:38 | mriedem | i'm just using a ridiculous example | |
| 20:32:11 | mriedem | but yeah, just saying, one cloud/product docs could have any number of weird things tailored for their users | |
| 20:34:33 | mriedem | if we actually cared, we'd have some kind of scheduler_hints API to return what *this* cloud supports for scheduler hints, so it would at least be discoverable | |
| 20:35:12 | jaypipes | mriedem: sure, agreed. discoverable, not interoperable... | |
| 20:35:25 | mriedem | right, neither are flavors | |
| 20:35:32 | jaypipes | mriedem: ack | |