17:00:16 <alaski> #startmeeting nova_cells
17:00:17 <openstack> Meeting started Wed Aug  3 17:00:16 2016 UTC and is due to finish in 60 minutes.  The chair is alaski. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:20 <openstack> The meeting name has been set to 'nova_cells'
17:00:25 <dansmith> ohai
17:00:30 <melwitt> o/
17:00:32 <mriedem> o/
17:00:58 <alaski> I'm not sure we have much to cover at this point so let's roll through this
17:01:03 <alaski> #topic Testing
17:01:24 <alaski> dansmith: I think you agreed to do a thing here involving grenade?
17:01:36 <dansmith> did I?
17:01:41 <dansmith> doesn't sound like me.
17:01:43 <mriedem> he did
17:01:50 <dansmith> what did I promise to do?
17:02:32 <mriedem> L396 https://etherpad.openstack.org/p/nova-newton-midcycle
17:02:36 <mriedem> somewhere around in there
17:02:42 <alaski> Forcing this is contingent on grenade testing. (TODO: dansmith)
17:02:49 <alaski> yeah, what mriedem said
17:03:08 <alaski> I'm going to assume there's nothing to report here then
17:03:12 <mriedem> yeah that was the todo
17:03:20 <mriedem> the other was investigating some rpc/db switching stuff
17:03:35 <dansmith> um
17:03:40 <dansmith> ot
17:03:57 <dansmith> it is not clicking for me, but nothing to report obviously.. we can chat after the meeting to get it back in my head
17:04:15 <alaski> okay
17:04:25 <alaski> moving on
17:04:29 <mriedem> steps: expand db, roll new code, things still work, then run the command, we don't lose stuff in between b/c we assume there is a single cell setup and we can do things as before cells v2
17:04:35 <mriedem> i think it was just having something run through the upgrade in grenade
17:04:39 <mriedem> from no cells to cells v2
17:05:09 <alaski> yeah, that rings a bell
17:05:13 <alaski> #topic Open Reviews
17:05:42 <alaski> so let's discuss what we're going to push for in Newton
17:05:53 <alaski> dansmith: what's the status of aggregates?
17:05:58 <alaski> I didn't see if that merged
17:06:01 <dansmith> merged
17:06:03 <dansmith> like a mofo
17:06:05 <alaski> excellent
17:06:35 <alaski> melwitt: what's the status of instance groups? does that need review at this point?
17:07:14 <melwitt> alaski: yes, it's all ready for review
17:07:23 <alaski> great
17:07:39 <melwitt> dansmith reviewed it recently and I updated it to address the comments
17:07:46 <alaski> I don't think it's critical for N, but would help simplify upgrades
17:08:00 <dansmith> yeah, we should try to get it in if we can I think
17:08:18 <alaski> agreed
17:08:29 <alaski> I'll add it to my queue
17:09:04 <alaski> I just pushed up a new revision to my series on deleting instances and then includin build_requests in instance show
17:09:20 <dansmith> what about quota?
17:09:25 <alaski> I have a few more patches to add covering instance list and scheduling to a cell
17:09:28 <dansmith> alaski: you're going to pick that up right? (I hope)
17:10:02 <alaski> I'm happy (not really) to look at that once I get my current series in shape
17:10:17 <mriedem> i've been through https://review.openstack.org/#/c/325985/ a few times already so should be good to push there
17:10:25 <mriedem> alaski: i'm going to have to ask you to push me on ^ though
17:10:31 <mriedem> i.e. badger me
17:10:35 <alaski> can do
17:10:55 * dansmith doubts alaski's abilities
17:11:27 <alaski> I think you all impressed upon me the need to be more aggressive, though it's against my natur
17:11:30 <alaski> e
17:11:38 <dansmith> yeah, but I have seen no change of behavior
17:11:41 <dansmith> you're as nice as ever
17:12:07 <alaski> heh, fair point. I'll see what I can do
17:12:24 * alaski cracks a whip
17:12:29 <mriedem> probably nicer
17:12:32 * dansmith quakes in his boots
17:12:44 <alaski> there's a review up for a simple migration command for cellsv2
17:12:46 <mriedem> 'they told me to be mean, so i probably did something wrong and need to be extra nice now!'
17:12:53 <dansmith> mriedem: lol
17:12:54 <alaski> lol
17:13:22 <alaski> we'll need that nova-manage cmd for grenade
17:13:40 <alaski> the only other series I can think of right now for N is the rpc switching from melwitt
17:13:50 <dansmith> I'm already +2 on the migration command IIRC
17:13:54 <alaski> yep
17:13:56 <dansmith> so crack that whip somewhere else
17:14:03 * mriedem watches his behind
17:14:15 <mriedem> is anything up yet for the list stuff?
17:14:31 <alaski> not yet, that's my next patch
17:14:32 <mriedem> there was quite a bit of talk about what to do with listing instances
17:14:33 <mriedem> ok
17:14:44 <alaski> that series was 8 patches long for a while, so I deferred
17:14:45 <mriedem> we also talked about restricting sort_keys for list, which i opened a bug for yesterday
17:15:08 <mriedem> but that could be done in parallel
17:15:28 <alaski> yeah
17:15:51 <alaski> the real value of that is if it's a small enough set of data that we could keep in in the api db
17:16:06 <alaski> then we don't need to query each cell, or elasticsearch, to get the set of instances
17:16:08 <melwitt> alaski: I was about to ask about that. the service version query stuff. it's already doing the version querying but I planned to incorporate the feedback from belliott and refactor the Transport creation
17:17:12 <alaski> melwitt: okay. I seem to recall agreeing with belliotts ideas
17:17:19 <dansmith> melwitt: because of the other requirements we have, querying the service version in the cell is just extra work, right
17:17:24 <dansmith> you're talking about for the rpc switching, right?
17:18:14 <melwitt> dansmith: what do you mean by extra work?
17:18:27 <melwitt> like an extra step? yes
17:18:55 <dansmith> melwitt: well, if we're going to require the cells to be upgraded first, then we'll always be okay to send the newest version known by the api stuff
17:19:02 <alaski> this gets to the idea of doing an api upgrade last right?
17:19:09 <melwitt> ohh. I see
17:19:15 <dansmith> the same reason we don't really ever pin the conductor version, because it always has to be newer anyway
17:19:16 <dansmith> alaski: yeah
17:19:31 <dansmith> I left this feedback on that review a long time ago, but maybe it wasn't super clear at that point
17:19:34 <alaski> so that's some documentation work we need to do
17:19:50 <alaski> where is the current upgrade procedure documented?
17:19:51 <dansmith> well, and testing to make sure it works
17:19:56 <alaski> yeah
17:20:06 <dansmith> alaski: not really sure we have a good place that covers it, TBH
17:20:23 <alaski> okay
17:20:24 <mriedem> we don't, that was another todo in the etherpad from the midcycle
17:20:35 <melwitt> it was probably just me. I didn't get the point that the upgrade order obviates the patch
17:20:40 <alaski> mriedem: for whom?
17:20:49 <mriedem> alaski: unspecified
17:20:56 <mriedem> mikal said we could open bugs against the docs team
17:21:11 <alaski> cool
17:21:38 <alaski> #action alaski to file a bug against the docs team on upgrade ordering with cellsv2, dependant on testing of that ordering
17:22:01 <dansmith> we really need to get testing of it done before we start prescribing,
17:22:14 <dansmith> and figure out how we're going to handle going from the current method to the new one
17:22:36 <dansmith> because until conductor is completely isolated from the api database, we can't really separate the api and the conductor I don't think
17:22:57 <dansmith> well, unless we're lucky right now and we use a voting test to make sure we don't migrate data away from where the api can see it until it's upgraded
17:23:01 <dansmith> like the aggregate stuff for example,
17:23:11 <dansmith> well, no that's manual
17:23:16 <dansmith> but the flavor thing we did in newton,
17:23:26 <dansmith> would break a mitaka api if you started running newton conductors with older apis
17:23:52 <dansmith> but maybe we get that in place for ocata early so we can make sure we don't break a newton api running with ocata conductor
17:23:58 <alaski> this sounds like it's getting into O territory
17:24:00 <dansmith> that may have even been my todo item
17:24:00 <alaski> yeah
17:24:06 <dansmith> or one of them
17:24:20 <dansmith> I tried a hack against grenade a month or so ago, but never got it working, for grenade reasons
17:24:28 <dansmith> and sdague refuses to help me on things, so...
17:24:55 <mriedem> don't get me started on that guy
17:25:02 <alaski> that definitely sounds like him
17:25:36 <alaski> well I think that's all on reviews right now
17:25:57 <alaski> but yeah, I'll hold off on the docs bug until we get testing sorted
17:26:07 <alaski> #topic Open Discussion
17:26:45 <alaski> does anyone have a topic?
17:26:53 <alaski> I do not have anything for here
17:27:21 <melwitt> so if we don't need the service version query, then I think all I have for rpc switching is to have the queries for mapping go in the compute rpcapi and refactor the Transport object stuff to be cached
17:27:52 <melwitt> and also switching needs to go in consoleauth rpcapi but IIRC that is intended to be removed
17:28:20 <alaski> I recall paul murray mentioning that
17:28:30 <melwitt> yeah, that's what I'm thinking of
17:29:42 <alaski> sounds good. that seems like a simplification of what's up now
17:29:56 <alaski> anything else?
17:30:39 <alaski> thanks everyone!
17:30:43 <alaski> #endmeeting