| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-30 | |||
| 16:37:46 | openstackgerrit | Doug Hellmann proposed openstack/nova master: add whereto for testing redirect rules https://review.openstack.org/516385 | |
| 16:40:24 | efried | jaypipes I'm about to be afk for a couple of hours, but: We do need to distinguish between unnumbered and numbered, remember, because the unnumbered can come from any RP in the tree or aggregate; whereas numbered has to come from exactly the same RP. | |
| 16:40:49 | efried | I'm not a fan of naming them 'numbered' and 'unnumbered', but thus far haven't been able to come up with better nomenclature. | |
| 16:41:09 | jaypipes | efried: no, the request group just means "in the same provider tree". | |
| 16:41:39 | efried | jaypipes This was the whole thing the spec was about. | |
| 16:41:54 | efried | jaypipes Same provider tree doesn't work for e.g. a VF and its bandwidth. | |
| 16:42:19 | efried | jaypipes See use cases in the spec. | |
| 16:42:22 | jaypipes | efried: Sorry, by "same provider tree" I mean "same provider or its descendants" | |
| 16:42:35 | jaypipes | efried: and each request group means exactly the same thing. | |
| 16:43:13 | efried | jaypipes Whoah. That's totally not what happened in the spec. To be continued... | |
| 16:55:52 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: libvirt: do not remove inst_base when volume-backed during resize https://review.openstack.org/516395 | |
| 16:55:53 | mriedem | jaypipes: this should allow reproducing that bug in the NFS job ^ | |
| 17:07:43 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Pass the correct image to build_request_spec in conductor.rebuild_instance https://review.openstack.org/516400 | |
| 17:29:02 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: Pass the correct image to build_request_spec in conductor.rebuild_instance https://review.openstack.org/516404 | |
| 17:59:46 | openstackgerrit | Merged openstack/nova master: rp: remove _HasAResourceProvider mixin https://review.openstack.org/509036 | |
| 18:19:56 | openstackgerrit | David Rabel proposed openstack/nova master: Fix format in live-migration-usage.rst https://review.openstack.org/516416 | |
| 18:59:48 | efried | jaypipes Now a good time? | |
| 19:13:29 | jaypipes | efried: sure | |
| 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 | sdague | oh, I guess the issue is grenade doesn't do that yet | |
| 19:40:24 | mriedem | sdague: the problem isn't superconductor + ceph, | |
| 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: adds REST API for nested providers https://review.openstack.org/384807 | |
| 19:52:05 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: allow filter providers in tree https://review.openstack.org/377215 | |
| 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: _get_usages_by_provider_and_rc not filter on RC ID https://review.openstack.org/514649 | |
| 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:52 | openstackgerrit | Eric Fried proposed openstack/nova master: Add ProviderSummaryList object https://review.openstack.org/514198 | |
| 20:10:52 | openstackgerrit | Eric Fried proposed openstack/nova master: Add _get_traits_by_rp_ids method https://review.openstack.org/511184 | |
| 20:10:53 | openstackgerrit | Eric Fried proposed openstack/nova master: Add AggregatedProviderSummary[List] objects https://review.openstack.org/514200 | |
| 20:10:53 | openstackgerrit | Eric Fried proposed openstack/nova master: More caches: ProviderSummary, ProviderSummaryList https://review.openstack.org/514199 | |
| 20:10:54 | openstackgerrit | Eric Fried proposed openstack/nova master: AggregatedProvierSummary.as_allocation_request_obj https://review.openstack.org/514651 | |
| 20:10:54 | openstackgerrit | Eric Fried proposed openstack/nova master: Add has_resources to AggregatedProviderSummary https://review.openstack.org/514650 | |
| 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. | |