21:00:14 <alaski> #startmeeting nova_cells
21:00:21 <openstack> Meeting started Wed Feb 24 21:00:14 2016 UTC and is due to finish in 60 minutes.  The chair is alaski. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:25 <openstack> The meeting name has been set to 'nova_cells'
21:00:27 <mriedem> o/
21:00:28 <doffm> o/
21:00:41 <alaski> cool, let's get going
21:00:45 <melwitt> o/
21:00:50 <alaski> #topic Testing
21:00:59 <alaski> any news on this front?
21:01:12 <mriedem> ccarmack isn't here
21:01:32 <alaski> okay
21:01:39 <alaski> he has a +2 and -1 on his review
21:02:03 <alaski> but seems to be moving forward
21:02:13 <mriedem> idk
21:02:41 <alaski> I'll have to look at the objections after this to see what's up
21:02:49 <alaski> #topic Open Reviews
21:02:58 <alaski> https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking as always
21:03:09 <alaski> take a peek in there at some point
21:03:22 <alaski> #topic Open Discussion
21:03:27 <mriedem> on reviews
21:03:28 <mriedem> ...
21:03:33 <mriedem> for the flavor db thing,
21:03:33 <alaski> #undo
21:03:33 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0xaf5f690>
21:03:42 <mriedem> we were waiting on that root_gb flavor spec
21:03:46 <mriedem> did that move forward at all?
21:04:04 <alaski> not yet
21:04:07 <doffm> mriedem: Which spec?
21:04:13 <alaski> I don't expect much from the spec until N is open though
21:04:28 <alaski> doffm: https://review.openstack.org/#/c/267673/
21:04:33 <mriedem> doffm: https://review.openstack.org/#/c/267673/
21:04:35 <mriedem> damn!
21:04:36 <mriedem> laski
21:04:42 <alaski> heh
21:04:43 <mriedem> well,
21:04:53 <mriedem> do we want to land the flavors tables things in mitaka?
21:04:57 <mriedem> if we want to punt,
21:05:03 <mriedem> we leave root_gb nullable=True
21:05:12 <alaski> right, I think that's what we do for now
21:05:15 <mriedem> we could always make it non-nullable with  a migration later
21:05:38 <alaski> I can comment on the flavor table review with that
21:05:54 <alaski> but if there's no opposition I think that leaves us the most options for now
21:06:33 <alaski> #topic Open Discussion
21:06:50 <mriedem> i did
21:06:55 <doffm> mriedem: We added something about Neutron?
21:07:00 <mriedem> doffm: i did
21:07:01 <alaski> mriedem: great
21:07:08 <mriedem> i do it all!
21:07:13 <doffm> Bwahhahah.
21:07:20 <melwitt> I have a couple of things I wanted to ask
21:07:37 <alaski> okay
21:07:42 <alaski> let's start with mriedem
21:08:01 <melwitt> one is for the CellMapping, do we want to consider making transport_url nullable or will cell0 be a special thing where it sets it as empty string and we make our code know not to switch mq in that case?
21:08:06 <melwitt> oops sorry
21:08:16 <mriedem> i don't have the agenda sitting in front of me
21:08:20 <mriedem> alaski: want to just paste the question
21:08:33 <alaski> mriedem: sure, but you're at the back of the line now
21:08:33 <doffm> melwitt: The latter option is what I'm assuming right now.
21:08:44 <doffm> melwitt: But if you are opposed...
21:09:17 <alaski> yeah, the latter option seemed fine with me
21:09:26 <melwitt> I don't have a strong opinion either way but wanted to see if anyone else had wondered about nullable as a way
21:09:52 <melwitt> because what that means is CellMapping must have a transport_url to make sense. except cell0
21:10:04 <melwitt> (non-nullable means that)
21:10:31 <mriedem> if it's non-nullable i guess you set a sentinel value
21:10:48 <doffm> mriedem: Thats what we are doing now.
21:10:53 <mriedem> if mapping.transport_url == 'special-unicorn': do x
21:11:01 <alaski> melwitt: my thinking was that we would know not to attempt an RPC call if the instance was in cell0. I guess it depends on where we want to have that check
21:11:07 <doffm> Unicorn = none:///
21:11:43 <alaski> should we check for cell0 before attempting RPC, or have RPC raise an exception if cell0?
21:12:26 <mriedem> wouldn't the latter be more performant?
21:12:34 <melwitt> alaski: I was imagining access to the instance is inside the with statement for the "target_cell" and then "if not transport_url: no-op" or something?
21:12:38 * mriedem actually has no idea what this whole discussion is about so should shut up
21:13:02 <melwitt> alaski: the check being inside the target_cell call
21:13:05 <alaski> mriedem: it's the same lookups either way, just about where the if statement goes
21:13:48 <melwitt> my other topic was, the potential oslo.messaging function we could write that assembles a transport_url from the various opts to various rpc backends
21:13:53 <doffm> I was imagining that if transport_url=unicorn, don't create or switch transport. Then later we could add something more complicated to check if transport is used to cell0. Create a transport that emits warnins.
21:14:38 <doffm> melwitt: I'd like to do that.
21:14:47 <doffm> Or someone do it.
21:14:51 <doffm> I think its generally useful.
21:14:58 <doffm> Especially for our nova-manage commands.
21:15:01 <alaski> the reason I leaned towards a unicorn transport is that if for some reason it does get passed to oslo.messaging hopefully it would fail gracefully, not blowup like None might do
21:15:20 <alaski> doffm: +1
21:15:44 <melwitt> doffm: sounds good to me
21:15:59 <doffm> Ok.
21:16:34 <melwitt> that's it from me, sorry for cutting in line
21:16:57 <doffm> mriedem? We are at the neutron-midcycle so we have some updates from there.
21:17:00 <alaski> heh, mriedem didn't have his papers in order
21:17:12 <doffm> We discussed cells.
21:17:27 <alaski> I think we're still open on the unicorn transport vs None thing
21:17:43 <doffm> * goes to the back of the line. :)
21:17:58 <melwitt> alaski: well, it can't be None I think because non-nullable. so empty string vs sentinel?
21:18:12 <melwitt> alaski: or am I wrong on what nullable means.. I get confused
21:18:18 <alaski> we could make it nullable
21:18:26 * bauzas waves late
21:18:28 <alaski> no, you're right on that
21:18:46 <alaski> I would prefer None or sentinel
21:19:08 <alaski> and sentinel works without a further migration
21:19:11 <doffm> I'd prefer sentinel. Because it will parse the oslo.messaging Transport stuff.
21:19:18 <melwitt> okay, so None is not a valid value for a non-nullable field. is that right?
21:19:25 <alaski> melwitt: right
21:19:50 <mriedem> alaski: technically my thing is last in open discussion
21:20:07 <mriedem> it's not really mine either, more from armax
21:20:09 <mriedem> i'm just a proxy
21:20:09 <alaski> doffm: I agree
21:20:51 <alaski> melwitt: are you okay with the sentinel or do you have an argument for None
21:22:19 <melwitt> yeah, I think the main thing is I wouldn't want to make transport_url nullable for just one case
21:22:47 <melwitt> when for everything except cell0 a CellMapping absolutely has to have a transport_url
21:22:52 <alaski> yeah
21:23:21 <alaski> okay. if you change your mind let doffm know with an angry -1 on his patch
21:23:38 <melwitt> haha
21:23:41 <alaski> doffm: sorry, your turn
21:23:55 <doffm> I guess just an update from the neutron meetup.
21:24:00 <alaski> great
21:24:31 <doffm> We briefly discussed `routed networks` and `resource pools` as a scaling solution.
21:24:52 <doffm> The general opinion was that that is an option, but only deals with data-plane scaling.
21:25:04 <alaski> yeah
21:25:05 <doffm> Something like `cells` for neutron could work for control-plane scaling.
21:25:18 <doffm> And we agreed to .... have some talks about that in the future.
21:25:29 <alaski> heh, sounds good
21:25:49 <alaski> is that a nebulous future or are there ideas on when/where?
21:25:51 <mriedem> i think armax is just curious to be in the loop on any requirements for neutron
21:25:59 <mriedem> so it's not a surprise to them later
21:26:14 <mriedem> or what the recommended deployment with cells v2 + neutron is going to be
21:26:17 <doffm> alaski: I could try to do it this week, but we will see.
21:26:29 <doffm> Yeah he wanted more deployment docs, earlier rather than later.
21:26:53 <alaski> okay
21:26:54 <mriedem> so,
21:27:01 <mriedem> i don't know if that could fit into the upgrade doc?
21:27:09 <mriedem> or something separate,
21:27:14 <mlavalle> alaski: is your concern mostly the data plane?
21:27:19 <mriedem> like, with cells v2 this is how we think thinks will work for networking
21:27:26 <mriedem> *things
21:27:32 <alaski> right now there are no requirements for neutron, but with multiple cells the use cases that CERN/Rackspace/GoDaddy have about network partitioning will come up
21:27:48 <mlavalle> alaski: that was the assumption it was made in the neutron mid-cycle
21:28:16 <mriedem> alaski: maybe just having their use cases doc'ed somewhere would be helpful?
21:28:17 <mriedem> idk
21:28:23 <alaski> mlavalle: yes, that's where current deployers have faced scaling issues
21:28:33 <alaski> mlavalle: well, mostly. but they've overcome control plane issues
21:29:00 <mlavalle> alaski: we think that routed networks will help with the data plane issues
21:29:01 <alaski> mriedem: that's a great idea
21:29:10 <alaski> mlavalle: that's my hope as well
21:29:25 <mriedem> alaski: is it also a great idea if you doc those? :P
21:29:29 <mriedem> b/c i don't know the details
21:29:52 <mriedem> or we could ask those guys to doc them in an etherpad
21:29:56 <mriedem> and we distill that into somtehing else
21:30:06 <doffm> mlavalle: Want to help out with the routed networks docs for that?
21:30:13 <alaski> heh, I don't either(just some about rax). But I can reach out to people to ask them to write some things
21:30:16 <mlavalle> alaski: I am part of that effort. and i'll continue attending this meeting, a cocnluesion is reached that we need to tackle also from the control plane
21:30:34 <mlavalle> doffm: yeah
21:30:41 <alaski> mriedem: +1. I'd like to get everyone to doc it in their own words
21:30:54 <alaski> then distill
21:30:55 <mriedem> #action get CERN/Rackspace/GoDaddy to doc their cells + networking use cases somewhere (etherpad most likely)
21:31:20 <mriedem> i can poke people
21:31:36 <alaski> okay, you know who at each place?
21:31:52 <mriedem> klindgren at godaddy, belmoria at cern, you at rax :)
21:32:00 <mriedem> i don't know a specific rax networking person
21:32:02 <alaski> hah, close enough for now
21:32:13 <alaski> tbh I don't know either right now
21:32:17 <alaski> johnthetubaguy might
21:32:38 <alaski> I would've said mlavalle not too long ago
21:32:59 <mriedem> i'll also post to the ops list
21:33:02 <mlavalle> alaski: in RAX, ping Ryan Clevenger (clev)
21:33:02 <mriedem> and poke some specific people
21:33:17 <alaski> mlavalle: great, thanks
21:33:25 <mlavalle> alaski: clev doesn't know, but the people who know work for him
21:33:39 <mlavalle> alaski: most likely, ahill
21:34:11 <alaski> mlavalle: for control plane scaling I would love to be involved in any conversations on the Neutron side. But I also think we can keep those details hidden from Nova, and just rely on routed networks for coordination
21:34:44 <mlavalle> alaski: there is no scaling up work taking place in Neutron's control plane right now
21:35:07 <doffm> mlavalle: Get together with russellb to discuss control plane scaling this week?
21:35:27 <mriedem> https://etherpad.openstack.org/p/cells-networking-use-cases
21:35:38 <mlavalle> alaski: what I meant earlier is that I am working on Routed Networks and I will monitor your work on Nova side, in case we need to re-visit on the Neutron side
21:35:39 <alaski> #link https://etherpad.openstack.org/p/cells-networking-use-cases
21:36:00 <alaski> mlavalle: okay
21:37:14 <alaski> that was essentially your agenda item right mriedem?
21:37:18 <mriedem> yeah
21:37:25 <alaski> cool
21:37:29 <alaski> anything else today?
21:37:35 <mriedem> there were other things in the agenda
21:37:38 <mriedem> db migrations and summit talks
21:37:40 <mriedem> or are those old?
21:37:46 <alaski> they're old
21:38:02 <alaski> doffm: you mentioned some specs yesterday
21:38:05 <bauzas> I guess that we'll be calling the wrap due to FF next week ?
21:38:16 <mriedem> bauzas: i hope so :)
21:38:19 <bauzas> so I'd like to know which changes are really prio
21:38:34 <mriedem> we can get the flavors db thing in this week
21:38:36 <bauzas> for Mitaka I mean
21:38:42 <doffm> alaski: I did, but I don't have those specs finished. Might as well discuss when they are. I'm working on db migrations specs for Newton.
21:38:44 <mriedem> i don't know the other changes
21:38:45 <alaski> bauzas: start here https://review.openstack.org/#/c/263926/11 :)
21:38:52 <alaski> doffm: okay
21:38:53 <bauzas> mriedem: I saw the convo by scrollbacking
21:39:08 <bauzas> mriedem: so the consensus is to not wait for the flavor spec ?
21:39:29 <bauzas> alaski: ack, right in my pipe
21:39:31 <mriedem> bauzas: we're going to mark root_gb as nullable=True
21:39:36 <mriedem> bauzas: we're going to punt on the decision
21:39:45 <mriedem> doffm can update the patch and i'll +2
21:39:49 <bauzas> okay, I should read the logs carefully
21:39:53 <alaski> bauzas: flavor db migration, nova-manage changes, and my series. I think those are the prio unless I'm forgetting something
21:39:55 <bauzas> okay, nice
21:39:57 <doffm> mriedem: Hokay.
21:40:07 <bauzas> alaski: okay, we can sprint those
21:41:17 <alaski> this does remind me. after FF we'll probably want to back off to less regular meetings while RC1 is being worked
21:41:37 <bauzas> fair point
21:41:57 <bauzas> RC1 will probably take me a lot of time
21:42:00 <alaski> doffm: mriedem last cycle we went to every other week due to the slowdown that occurs
21:42:17 <alaski> because outside of some specs and summit prep not much happens
21:42:23 <doffm> Sounds good.
21:42:25 <mriedem> yeah
21:42:50 <mriedem> ops email sent for networking
21:42:53 <mriedem> klindgren pinged
21:42:55 <mriedem> my job is done
21:42:57 <alaski> we'll workout the weeks and timeslot when FF hits
21:43:00 <alaski> mriedem: excellent work
21:43:09 <alaski> anything else?
21:43:13 <mriedem> nope
21:43:18 <doffm> No.
21:43:32 <alaski> great
21:43:43 <alaski> I can go watch for the tornadoes supposedly headed this way
21:43:46 <alaski> thanks all!
21:43:51 <doffm> Thanks.
21:43:51 <alaski> #endmeeting