17:00:23 <alaski> #startmeeting nova_cells
17:00:24 <openstack> Meeting started Wed Feb 25 17:00:23 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:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:27 <openstack> The meeting name has been set to 'nova_cells'
17:00:32 <alaski> Anyone around today?
17:00:35 <gilliard> Helloo
17:00:35 <dheeraj-gupta-4> o/
17:00:46 <dansmith> o/
17:01:07 <alaski> excellent
17:01:16 <melwitt> o/
17:01:24 <alaski> short agenda today so hopefully we can move through it
17:01:43 <alaski> #topic separate database configs
17:02:15 <alaski> Primarily I wanted to get some thoughts on having two config options
17:02:38 <alaski> two connection strings I guess I should say
17:03:48 <alaski> I would like to require that a connection string is explicitly for a particular db type
17:04:12 <gilliard> What do you mean 'type'?
17:04:18 <alaski> api vs cell
17:04:54 <alaski> I'm guessing that people would generally be in favor of multiple configs, but wanted to see if there was a reason not to do it
17:05:59 <dansmith> alaski: what's the other option?
17:06:23 <dansmith> oh, wait
17:06:27 <melwitt> I must admit I don't have a clear picture of what that looks like (not super familiar with cells configs).  in v1 I know about cell_type but didn't notice the db connection strings
17:06:30 <alaski> that the db type is determined by the service
17:06:36 <dheeraj-gupta-4> alaski: Separate configs with each service look "easier"
17:06:50 <dansmith> so, the anything that the API does in a cell database would get the connection string from the api database, right?
17:07:00 <alaski> dansmith: right
17:07:42 <alaski> dheeraj-gupta-4: I think it's easier to just keep using 'connection_url' or whatever it is right now, but also more confusing
17:08:16 <alaski> melwitt: cells v1 doesn't make a distinction because the db is the same in the parent and child
17:08:23 <gilliard> Where would the services in the cell get the conn string from?
17:08:45 <alaski> gilliard: CONF.db.connection_url
17:09:36 <alaski> it boils down to, should CONF.db.connection_url always point at a cell db and we make a CONF.db.api_connection_url (ignore names), or should CONF.db.connection_url work for either
17:10:22 <dansmith> the thing I like about using the same thing,
17:10:37 <dansmith> is that it reinforces that we don't get cell connection info from anywhere other than the API database
17:10:38 <dansmith> however,
17:11:08 <dansmith> it is probably very confusing to people that we access one database (and schema) in one place, and a different schema in other places in the code, both through the same URL
17:11:19 <dansmith> and you can only know by having supreme understanding of the whole thing
17:11:35 <dansmith> so probably two are required just for human reasons,
17:11:39 <alaski> yeah, that's why I prefer the first option
17:11:53 <dansmith> and we should have an assertion that both can't be set
17:11:59 <gilliard> ^^ yes
17:12:19 <alaski> yep
17:13:40 <alaski> the follow up is, should nova-manage work for cell dbs from the api level?
17:13:55 <alaski> i.e. should it take an argument to pull cell db info from the db
17:14:00 <dheeraj-gupta-4> alaski: Can the connection_url option be kept as one but underlying session/engine be split into api_session/session and api_engine/engine
17:14:39 <dansmith> alaski: I'm thinking maybe nova-manage has to have a --cellid=$uuid to work against the cell db, and then it looks things up in the API database, and operates on $cell
17:15:15 * bauzas waves very late
17:15:19 <mdorman> +1 on nova-manage working (somehow) to operate on individual cells.  that seems pretty useful from an operational perspective.
17:15:20 <bauzas> damn TB notices
17:15:36 <melwitt> dansmith: that makes sense to me
17:15:41 <alaski> dheeraj-gupta-4: that could work, but then it's confusing because it's split based on which service is running
17:16:05 <alaski> dansmith: that's what I was thinking too, just wanted to ensure no one had an aversion to managing dbs that way
17:16:40 <bauzas> I'm running late, but I'm in favor of 2 connection strings as config opts
17:17:02 <alaski> cool
17:17:10 <bauzas> that's something we discussed in the spec btw. IIRC :)
17:17:29 <alaski> yep, but then it was easier to get started by piggybacking on the current config
17:17:34 <bauzas> sure
17:17:49 <alaski> just wanted a gut check before proceeding with it
17:17:52 <bauzas> I just wanted to say that I'm still agreeing with myself :)
17:18:05 <alaski> :)
17:18:24 <alaski> sounds like we have general agreement then, I'll start working on the split
17:18:28 <bauzas> cool
17:18:33 <alaski> #topic Open Discussion
17:18:38 <bauzas> I had very few review bandwidth this week
17:18:56 <bauzas> FPF ?
17:19:03 <bauzas> how can it impact the cells work ?
17:19:22 <alaski> we'd have to request an exception for anything not merged
17:19:23 <bauzas> that's something we're hitting on the scheduler side
17:19:42 <bauzas> alaski: ok, I guess we'll maybe have to find the good ones
17:19:47 <alaski> which is why I was about to post...
17:19:49 <alaski> https://review.openstack.org/#/c/150381/
17:19:51 <bauzas> because FPF is March 5th
17:19:57 <bauzas> ie. one week left
17:20:06 <alaski> https://review.openstack.org/#/c/157156/7
17:20:14 <alaski> those are two review streams up right now
17:20:35 <bauzas> yeah, we can probably put them in the etherpad, are they ?
17:20:50 <alaski> bauzas: I'm not sure if the full chain is, but I put some of them at elast
17:20:53 <alaski> *least
17:21:09 <bauzas> cool
17:21:16 <bauzas> at least, it's FPF
17:21:21 <bauzas> so we're ok
17:21:25 <bauzas> with these I mean
17:21:32 <bauzas> I'm more concerned about what's still missing
17:21:46 <bauzas> FF is end of March IIRC
17:21:50 <alaski> this is a good portion of it
17:21:57 <bauzas> then that's cool :)
17:21:57 <alaski> there's the config piece
17:22:15 <alaski> and tieing the db migrations the the work from dheeraj-gupta-4
17:22:28 <alaski> like, just a sample call being tested or something
17:22:59 <alaski> and I would like to do some work with the RPC side of things, but I'm not sure if there will be time
17:23:25 <bauzas> erm, touching the RPC interfaces by end of K3 still pretty optimistic :)
17:23:32 <dheeraj-gupta-4> alaski: Are we also targetting patching nova-manage to add cells using cellsv2?
17:23:36 <bauzas> *seems
17:24:01 <alaski> bauzas: yeah, not touch them really, more of just a framework to make RPC calls to different endpoints
17:24:13 <bauzas> dheeraj-gupta-4: sounds like it's part of the patch series that alaski mentioned ?
17:24:29 <alaski> dheeraj-gupta-4: yeah, that's up for review already
17:24:33 <bauzas> alaski: still big IMHO :D
17:24:45 <dheeraj-gupta-4> bauzas: aah...didn't realize that..sorry
17:24:56 <bauzas> dheeraj-gupta-4: try the new Gerrit UI
17:24:58 <alaski> bauzas: definitely, hence me not being sure about getting it done
17:25:24 <alaski> I got tied up with stuff a bit ago which delayed my working on cells mostly fulltime
17:25:49 <bauzas> anyway, Liberty should open very soon after FF, so that's really about what we want for Kilo :)
17:26:17 <alaski> yep
17:26:39 <alaski> as soon as FPF hits I'm going to be working on specs/etherpads/etc.. so we can go into Liberty with a good plan
17:26:41 <dansmith> alaski: one of these days we're going to stop letting you use that excuse :)
17:27:06 <alaski> dansmith: :) ... :(
17:27:11 <dansmith> heh
17:27:22 <melwitt> on testing, I have a patch up that addresses the FlavorNotFound errors in the tempest cells job, https://review.openstack.org/#/c/158933/ in local testing it got the failure count down to 45. a question I have is, is there any way to see what the effects of removing items from our whitelist are on the job? since that updates project-config, is there a way to see how it looks on the CI cells job
17:28:12 <alaski> melwitt: not as far as I know
17:28:16 <bauzas> melwitt: there is no magic
17:28:34 <melwitt> okay, just wanted to make sure I didn't miss some magic
17:28:35 <bauzas> melwitt: we need to merge the change before seeing the impact on Nova
17:28:46 <melwitt> bauzas: got it
17:28:49 <bauzas> melwitt: or we can copy the logic to the experimental pipeline
17:29:00 <bauzas> melwitt: and do the stuff in there for testing the gate
17:29:31 <bauzas> melwitt: that's something I was working on, not really huge, but after discussed with some folks, I just moved the test to the check ppl
17:30:08 <bauzas> btw. that comes up with an action from me
17:30:21 <bauzas> https://review.openstack.org/157185
17:30:33 <melwitt> bauzas: forgive my lack of knowledge, but wouldn't moving it to experimental make it not run all the time as non-voting check?
17:30:37 <bauzas> so there is a regression, because someone dumb enough introduced it
17:30:42 <alaski> melwitt: if you're confident that the tests will pass based on local testing just propose removing some exclusions
17:31:04 <bauzas> melwitt: yeah, it needs to be checked by hand, ie. check experimental
17:31:33 <alaski> melwitt: once the job is voting we'll need to be more careful, but for now I think we can work off of local testing
17:31:37 <bauzas> (just to be clear, I'm the guy who introduced the regression...)
17:31:58 <bauzas> alaski: agreed
17:32:35 <melwitt> okay. this is just the kind of thing I'd feel a lot better if I could verify it first, it'd be a big "oops :(" if somehow it doesn't do the same as it's doing locally for me
17:32:41 <alaski> bauzas: is that patch just waiting on testing now?
17:33:35 <alaski> melwitt: agreed.  but it won't break anything currently, so without a better way...
17:33:51 <melwitt> and it's not that I want to remove whitelist items so badly, but just assumed that's the way forward as I whittle away at the failures
17:34:10 <bauzas> alaski: the patch needs some cleanup, and also there are some changes I want to merge first for the cells API
17:34:18 <melwitt> alaski: cool, I understand
17:34:25 <alaski> melwitt: definitely, it helps with future regressions too once we can get to voting
17:34:38 <bauzas> alaski: ie. all the things coming in the bp/detach-service patch series
17:34:49 <melwitt> okay, thanks for the guidance alaski, bauzas
17:34:52 <alaski> bauzas: gotcha
17:35:22 <bauzas> but as it's FPF soon, my priorities go to another BP which is still WIP, tbh :)
17:35:34 <bauzas> ie. I'm rushing on Gerrit
17:35:55 <alaski> bauzas: want me to take over on this one?
17:36:38 <bauzas> alaski: eh, you can co-author it, sure, but I think it still needs first the improvements I mentioned :)
17:37:06 <bauzas> alaski: by saying I'm holding it off, I'm speaking about days, not weeks ;)
17:37:07 <alaski> bauzas: sure, I can tack it onto your other series and work on some tests
17:37:28 <bauzas> alaski: sure that would be nice
17:37:49 <bauzas> alaski: again, we all have priorities so that's just matter of finding time :)
17:38:10 <dheeraj-gupta-4> bauzas, alaski: Sorry about pulling it back. But from my earlier comment about patching nova-manage, what I meant was are we targetting something like "nova-manage cellsv2 cell create name --foo" for kilo. I don't see a patch for that as yet.
17:38:14 <alaski> bauzas: yep.  it's not my first priority either, but I think I can write some tests for it
17:38:32 <alaski> dheeraj-gupta-4: oh.  no not yet
17:38:53 <dheeraj-gupta-4> alaski: ok
17:39:14 <bauzas> dheeraj-gupta-4: my bad
17:39:20 <alaski> I started getting into that in a migration spec that didn't make it into K
17:40:20 <alaski> anything else to discuss here?
17:40:38 <gilliard> The reviews on the etherpad are:
17:40:51 <gilliard> https://review.openstack.org/#/c/157156/
17:40:52 <gilliard> https://review.openstack.org/#/c/157423/
17:40:54 <gilliard> https://review.openstack.org/#/c/157426/
17:41:23 <gilliard> I'll spend some time on those & following dependency chains but if there's anything else please feel free to add me directly.
17:41:46 <alaski> there's also https://review.openstack.org/#/c/150381/
17:41:54 * gilliard adds to etherpad
17:42:15 <alaski> oh, woops
17:42:19 <gilliard> heh
17:42:42 <alaski> and thanks for reviewing
17:43:20 <alaski> looks like we can get out early today
17:43:27 <alaski> thanks everyone!
17:43:32 <gilliard> splendid
17:43:36 <alaski> #endmeeting