17:00:19 <alaski> #startmeeting nova_cells
17:00:20 <openstack> Meeting started Wed May 11 17:00:19 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:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:23 <openstack> The meeting name has been set to 'nova_cells'
17:00:32 <melwitt> o/
17:00:42 <belmoreira> o/
17:00:50 <doffm> o/
17:00:52 <alaski> bauzas: ping
17:00:59 <alaski> cool, let's get going
17:01:06 <alaski> #topic Testing
17:01:15 <mriedem> o/
17:01:20 <alaski> no breaks on v1 that I can see
17:01:34 <alaski> and the cell job caught something dansmith tried to sneak by which would break it
17:01:40 <alaski> so huzzah
17:01:44 <mriedem> he's so sneaky
17:01:45 <melwitt> nice
17:01:57 <dansmith> heh
17:02:20 <alaski> I don't see ctrath so we'll skip talking about v2 testing
17:02:30 * bauzas lurks
17:02:30 <mriedem> ccarmack you mean
17:02:34 <alaski> woops
17:02:37 <mriedem> but yeah
17:02:43 <alaski> yeah
17:02:49 <alaski> #topic Open Reviews
17:02:55 <alaski> https://etherpad.openstack.org/p/newton-nova-priorities-tracking
17:03:00 <alaski> plenty of things to look at
17:03:22 <alaski> I think most of us here have series up, we should take a moment to look at someone elses
17:03:44 <alaski> #topic Open Discussion
17:03:47 <mriedem> should probably add the keypair stuff to that
17:03:54 <alaski> mriedem: yes
17:03:57 <bauzas> Yup please
17:04:29 <alaski> #action alaski add keypair patches to review priorities if someone doesn't beat me to it
17:04:44 <mriedem> you slackers are all supposed to be reivewing api-ref stuff today too
17:04:46 <mriedem> shame!
17:04:48 <dansmith> I have to add a fake test for mriedem first
17:04:55 <alaski> ok
17:05:07 <dansmith> the bottom patch is already +W
17:05:16 <dansmith> but give me a bit after this meeting and I'll have it ready
17:05:23 <alaski> I don't have any items on the agenda for open discussion, but I do have some questions for folks
17:05:46 <alaski> dansmith: you and jay had a pow wow on migrating stuff to the cell db
17:05:53 <alaski> can you share the gist of the plan?
17:06:09 <dansmith> well,
17:06:12 <bauzas> Pow wow ?
17:06:16 <alaski> by stuff I mean inventory and resource type things
17:06:22 <dansmith> he pasted some of it into the channel, I just came up with a few steps,
17:06:31 <alaski> bauzas: they sat around a campfire and discussed, metaphorically
17:06:32 <dansmith> but the thing I had that was more concerning is that .. if we move inventory to the api,
17:06:43 <dansmith> then we've got the cells making an upcall to the api db to write that information,
17:06:44 <dansmith> which I don't like
17:06:57 <dansmith> longer term we'll be making a REST call to the api to manage those things, which is better
17:07:03 <alaski> yea
17:07:24 <bauzas> I agree it's a sad thing
17:07:28 <alaski> but that longer term is actually getting approachable right?
17:07:34 <dansmith> yes
17:07:35 <doffm> The upcall is short lived. hopefully.
17:07:43 <dansmith> so we'll have to do it in the short term of course
17:07:50 <dansmith> I just want to make sure we don't let it go longer than we need
17:08:08 <alaski> okay
17:08:25 <doffm> dansmith: What about instance groups? I presume we just move all of those up in to the API as well?
17:08:32 <bauzas> Because it's the compute manager save thing ?
17:08:34 <doffm> I don't think there is an upcall there.
17:08:42 <dansmith> doffm: actually I want to move those into the fire, but...
17:08:53 <bauzas> I mean the RT
17:08:57 <alaski> dansmith: that basically ties scheduler work into cellsv2 a bit, so I may divert my energy in that direction to help out if needed
17:09:54 <alaski> doffm: my understanding was that anything that's purely for scheduling would move to the api db
17:10:07 <alaski> which is actually a lot of what Nova keeps in the db
17:10:11 <dansmith> alaski: yeah, we're definitely getting into the intersection area at this point
17:10:40 <bauzas> that's because the compute nodes need to update somehow the DB for the scheduler, right
17:10:49 <bauzas> so, if we have an scheduler DB, then...
17:10:58 <doffm> There was some discussion from johnthetubaguy about leaving some of the instance groups in the cell. (InstanceGroupHostMappingThing). But i'll presume its all going to api.
17:11:02 <doffm> For now.
17:11:03 <bauzas> without really needing yet a REST API call
17:11:09 <bauzas> so, my thoughts are
17:11:17 <bauzas> 1/ do an upcall for Newton
17:11:21 <alaski> doffm: +1 for presuming
17:11:35 <bauzas> 2/ discuss on any need for a sched DB in Ocata
17:11:44 <bauzas> 3/ implement if so, or wait for the REST call
17:12:02 <dansmith> bauzas: no, it's really 1. do the upcall now, 2. get a REST call very soon, 3. the rest
17:12:14 <alaski> 4/ think of a new db to split out next
17:12:26 <dansmith> the split and db stuff can come later, we should have the rest call ASAP so that we're decoupled regardless
17:12:33 <alaski> +1
17:12:33 <bauzas> dansmith: well, it needs a placement client first, right? plus the fact we need to have old n-1 computes having that
17:12:51 <bauzas> dansmith: which means the upcall is N+O right?
17:12:52 <dansmith> it needs some isolation
17:12:59 <alaski> part of the REST work would be a client
17:13:12 <dansmith> I think we might get the REST bit done in newton, which would mean we could split or do other things in O
17:13:14 <bauzas> I assume the compute services using that placement client if so
17:13:14 <alaski> and computes don't call the scheduler
17:13:27 <alaski> nvm, you may be talking about updates
17:13:41 <bauzas> they actually call "a scheduler client"
17:13:50 <bauzas> so the problem is really with upgrades
17:14:14 <bauzas> because we already have that facade
17:15:21 <alaski> if we get a new API and computes using a new client in N, the scheduler keeps supporting current mechanisms in N, then in O we can drop all of that right?
17:15:37 <dansmith> yar
17:15:59 <bauzas> alaski: yeah, but that means 1.5 milestones for both implementing the REST API and the client :)
17:16:11 <bauzas> (and approving the spec)
17:16:15 <mriedem> bauzas: you better get to work then
17:16:40 <mriedem> it's definitely a stretch
17:16:49 <bauzas> mriedem: heh, that's the exact reason why I threw off my api-ref duty
17:17:04 <bauzas> in order to make my non-prio BPs done first before helping
17:17:18 <alaski> bauzas: you're more up to date on scheduling plans, are there dependencies that have to happen before working on the REST stuff?
17:17:28 <mriedem> we have to get this spec approved for one https://review.openstack.org/#/c/300176/
17:17:29 <alaski> or anyone who knows
17:17:38 <mriedem> i haven't reviewed the updates since monday
17:17:43 <mriedem> but i'm told jay and chris are on the same page
17:17:56 <bauzas> alaski: the generic-resource-pools spec is kinda not needing deps
17:18:02 <dansmith> shall we move on?
17:18:03 <alaski> okay
17:18:18 <dansmith> I'm hangry and looking for this to move along :)
17:18:24 <alaski> alright
17:18:41 <alaski> from my end I'm finishing up docs for my policy changes, and then I'm done with that except for review feedback
17:18:50 <bauzas> alaski: apart the tables move to the API DB and the policy stuff you volunteered
17:19:01 <dansmith> alaski: are you working on quota migration?
17:19:06 <alaski> doffm: are you pretty set on the direction of your specs or are there things to discuss here?
17:19:16 <alaski> dansmith: I am not
17:19:16 <doffm> alaski: Pretty set.
17:19:21 <dansmith> alaski: why for/
17:19:26 <alaski> dansmith: does that need someone?
17:19:37 <dansmith> alaski: it doesn't need someone, it needs _you_
17:19:43 <alaski> heh
17:20:03 <melwitt> was that supposed to be a question mark again
17:20:13 <dansmith> melwitt: yeah
17:20:30 <alaski> I'm still pushing on reworking scheduling for cells, but I'll look at quotas as well
17:20:36 <doffm> Actually.... I'll ask about the quota spec.
17:20:52 <doffm> mriedem and alaski gave me some feedback on how quotas should be migrated.
17:21:04 <doffm> By putting the migration code in the quota db driver.
17:21:26 <doffm> Is that how we want to do things this cycle? Quick and dirty. :)
17:21:30 <doffm> Fix things in this code later.
17:21:36 <mriedem> yes
17:21:45 <alaski> yeah, we can't wait on fixing quotas
17:21:54 <doffm> Ok, will update spec with that feedback this afternoon.
17:22:06 <mriedem> also, fyi, i'm overly full of pizza right now
17:22:11 <doffm> Me too.
17:22:14 <doffm> And mountain dew.
17:22:18 <mriedem> and oreos
17:22:21 <bauzas> oh man
17:22:53 <alaski> you're going to make dansmith jealous
17:23:01 <dansmith> so .. hungry
17:23:12 <mriedem> that's the idea
17:23:12 <alaski> I don't have anything else though, so if nobody has a topic
17:23:14 <bauzas> fortunately, I already ate
17:23:28 <mriedem> i've heard that snickers really satisfies
17:23:28 <alaski> me too
17:23:37 <alaski> alright, thanks everyone
17:23:39 <alaski> #endmeeting