Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-30
15:17:29 bauzas but just explaining about our tags
15:17:37 mriedem umm, ok
15:17:45 bauzas but meh
15:17:50 jaypipes efried: what happened to the patch about parsing numbered request groups that I commented on?
15:17:57 bauzas mriedem: no worries, I'll just pass a list of tags
15:19:19 efried jaypipes If you're talking about https://review.openstack.org/#/c/515151/ -- I reworked it for you & gibi. gibi left a couple little tweaks that I'll get to later today, so if you want to hit it again, I can also take care of anything else you find.
15:19:53 mriedem bauzas: were you going to drop your -1 on this? https://review.openstack.org/#/c/515530
15:20:06 jaypipes efried: k, thanks, yeah, that's the one. I was looking at https://review.openstack.org/#/c/514091/ and wondering where it was...
15:20:27 efried jaypipes Yeah, that one's coming from the placement side.
15:20:29 mriedem bauzas: also fyi in case you didn't notice this from the weekend https://review.openstack.org/#/c/515530/
15:20:35 jaypipes efried: k
15:20:37 efried jaypipes Also needs a review, if you please :)
15:20:44 bauzas mriedem: yup, just forgot to remove it
15:20:56 jaypipes efried: yup, I'm on it. just finished reviewing cdent's series on POST /allocations. Moving on to yours.
15:21:05 efried jaypipes Thanks.
15:21:07 jaypipes edleafe is still reworking the Selection object series, right?
15:21:42 mriedem bauzas: i think we should try and get https://review.openstack.org/#/c/515530/ into newton before eol
15:21:46 mriedem since we shipped a broken feature basically
15:22:15 edleafe jaypipes: the object is fine. It's the RPC change that's being re-worked
15:24:33 jaypipes edleafe: gotcha.
15:25:27 openstackgerrit Jay Pipes proposed openstack/nova master: placement: add nested resource providers https://review.openstack.org/377138
15:25:28 openstackgerrit Jay Pipes proposed openstack/nova master: placement: allow filter providers in tree https://review.openstack.org/377215
15:25:28 openstackgerrit Jay Pipes proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807
15:25:29 openstackgerrit Jay Pipes proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693
15:26:17 jaypipes dansmith, gibi, edleafe, cdent, bauzas, mriedem: ok ^ should be good to review. First one to microversion 1.12 wins some Halloween candy.
15:29:31 mriedem you can't tempt me with halloween candy
15:34:50 efried alex_xu Still awake?
15:35:50 cdent jaypipes: I don’t think we want zero value resources? See my response on https://review.openstack.org/#/c/500073/27
15:40:48 jaypipes cdent: yeah, guess I was confused.
15:41:11 namnh jaypipes: hi Jay, could I ask you a question? have you created a etherpad or something to note a list of members who will join fast forward upgrade session at the sydney summit?
15:41:29 openstackgerrit Matt Riedemann proposed openstack/nova master: Add microversion to allow setting flavor description https://review.openstack.org/515213
15:41:41 jaypipes cdent: the magic zeroed allocations are only internal to the AllocationList.create_all() method then...
15:41:53 mriedem namnh: that's a question for lyarwood probably
15:42:10 jaypipes namnh: yeah, especially since I won't be in Sydney :)
15:42:22 cdent yes, I think I may have said that was the intent on a comment on the change that adjusted create_all()
15:42:51 cdent (that it was an internal thing to be jiggered at the api controller level for special powers)
15:43:35 jaypipes cdent: k, cool with me then.
15:43:41 cdent ✔\
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.

Earlier   Later