17:00:32 <alaski> #startmeeting nova_cells
17:00:33 <openstack> Meeting started Wed Mar 16 17:00:32 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:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:37 <openstack> The meeting name has been set to 'nova_cells'
17:00:39 <mriedem> o/!
17:00:41 <doffm> o/
17:00:42 <alaski> bauzas: ping
17:00:44 <melwitt> o/
17:00:55 <mriedem> bauzas is at a bday party for the mrs
17:01:01 <alaski> ahh, okay
17:01:06 <mriedem> or so he says
17:01:12 <alaski> #topic Cells testing
17:01:27 <alaski> everything seems quiet
17:01:44 <melwitt> agreed
17:01:58 <alaski> traditionally this topic has been about v1 testing but I'd like to expand it to include v2 testing as well, beyond unit tests I mean
17:02:04 <alaski> melwitt: excellent
17:02:23 <alaski> mainly I'd like to start thinking about grenade and upgrade testing in this portion of the meeting
17:03:01 <alaski> since melwitts nova-manage command merged in M we can use that for grenade testing once the branches switch
17:03:31 <alaski> but until that happens there's not much we can do
17:04:00 <alaski> but if anyone has ideas on what/how to test bring them forward
17:04:19 <mriedem> well,
17:04:36 <mriedem> nvm
17:04:41 <doffm> At some point we will need a multi cell test, but we arn't there yet.
17:04:48 <alaski> doffm: agreed
17:05:07 <mriedem> i'm not sure how the nova-manage command fits into grenade really
17:05:21 <mriedem> i.e. do you populate some stuff in mitaka and then run the command in newton?
17:05:24 <alaski> I did not do a good job updating the agenda so we'll skip the next planned topic "Open reviews"
17:05:28 <alaski> mriedem: yes
17:05:40 <mriedem> alaski: then we didn't really need the command to land in mitaka right?
17:05:53 <alaski> but I believe grenade only has access to it if it lands in current-1
17:06:03 <alaski> grenade only updates computes I think
17:06:18 <mriedem> so you run the command in mitaka side of grenade too?
17:06:30 <mriedem> there are different ways to grenade, there is the all upgrade, and the partial upgrade
17:06:36 <alaski> no, the command just runs on N
17:06:40 <mriedem> partial upgrades everything but n-cpu
17:06:56 <mriedem> gate-grenade-dsvm is full upgrade of everything
17:07:11 <mriedem> what used to be the n-cpu job was upgrade all but n-cpu, that's now the multinode grenade job
17:07:21 <alaski> okay, my details are off then. but I know I've hit the issue in the past where grenade couldn't run a nova-manage thing from the current branch
17:07:32 <alaski> maybe it's fixed
17:08:40 <alaski> oh, maybe it's that devstack runs the same for both? and errors if the command isn't in current-1
17:09:04 <mriedem> yes,
17:09:04 <mriedem> well,
17:09:12 <mriedem> it'll be devstack n-1 for old, then devstack n
17:09:26 <mriedem> so if you need to run a thing in n-1, it has to exist
17:09:27 <mriedem> :)
17:10:12 <alaski> heh. either way the thing merged so we're good :)
17:10:22 <mriedem> right, plus it doesn't sound like you need the cli there anyway
17:10:58 <mriedem> were there any data migrations that needed testing?
17:11:04 <mriedem> *any other
17:11:11 <doffm> We might need to add cell0 commands that didn't make it. But... as mriedem described we should be ok running them just on 'n'
17:11:19 <alaski> right. though we could test mapping cells then upgrading, though it's not realistic as noone should be mapping cells yet
17:11:54 <alaski> mriedem: just the cell0 one from doffm
17:12:05 <mriedem> i'd think at some point we use the multinode job where cell0 is one node and the other is not
17:12:09 <mriedem> but,
17:12:13 <mriedem> then do we require a 3 node job/
17:12:14 <mriedem> ?
17:12:19 <mriedem> like for live migration
17:12:29 <mriedem> cell0 but 2 nodes for actually migrating things
17:12:32 <alaski> you could coexist the api with a cell
17:12:34 <mriedem> infra is going to looove that
17:12:44 <mriedem> but still,
17:12:49 <mriedem> 2 compute cells, right?
17:12:51 <mriedem> +cell0
17:12:58 <doffm> Yep.
17:13:02 <mriedem> so 3 nodes
17:13:10 <mriedem> 3 hosts i should say
17:13:15 <alaski> to do it right, yeah
17:13:17 <doffm> Probably best theat way.
17:13:19 <mriedem> i'll let alaski break that to sdague
17:13:33 <mriedem> can you run cell0 on one of those?
17:13:38 <doffm> Yes.
17:13:39 <alaski> heh, good things there's plenty of beer in Austin
17:13:40 <mriedem> ok
17:13:46 <alaski> cell0 is just a db
17:13:57 <mriedem> true, so yeah, nvm
17:14:09 <mriedem> i always think of cell0 as another service
17:14:23 <doffm> Its not really. Its a paper tiger of a cell.
17:14:49 <mriedem> say that to cell0's face
17:15:01 <alaski> doffm: where were you when we were naming this thing? :)
17:15:09 <doffm> :)
17:15:12 <mriedem> again,
17:15:15 <mriedem> why not jailcell?
17:15:40 <alaski> that would have worked, I don't remember it being proposed
17:15:46 <alaski> graveyard was the other contender I recall
17:15:51 <mriedem> geez
17:15:59 <mriedem> void
17:16:00 <mriedem> null
17:16:02 <doffm> Thats macarbre.
17:16:05 <melwitt> the only other migration we added recently was flavor table. the active migration part isn't there yet
17:16:26 <alaski> mriedem: null was ruled out for being overloaded
17:16:37 <alaski> doffm: that's why we didn't go with it
17:16:56 <alaski> melwitt: yeah, we need to push on sdagues flavor API thing first
17:17:13 <mriedem> and jaypipes threw a wrench in the mix for that spec
17:17:24 <alaski> this segues nicely into the next topic
17:17:29 <alaski> #topic Open Discussion
17:17:33 <alaski> mriedem: what now?
17:17:46 <mriedem> https://review.openstack.org/#/c/265282/
17:17:52 <mriedem> jay went all resource provider on it's ass
17:18:01 <doffm> Ha. Thats a pretty big wrench.
17:18:31 <doffm> "all of this is useless! bwahaha"
17:18:37 <alaski> hmm, I agree with him on that
17:19:02 <alaski> I think it's just a representation issue though, so may not be too bad
17:19:04 <jaypipes> sorry.
17:19:33 <mriedem> so,
17:19:46 <mriedem> if representing the flavor depends on the capabilities stuff
17:19:48 <doffm> jaypipes: You arn't neccessarily wrong, but it predicates the flavor migration on an api change.
17:19:54 <mriedem> and the cells flavor migration depends on the flavor spec,
17:20:11 <mriedem> i don't think we can block like that right now
17:20:12 <jaypipes> doffm: I don't understand what you mean by that.
17:20:38 <alaski> mriedem: ignoring the capabilities stuff, I think we can move forward on what he suggested
17:21:00 <alaski> and then microversion in the capabilities later. I need to look closer at it
17:22:03 <mriedem> well,
17:22:10 <mriedem> we're probably going to need a design session o nthis
17:22:13 <doffm> jaypipes: A microversion change. The server representation is changing just to list resources and removing flavor.
17:22:35 <alaski> mriedem: +1
17:23:37 <jaypipes> doffm: oh, yes, no disagreement.
17:23:52 <alaski> for now let's all go loudly agree/disagree with jaypipes on the spec
17:24:01 <mriedem> i punted :)
17:24:06 <mriedem> like a true politician
17:24:07 <alaski> or that
17:24:16 <jaypipes> alaski: sorry to throw the wrench in the mix :(
17:24:18 <mriedem> "let's wait until after the midterms"
17:24:38 <mriedem> alaski: you had a series of changes that was looking good but hit FF
17:24:45 <mriedem> i don't think those had blockers, just ran out of time
17:24:57 <mriedem> we could queue those up early for newton, would have to re-propose the spec/blueprint
17:25:14 <alaski> jaypipes: it's cool. I think we might need to partway follow what you suggested or we'll be blocked for a cycle.
17:25:16 <mriedem> the build request stuff i think
17:25:27 <alaski> right
17:25:42 <alaski> I will tidy all of that back up as soon as N opens
17:25:44 <jaypipes> alaski: I will have the capabilities proposal written up by the summit.
17:26:05 <jaypipes> which reminds me, I should probably book a flight and find a cheap hotel in austin..
17:26:18 <alaski> me too...
17:26:20 <doffm> Good luck with cheap.
17:26:23 <mriedem> i thought mirantis all stayed at the same fancy place?
17:26:46 <jaypipes> alaski: well, *you* get yours paid for so you don't need to worry about the hotel ;)
17:26:49 <melwitt> I'm planning to write a spec for the message queue switching and get my patch ready for review for N
17:27:10 <jaypipes> mriedem: I'm paying my own way in order to get an additional engineer to the summit.
17:27:16 <alaski> jaypipes: ahh, didn't realize you were going dutch
17:27:24 <jaypipes> ya
17:27:31 <doffm> melwitt: Sounds good. I guess I was wondering if you were going to get the spec up for that.
17:27:32 <mriedem> jules doesn't count as an engineer right? :)
17:27:40 <jaypipes> mriedem: no, she isn't goin.
17:27:52 <alaski> melwitt: great.
17:28:12 <melwitt> doffm: yeah, my bad on that. I had meant to do it earlier than now
17:28:24 <doffm> I have 3 specs up for DB api migration. I'm still working on a 4th and FINAL one.
17:28:39 <doffm> https://review.openstack.org/#/c/291382/
17:28:44 <alaski> so let me ask a question of the room on specs, how would you all like to be notified of new ones going up?
17:29:01 <alaski> advertise in this meeting, add each other to reviews, ...?
17:29:17 <doffm> I was thinking of putting them in the 'work to be done' document.
17:29:28 <doffm> https://etherpad.openstack.org/p/cellsV2-remaining-work-items
17:29:36 <doffm> But another etherpad / in here would be fine by me.
17:29:46 <melwitt> I was thinking maybe the priorities etherpad in the cells section?
17:29:47 <mriedem> as long as it's clear on the order somewhere, i'm happy
17:30:00 <doffm> melwitt: That makes sense.
17:30:16 <xgerman> o/
17:30:18 <alaski> cool, let's use the priority etherpad then
17:30:31 <alaski> potential future PTL mriedem, any idea when a new one of those might go up?
17:30:52 <mriedem> alaski: i'll talk to john, i don't see why we couldn't start creating one now
17:31:06 <alaski> cool
17:31:17 <alaski> I guess technically we don't decide priorities until Summit, but...
17:31:30 <melwitt> I feel like I want to add the https://etherpad.openstack.org/p/cellsV2-remaining-work-items to the cells section too. I didn't know about it until now
17:31:38 <mriedem> alaski: i think cellsv2 is a given
17:31:47 <alaski> melwitt: +1, I mean I knew but forgot
17:31:47 <mriedem> melwitt: +1
17:32:55 <melwitt> done
17:33:24 <alaski> doffm: do you feel like db migrations are going to fill the cycle for you?
17:33:50 <doffm> They would If I did all of them. I'm hoping to get some help around here.
17:33:58 <doffm> But yes, they ar at least one full person.
17:34:01 <alaski> melwitt: do you feel that message queue switching is all you might get to this cycle?
17:34:08 <alaski> doffm: okay
17:34:20 <melwitt> alaski: no, I've got bandwidth for more work actually
17:34:32 <alaski> I'd like to get a sense of if plates are full or we need to think ahead to what else could be done
17:34:37 <alaski> melwitt: awesome
17:35:54 <alaski> I haven't heard from belmeiora or vineet recently to know if CERN will have much involvement this cycle
17:36:04 <melwitt> doffm: did you get anywhere with the oslo.messaging "assemble transport url from ConfigOpts" by chance?
17:36:32 <doffm> melwitt: I haven't started. If you want to try then... go ahead. Otherwise I will try and get around to it soon.
17:36:48 <melwitt> doffm: no, was just curious
17:37:00 <doffm> Implementation wise i'm working on this spec. https://review.openstack.org/#/c/288084/
17:37:19 <doffm> Its the aggregate db move. I want to get it done early beacuse the resource provider cells work will depend on it.
17:37:49 <alaski> nice
17:38:05 <mriedem> fyi https://etherpad.openstack.org/p/newton-nova-priorities-tracking
17:38:13 <dansmith> the flavor move is still a thing we need right?
17:38:18 <alaski> yes
17:38:19 <mriedem> dansmith: yeah
17:38:22 <mriedem> but it's held up
17:38:28 <dansmith> on?
17:38:33 <mriedem> https://review.openstack.org/#/c/265282/
17:38:36 <melwitt> jaypipes
17:38:43 <melwitt> :)
17:38:46 <mriedem> technically sdague,
17:38:51 <mriedem> who is held up on jaypipes
17:38:59 <mriedem> it's a turducken
17:39:06 <dansmith> I don't understand jaypipes' thing there
17:39:10 <melwitt> haha nice
17:39:19 <dansmith> we have flavors codified in instances already
17:39:23 <dansmith> and we have that link already
17:40:00 <madhu_ak> do we have fwaas meeting?
17:40:10 <alaski> dansmith: my read is that his goal is to remove all of that, and this is a first step towards that rather than codifying it further
17:40:17 <alaski> madhu_ak: there's another meeting here atm
17:40:43 <dansmith> alaski: I'm not sure who the he is in that statement exactly
17:40:53 <alaski> jaypipes
17:40:57 <dansmith> alaski: maybe we can appease jay by changing the resource name to "resources" or something
17:41:04 <madhu_ak> sorry alaski didnt account for daylight saving..
17:41:11 <alaski> madhu_ak: no worries
17:41:42 <alaski> dansmith: maybe. I do think it's really just a representation issue, shouldn't be too hard to workaround
17:41:57 <alaski> I just don't want to block on waiting for capabilities to be expressable
17:42:01 <dansmith> yeah
17:42:13 <dansmith> I'll look over that spec and the comments in a bit
17:43:55 <alaski> for divvying up work how about we all link our specs, or mention specs we want to propose, in https://etherpad.openstack.org/p/newton-nova-priorities-tracking and then get together on what we have the bandwidth for as a group
17:44:39 <melwitt> okay
17:44:46 <doffm> alaski: Good idea.
17:45:43 <alaski> cool
17:46:32 <alaski> I know bauzas is interested in rethinking the meeting times. I am going to take a look at what's available and look at alternates to the current times
17:46:56 <alaski> and we can vote on changing it or now
17:46:59 <alaski> *not
17:47:00 * jaypipes leading a meeting :(
17:47:37 <alaski> jaypipes: no worries
17:47:55 <alaski> along those lines, do you all want to meet next week or wait two weeks again?
17:48:53 <doffm> Will anyone be reviewing specs by next week?
17:48:56 <melwitt> either way works for me
17:49:22 <mriedem> i'm fine either way
17:49:32 <alaski> doffm: usually there aren't many reviews until RC2 is out
17:49:42 <doffm> Could probably leave it then. I don't mind.
17:49:43 <alaski> but reviews might start to trickle soon
17:49:59 <alaski> cool. let's skip again then
17:50:14 <alaski> #info Skip next weeks cells meeting
17:50:25 <alaski> any other topics for today?
17:50:48 <doffm> Not here.
17:51:13 <alaski> great
17:51:19 <alaski> until next time
17:51:23 <alaski> #endmeeting