21:00:54 <dansmith> #startmeeting nova_cells
21:00:55 <openstack> Meeting started Wed Nov 29 21:00:54 2017 UTC and is due to finish in 60 minutes.  The chair is dansmith. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:58 <openstack> The meeting name has been set to 'nova_cells'
21:00:59 <e0ne> rdopiera: the same for me. we're working on downstream pike  too :)
21:01:01 <mriedem> o/
21:01:02 <tssurya_> o/
21:01:10 <melwitt> o/
21:01:12 <dansmith> #topic bugs
21:01:21 <dansmith> so, belmiro reported an issue recently,
21:01:25 <dansmith> although not via a bug
21:01:28 <dansmith> and I put up a patch:
21:01:36 <dansmith> https://review.openstack.org/#/c/523187/
21:01:42 <mriedem> ah i was going to ask for a recap of this
21:01:55 <dansmith> he said that worked for him, so I probably need to get him to file a bug and then clean that up so we can merge/backport it
21:02:08 <dansmith> I guess we can't really send it back to newton, although that's where he wants it
21:02:15 <mriedem> this is also specific to how he's doing the api db setup per child cell yes?
21:02:30 <dansmith> yes, although this is the right thing to be doing anyway I think
21:02:31 <tssurya_> mriedem : yes
21:03:18 <mriedem> so we're deleting the build request here so that it doesn't get confused at the top when listing instances?
21:03:23 <dansmith> yeah
21:03:30 <dansmith> otherwise it obscures looking for the real instance
21:03:40 <dansmith> since the mere presence means "don't even look for an instance"
21:03:57 <mriedem> and if you're doing global placement with a single api db, we'd likely get the build request not found, which we ignore
21:04:08 <mriedem> i know nectar said they are doing global placement, not per child cell
21:04:21 <dansmith> right, because the compute api in the lower cell would have already done it
21:04:27 <mriedem> ok
21:04:28 <dansmith> yeah and I don't think godaddy was far enough along to have thought through this
21:04:40 <mriedem> godaddy was waiting to see how everyone else (2 of them) had done it
21:04:43 <dansmith> I dunno how many cells they have, but I'm kinda assuming they're somewhere between cern and nectar in terms of numbers
21:04:50 <dansmith> heh, so that worked out well for them
21:04:54 <dansmith> two examples, two answers
21:05:14 <mriedem> i was also going to ask if we were going to push patches up for the issues cern runs it, so i'm happy to see we are
21:05:24 <dansmith> yeah, I think we should for sure
21:05:27 <mriedem> i figured we'd at least need somewhere/somethign to track patches people need to transition from v1 to v2
21:05:41 <dansmith> I'd rather it be integrated when and where possible
21:05:53 <dansmith> so I assume you're cool with this back to ocata but not newton?
21:05:54 <mriedem> tssurya_: can you follow up with belmiro to open a bug?
21:05:58 <mriedem> dansmith: yeah
21:06:02 <tssurya_> mriedem : yes of course
21:06:09 <dansmith> tssurya_: and just comment on the patch with the bug number or something
21:06:16 <dansmith> tssurya_: you could open it too, doesn't have to be belmiro
21:06:24 <tssurya_> dansmith : yes , I will follow this up
21:06:27 <dansmith> cool, thanks
21:06:48 <dansmith> anything else on this or other bugs?
21:07:14 <tssurya_> not from me
21:07:26 <mriedem> i don't have any bugs in mind
21:07:28 <dansmith> #topic open reviews
21:07:43 <dansmith> so the big one still open here is ed's alternates patches,
21:07:53 <dansmith> which I honestly haven't looked at much since sydney for various reasons
21:07:57 <dansmith> some good reasons, so not so good ones
21:08:09 <mriedem> i made it about halfway,
21:08:17 <melwitt> same, it's on my todo for today or tomorrow
21:08:20 <dansmith> there's also melwitt's fixtures cleanup, which I think I have uncommitted comments on,
21:08:20 <mriedem> jay was -1 on something in the middle so thta's where i stopped b/c ed was on vacation
21:08:26 <dansmith> yeah
21:09:02 <dansmith> any other open reviews we need to be highlighting here?
21:09:08 <mriedem> kinda
21:09:12 <mriedem> just a mention of https://review.openstack.org/#/c/517273/25
21:09:16 <mriedem> i brought this up the other night,
21:09:20 <mriedem> paging migrations across cells,
21:09:22 <dansmith> oh right
21:09:24 <dansmith> ugh
21:09:26 <mriedem> he changed it from PS21 to PS25,
21:09:36 <mriedem> and he's moving in what i think is the right direction, just in the wrong way
21:09:37 <melwitt> I have a patch up to remove old quotas code, not directly related to cells but related to the quota changes from last cycle https://review.openstack.org/511689
21:09:46 <mriedem> so i've dumped more comments in there,
21:09:57 <mriedem> i think he basically wants to page like we used to do for instances, and then just simple merge sort the results at the end
21:10:01 <mriedem> no scatter/gather fanciness
21:10:38 <dansmith> the scatter gather is easier than doing it manually because it handles iterating cells for you
21:10:51 <dansmith> and does it in parallel, so not sure there's any benefit if you're going to merge at the end
21:11:28 <mriedem> the other night when i brought this up,
21:11:40 <mriedem> you seemed to agree that we didn't need the overhead of the stuff used for instance_list.py
21:11:52 <dansmith> yeah, right, but the scatter/gather thing is not instance_list,
21:11:58 <dansmith> it's just the bit in context.py which iterates cells for you
21:12:04 <dansmith> maybe we're confusing terminology
21:12:14 <dansmith> he _should_ use the context.scatter_gather_all_cells() thing
21:12:18 <mriedem> he's using scatter/gather to find the cell that the marker is in
21:12:35 <mriedem> and then iterating the cells starting at that cell, i think
21:12:47 <mriedem> not even probably, which is another issue here
21:12:54 <dansmith> not sure why that helps really
21:13:29 <dansmith> also, since this is new, we could do something smarter about the marker id so we can avoid doing the two-stage marker lookup right?
21:13:46 <mriedem> like, encode the cell id in the marker?
21:13:58 <dansmith> yeah
21:14:06 <mriedem> we could,
21:14:23 <mriedem> that means some custom marker/paging code in the rest api handler, which is different from how everything else builds the next links
21:14:23 <dansmith> or include a next-page: <url> thing in the response and you just call that, so we can change it over time
21:14:40 <dansmith> yep, indeed
21:15:12 <dansmith> anyway, if we don't change that, then he just has to look up the marker and do the thing, but I would scatter both times, personally
21:15:14 <dansmith> no reason not to
21:15:42 <mriedem> i have to say,
21:15:48 <dansmith> you wish for death?
21:15:50 <dansmith> yeah me too
21:16:09 <mriedem> i'm a bit confused on how we'd get the marker correct once the results are sorted, but i haven't thought through it all
21:16:13 <mriedem> like i know this is working for instances
21:16:45 <dansmith> well, you still have to do the local marker thing per cell
21:16:46 <mriedem> e.g. if i page across cell1 to cell2 and my marker is in cell2 before sorting,
21:16:53 <mriedem> but then sort and my marker is in cell1, its weird
21:17:00 <dansmith> that's why encoding something more in the marker id would let us avoid that
21:17:34 <mriedem> hmm, ok he dropped the local marker stuff he had in PS21
21:17:40 <dansmith> because you have to look up the marker globally by uuid, then look up the marker per cell by >=$sort_field, and then use that as your marker= to the actual list call
21:18:20 <dansmith> if we encoded the marker uuid, cell id and the sort key from the global marker in the result, then we wouldn't have to do all that and could restart the paginated query right away
21:19:04 <dansmith> anyway, let's not design it here, we can discuss elsewhere
21:20:07 <dansmith> any other reviews to highlight?
21:20:33 <mriedem> not me
21:20:37 <dansmith> #topic open discussion
21:20:52 <dansmith> so I had a thing to point out here, but I forgot what it was
21:21:38 <melwitt> hmm
21:21:54 <dansmith> anyone else got anything?
21:21:59 <mriedem> nope
21:22:05 <melwitt> nay
21:22:09 <tssurya_> nope
21:22:22 <dansmith> okie doke
21:22:23 <dansmith> #endmeeting