| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-30 | |||
| 15:43:59 | mriedem | namnh: should eventually show up here https://wiki.openstack.org/wiki/Forum/Sydney2017 | |
| 15:44:10 | namnh | mriedem: I asked him, but he does not know :) I've just asked Arkady, he suggest me to ask Jay :( | |
| 15:44:42 | mriedem | who is the actual session leader? | |
| 15:45:14 | mriedem | https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20451/fast-forward-upgrades | |
| 15:45:20 | mriedem | eric mccormick | |
| 15:45:23 | mriedem | find him | |
| 15:46:43 | namnh | mriedem: according to this mailling-list http://lists.openstack.org/pipermail/openstack-dev/2017-September/122361.html . that is Arkady | |
| 15:47:08 | mriedem | great... | |
| 15:47:24 | mriedem | dansmith: is lyarwood not going to be at the summit? | |
| 15:47:29 | dansmith | I don't think so | |
| 15:47:57 | mdbooth | melwitt: mriedem Any chance we can merge this one: https://review.openstack.org/#/c/507202/ | |
| 15:48:00 | mriedem | ok and the person moderating the session is sending people to jay...who won't be at the summit, nor is involved in fast forward upgrades | |
| 15:48:06 | namnh | mriedem: i asked both of them, it seems there is no a list of members for now | |
| 15:48:08 | mdbooth | Not sure what the current hold up is, but it's still a data corruptor | |
| 15:49:15 | mriedem | mdbooth: i believe the hold up is getting a run with https://review.openstack.org/#/c/508163/2 | |
| 15:49:21 | mriedem | in the live migration job to make sure nothing is regressed | |
| 15:49:46 | mriedem | namnh: ok i'll ask in the ML then | |
| 15:50:52 | namnh | mriedem: thanks in advance, because I'd like to know a list of members to prepare something for discussion :) | |
| 15:51:20 | mdbooth | mriedem: Thanks. I see melwitt spammed it a few times already. I've spammed it again. | |
| 15:51:58 | namnh | mriedem: are you joining FFU-session? | |
| 15:52:20 | mdbooth | Eurgh, gonna have to rebase it | |
| 15:52:22 | mriedem | namnh: idk | |
| 15:52:42 | mriedem | FFU isn't really a focus area of mine | |
| 15:53:24 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] POST /allocations to set allocations for >1 consumers https://review.openstack.org/500073 | |
| 15:53:52 | namnh | mriedem: i see, thanks for your time | |
| 15:55:30 | openstackgerrit | Matthew Booth proposed openstack/nova master: libvirt: Don't VIR_MIGRATE_NON_SHARED_INC without migrate_disks https://review.openstack.org/507202 | |
| 15:55:31 | openstackgerrit | Matthew Booth proposed openstack/nova master: DNM: Run test_volume_backed_live_migration and iscsi test https://review.openstack.org/508163 | |
| 15:55:44 | namnh | jaypipes: :)) i see | |
| 16:10:15 | mriedem | dansmith: fyi added starter etherpads for the nova sessions i'm aware of https://wiki.openstack.org/wiki/Forum/Sydney2017#List_of_Sessions_.26_Etherpads | |
| 16:10:38 | dansmith | mriedem: cool | |
| 16:14:39 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807 | |
| 16:14:40 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693 | |
| 16:32:14 | openstackgerrit | Matt Riedemann proposed openstack/nova master: rp: break functions out of _set_traits() https://review.openstack.org/509908 | |
| 16:36:48 | openstackgerrit | Doug Hellmann proposed openstack/nova master: add whereto for testing redirect rules https://review.openstack.org/516385 | |
| 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) | |