17:00:34 <alaski> #startmeeting nova_cells
17:00:35 <openstack> Meeting started Wed May  6 17:00:34 2015 UTC and is due to finish in 60 minutes.  The chair is alaski. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:38 <openstack> The meeting name has been set to 'nova_cells'
17:00:42 <bauzas> \o
17:00:47 <alaski> hello hello
17:00:48 <melwitt> o/
17:00:50 <dheeraj-gupta-4> o/
17:01:09 <alaski> #topic Cellsv1 testing
17:01:22 <vineetmenon> o/
17:01:22 <alaski> http://goo.gl/lZRucu
17:01:50 <alaski> a fix went in late yesterday for cellsv1
17:01:53 <dansmith> o/
17:02:05 <alaski> failures are low right now, but there's not much data yet
17:02:27 <alaski> there have been three failures, two of which were on stable branches
17:02:37 <bauzas> sounds nicer
17:03:01 <alaski> which does raise the question: can we vote on master only?  or should we backport to stable?
17:03:09 <alaski> well, probably not an or
17:03:10 <dansmith> I think we can vote only on master
17:03:26 <alaski> okay, good
17:03:46 <bauzas> alaski: you mean having the job set to voting for master only ?
17:03:52 <alaski> yes
17:04:21 <bauzas> mmm, AFAIK the job is set to vote or not, and then we call it for any project
17:04:45 <alaski> I know that jenkins wasn't happy recently, so I don't know how good the data we have is.  but we should watch it closely now
17:05:37 <alaski> bauzas: okay.  I guess we need to look into it to see what we can do
17:05:52 <bauzas> alaski: https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L652-L653
17:06:10 <bauzas> alaski: we can add a branch
17:06:28 <bauzas> alaski: so the answer to your question is yes
17:06:35 <alaski> okay
17:06:50 <bauzas> who actions that ?
17:07:16 <alaski> I will propose some backports for stable, but in the meantime we should separate failures by branch
17:07:31 <alaski> and see how close we are to being good on master
17:07:57 <alaski> bauzas: it's not needed yet, was just a question
17:08:28 <bauzas> build_name:"check-tempest-dsvm-cells" AND message:"Worker Balance" AND build_status:"FAILURE" AND build_branch:"master" gives us only 2 failures since your patch merged AFAICS
17:08:58 <bauzas> but sure we can leave it running for another round, sure
17:09:12 <alaski> it's been less than a day at this point
17:09:30 <bauzas> agreed
17:09:34 <alaski> #topic Specs
17:10:00 <alaski> the requestspec changes merged
17:10:18 <bauzas> yup
17:10:30 <bauzas> I'm working on the implem now
17:10:36 <alaski> so https://review.openstack.org/#/c/176078/ is next up for that series
17:10:51 <alaski> bauzas: great
17:11:09 <bauzas> alaski: should provide a WIP patch soon
17:11:18 <alaski> when that gets to a good point I'll start working on perisistence, if the spec is merged
17:11:36 <bauzas> alaski: https://review.openstack.org/#/c/76234 is a dependency tho
17:11:45 <alaski> I've completely changed the scope of https://review.openstack.org/#/c/141486/
17:11:54 <alaski> scheduler interactions with cells
17:12:22 <alaski> bauzas: ok
17:12:52 <alaski> while writing that last spec I found that we're missing a table to map hosts to cells, so I'll put something up for that
17:13:17 <bauzas> cool
17:13:59 <alaski> and I don't have a fleshed out spec for storing enough data to return an instance for a list/show
17:14:14 <alaski> so I need that as well
17:14:19 <dheeraj-gupta-4> alaski: Mapping hosts to cells seems counter-intuitive
17:14:29 <bauzas> dheeraj-gupta-4: why ?
17:14:47 <dheeraj-gupta-4> A compute node can be added to a child cell any-time
17:14:59 <dheeraj-gupta-4> API cell shouldn't know or care how/when that is done
17:15:33 <alaski> dheeraj-gupta-4: it needs to know where to send messages for it
17:15:43 <dheeraj-gupta-4> it only needs to know child cell
17:16:06 <alaski> right, but it needs to get that info from somewhere
17:16:07 <dheeraj-gupta-4> maybe the child cell should handle the internals
17:16:26 <dheeraj-gupta-4> but that's just over top of my head
17:16:30 <alaski> there are two cases here where we need to know how to route
17:16:39 <bauzas> dheeraj-gupta-4: how do you route calls ?
17:16:39 <alaski> the scheduler returns a host, which cell is it in?
17:16:40 <dheeraj-gupta-4> maybe the spec will answer those questions
17:16:53 <alaski> the host api needs to update/query a host, where is it?
17:17:22 <dheeraj-gupta-4> hmm... cellsv1 style naming maybe
17:17:31 <dheeraj-gupta-4> *shudders*
17:17:37 <alaski> yeah :)
17:18:06 <alaski> I think that for the most part a cell doesn't need to know it's a cell, or which cell it is
17:18:20 <alaski> that's a label the api cares about
17:18:26 <vineetmenon> dheeraj-gupta-4: any reservations against cell-host mapping?
17:18:29 <alaski> though that's muddled with scheduling slightly?
17:18:35 <alaski> woops, didn't mean a ? there
17:18:56 <dheeraj-gupta-4> vineetmenon: No it just seemed odd for a moment
17:19:37 <alaski> dheeraj-gupta-4: I understand the hesitation.  I'm open to alternatives that aren't named based.
17:19:57 <dheeraj-gupta-4> yes.... I see the motivation now
17:20:05 <dheeraj-gupta-4> wasn't clear when you first mentioned it
17:20:12 <alaski> okay
17:20:19 <bauzas> dheeraj-gupta-4: I think you need to forget cells v1 :)
17:20:26 <dheeraj-gupta-4> bauzas: :)
17:20:57 <bauzas> there should be no longer child and parent cells, just cells and api
17:21:06 <dheeraj-gupta-4> cool
17:21:20 <alaski> so outside of the specs I mentioned, and one for multiple rpc endpoints, I think that's about what's on our plate this cycle
17:21:41 <alaski> and also the scheduling stuff that's not really cell specific but affects us
17:22:20 <alaski> anything else on specs?
17:22:38 <alaski> #topic Open Discussion
17:22:43 <alaski> if so it can go here
17:22:55 <alaski> anyone have something to bring up?
17:23:21 <dheeraj-gupta-4> alaski: During Kilo closure one patch about talking to multiple DBs got held up
17:23:22 <bauzas> just one question, could we maybe ask again people if they are happy with moving this alternate time one hour before ?
17:23:54 <bauzas> on a personal note, that's just conflicting my w/l balance :)
17:23:55 <alaski> bauzas: the 2200 one?
17:23:57 <dheeraj-gupta-4> https://review.openstack.org/#/c/161906/
17:24:13 <bauzas> nah, I'm fine with this one, the 1700 one
17:24:21 <bauzas> this time
17:24:24 <alaski> dheeraj-gupta-4: oh, thanks for bring that up
17:24:36 <alaski> that will be necessary as well
17:24:52 <alaski> I'm not sure where it falls spec wise at this point
17:25:07 <dansmith> moving the 1700UTC one an hour earlier will have conflicts for me
17:25:14 <alaski> dheeraj-gupta-4: it might be something we can just open a bp for
17:25:19 <dheeraj-gupta-4> alaski: okay
17:25:20 <bauzas> dansmith: no worries, just asking the question :)
17:25:44 <bauzas> alaski: need resubmitting the spec ?
17:25:57 <bauzas> https://blueprints.launchpad.net/openstack/?searchtext=cells-v2-mapping gives 404 ;(
17:26:02 <alaski> bauzas: the spec was close as implemented afaik
17:26:22 <bauzas> alaski: so it was partial because it misses that change, right ?
17:26:27 <bauzas> missed even
17:26:28 <alaski> bauzas: I think we should go for a bp, it's not a big change
17:27:30 <bauzas> alaski: agreed
17:27:42 <alaski> also, sounds like we should keep this time for the meeting.  but if it interferes you can leave me comments before the meeting and follow up with the logs
17:28:27 <vineetmenon> alaski: so the alternate timing aren't applicable anymore?
17:28:33 <bauzas> alaski: ack
17:28:50 <alaski> vineetmenon: it still is.  1700 and 2100
17:28:59 <bauzas> it's just all about family time for dinner :)
17:29:03 <bauzas> but that's fine
17:29:07 <dheeraj-gupta-4> bauzas: 1700 UTC or 1600 UTC both work for me
17:29:09 <bauzas> I'll handle that
17:29:30 <bauzas> dheeraj-gupta-4: dansmith has conflicts for 1600, let's stick with the current time
17:29:31 <alaski> bauzas: totally understood.  hard to get everyone with so many timezones
17:29:40 <vineetmenon> alaski: ack
17:29:49 <dheeraj-gupta-4> bauzas: ok
17:30:46 <alaski> bauzas: lets revisit later, perhaps at the next dst shift
17:31:00 <alaski> anything else for today?
17:31:02 <bauzas> alaski: again, no worries
17:32:00 <alaski> bauzas: okay
17:32:08 <bauzas> crickets ?
17:32:12 <alaski> yep
17:32:16 <alaski> thanks everyone!
17:32:20 <alaski> #endmeeting