16:12:29 <VW> #startmeeting Large Deployments Team
16:12:29 <openstack> Meeting started Thu Jun 18 16:12:29 2015 UTC and is due to finish in 60 minutes.  The chair is VW. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:12:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:12:33 <openstack> The meeting name has been set to 'large_deployments_team'
16:12:34 <jlk> huzzah!
16:12:38 <rockyg> look at that!
16:12:41 <regXboi> there's a bot - so there will be minutes :)
16:12:44 <belmoreira> uhhh
16:12:50 <VW> sweet - decision made - well done, team
16:12:55 <VW> :)
16:13:11 <jlk> jobs done, time to go home
16:13:28 <mdorman> nice
16:13:35 <VW> we may get other noise from other conversations, but this works.  I'll get a mail out to the whole list letting them know of the change
16:13:38 <rockyg> ++
16:14:02 <VW> #action VW email ops list that LDT meetings are moving to #openstack-operators
16:14:15 <VW> Ok, now that the chaos is sorted
16:14:26 <rockyg> you know, this just might up attendance
16:14:27 <VW> lets go back to YVR :)
16:15:18 <VW> #topic Review LDT discussions at YVR
16:16:06 <VW> so, for reference, we had a triple length working session for LDT at the summit
16:16:10 <VW> notes are here - https://etherpad.openstack.org/p/YVR-ops-large-deployments
16:16:37 <VW> we had a rough plan going in, but ended up talking a lot about how we collectively viewed host groupings - cells, AZ's, Host aggregates, etc
16:16:47 * pc_m even still lurking
16:16:53 <VW> and spent a lot of time on Neutron and cells/network segments
16:17:09 <VW> klindgren, mdorman, belmoreira - any other high level details you guys would add?
16:17:23 <VW> or anyone else here that was there, for that matter?
16:17:48 <mdorman> that neutron bug that got created around that stuff is getting some good traction and discussion
16:18:06 <jlk> that's good
16:18:13 <mdorman> klindgren and hopefully i, too, are going to go to the neutron mid-cycle next week to discuss (it’s local for us)
16:18:14 <klindgren> https://bugs.launchpad.net/neutron/+bug/1458890
16:18:16 <openstack> Launchpad bug 1458890 in neutron "Add segment support to Neutron" [Undecided,Triaged]
16:18:27 <jlk> Mostly I've just had those conversations in my head as we plan out AZ/HGs
16:18:38 <jlk> and what failure domains mean in various places
16:19:15 <VW> yeah - so let's table the host groupings for a bit and see if we can come back.  I expected a lot of today's chat to center on the Neutron bits
16:20:28 <VW> the background on this was we all pretty much had different network layouts, but similar needs
16:20:52 <VW> so the problem with "Neutron and cells" was really that Neutron doesn't understand segmentation of the network
16:20:59 <VW> accurate ^ ?
16:21:03 <klindgren> Yes
16:21:58 <mdorman> +1
16:21:59 <carl_baldwin> We have had a lot of discussion around this network segmentation in Neutron.
16:22:11 <belmoreira> why are you mention cells?
16:22:41 <jlk> because there was some assumption that cells == network segmentation, which is not ht ecase
16:22:44 <VW> well that's were we started belmoreira, but realized it was less about cells specifically and more about most of us had some relationship of network segments to cells
16:22:51 <jlk> some sites segement the network within cells
16:23:00 <jlk> and in the future, everything will have cells, at least 1
16:23:04 <klindgren> imho Cells doesn't even need to be in that mix.  The problem is the same with and without cells
16:23:20 <jlk> in the future there is no "with and without"
16:23:22 <VW> well it's not 1 to 1, jlk, but there is a relationship.  Either way, though - it brought up the segment issue
16:23:30 <VW> right
16:23:33 <VW> sorry if I confused
16:23:43 <VW> was walking back through how the discussion went
16:23:50 <klindgren> ah - kk
16:24:05 <belmoreira> I think is a more generic problem. we don't segment per cell... but inside the cell.
16:24:07 <VW> for me a cell is a segment, for you a cab, etc
16:24:10 <regXboi> carl_bladwin: is it fair to say that neutron does have a segment concept, but it doesn't necessarily meet operator's needs?
16:24:25 <belmoreira> so, for me the scope is wider
16:24:41 <rockyg> I'd like to suggest that those who have already dealt with the problem write up your current workflow(s) for *deploying network, *deploying segment, adding/deleting in working deployment, modifying ranges, etc
16:24:51 <regXboi> sorry... carl_baldwin: is it fair to say that neutron does have a segment concept, but it doesn't necessarily meet operator's needs?
16:25:18 <rockyg> If you have the work flows in detail, the devs can convert transition points to actionable code.
16:25:27 <carl_baldwin> regXboi: You are referring to the multi-provider extension?  In that case, I haven’t wrapped my head around it yet enough to agree or disagree.
16:25:54 <carl_baldwin> rockyg: ++
16:25:57 <rockyg> carl_baldwin, isn't that just designware at the moment?
16:26:11 <carl_baldwin> rockyg: Yes.
16:26:16 <rockyg> Also, write what you do now, and what would be the preferred flow/flows
16:26:26 <VW> so, I've shared this elswhere, but we solved it with a plug-in - https://github.com/rackerlabs/quark
16:27:07 <carl_baldwin> rockyg: ++ because I would like to read these write-ups that you are requesting.
16:28:00 <regXboi> agreed - the write-ups will be useful
16:28:08 <VW> is it best to put those as comments in the spec above?
16:29:08 <mdorman> regXboi / carl_baldwin, i think a lot of that stuff has been captured in the ML thread about “how your users actually use networking” (or whatever the topic is) that klindgren started
16:29:27 <mdorman> although we could probably try to regurgitate that in a more useful format in the spec, etherpad, something else
16:29:40 <regXboi> mdorman: I've been following that, but I'm trying to see how to get it to an "example use case" format
16:29:52 <rockyg> What I would do and am starting for logs is to start with an etherpad, get agreement on one or multiple flows, then publish.  Put the link to etherpad or published stuff in bug
16:30:13 <rockyg> The product wg has a template for use cases
16:30:32 <rockyg> I'll see if I can dig up location, but likely in openstack/openstack-spec
16:30:32 <carl_baldwin> mdorman: Yes, I’ve read through the thread.  I’ll give another read through.  Would also like to see it condensed and organized a bit.
16:31:08 <mdorman> ok, i can suggest that klindgren and i start an etherpad and solicit people via ML to fill in their use cases (if klindgren agrees)
16:31:18 <rockyg> In fact, product_wg is putting a repo together specifically for use cases.
16:31:22 <mdorman> we can set a goal of having that togehter by early next week for review before the mid-cycle
16:31:23 <VW> go for it, mdorman
16:31:37 <rockyg> w))t!
16:31:47 <rockyg> sorry.  w00t!
16:31:49 <carl_baldwin> mdorman: The Neutron mid-cycle?  Yes, that would be great.  We could center our discussion around it.
16:32:04 <mdorman> #action mdorman & klindgren to create etherpad and condense currecnt use cases around network segmentation ahead of neutron mid-cycle
16:32:06 <mdorman> carl_baldwin:  yes
16:32:12 <VW> I'd reccomend pinging myself, belmoreira, sam and others to seed it before you send it out too
16:32:24 <VW> that would be amazing, carl_baldwin
16:32:35 <klindgren> carl_baldwin, rockyg regXboi - how much detail would you like to see?
16:32:36 <rockyg> Yeah.  Having a workflow for midcycle would help focus design of the RFE to what you guys want rather than how the devs currently think about the issue
16:33:21 <regXboi> klindgren: I think what rockyg said above would get us started...
16:33:23 <klindgren> would it help if we included something about how our network is layed out - so that you can also the problems we are trying to solve?
16:34:00 <klindgren> also see*
16:34:04 <carl_baldwin> klindgren: I think mostly detail around any API changes you’ve made or how you’d like to use the API.  Network layout that is pertinent will be useful.
16:34:10 <rockyg> Collecting network layouts would be *extremely* informative to neutron folks.  And could be used by the people building SDN/NFV stuff
16:34:27 <mdorman> kk
16:35:04 <rockyg> What carl_baldwin said.  Layouts as a set can be more midterm.  But, start collecting! Get the whole set!
16:35:48 <VW> #action klindgren and modorman to set up etherpad to better collect network segmentation use cases for Neutron mid-cycle
16:37:01 <VW> I think the only other big "network" related output from our YVR sessions was the schedule by IP capacity bits
16:37:22 <VW> and that was really a spec that mdorman and klindgren were pushing prior to the summmit if I remember
16:37:31 <VW> but that's not solely a Neutron thing, obviously
16:37:37 <klindgren> Correct - which we purposed as a spec/blueprint
16:38:07 <klindgren> Since when we presented it at the mid-cycle in philly other people were interested
16:39:00 <klindgren> https://review.openstack.org/#/c/180803/
16:39:24 <mdorman> i feel like that one is probably pretty close, i think most of the concerns and stuff have been worked out.  but i haven’t looked at it for a few days
16:39:42 <mdorman> if there’s time/desire, could also discuss that at neutron mid-cycle,too, if it makes sense.
16:39:56 <VW> yeah - as long as we are prepping for ops/dev discussion at mid cycle ...
16:40:03 <VW> mdorman types faster than me :)
16:40:12 <mdorman> hehe
16:40:38 <mdorman> kinda leaving that up to neutron team, if they do or do not want that on the agenda
16:40:44 <rockyg> FYI.  I created an etherpad for the segmentation use cases:  https://etherpad.openstack.org/p/Network_Segmentation_Usecases
16:40:53 <mdorman> awesome
16:41:17 <klindgren> +1 - don't want to railroad their meetup :-)
16:41:21 <rockyg> Yeah.  meeting moderator, wanna do a #link to that to get it in the minutes
16:41:44 <VW> #link  etherpad for the segmentation use cases:  https://etherpad.openstack.org/p/Network_Segmentation_Usecases
16:41:56 <rockyg> thans :-)
16:42:00 <VW> np
16:42:16 <VW> I'm not completely sure that commands besides stop and start are working
16:42:23 <VW> since topic gave no output
16:42:25 <VW> but we'll see
16:42:27 <carl_baldwin> mdorman: I’ll make time to discuss the usage BP too.
16:42:44 <VW> if not, I'll call it out in our wiki summarry too, rockyg
16:43:28 <rockyg> kewl!
16:43:32 <mdorman> carl_baldwin:  cool cool, thanks
16:43:54 <VW> awesome!  Anything else Neutron related?
16:44:56 * VW takes that as a no
16:44:58 <klindgren> I dont have anything
16:45:09 <VW> #topic Backlog Specs
16:45:31 <VW> so, we may have touched on this briefly in the meeting in YVR, but wanted to bring it up here too in case folks missed it
16:45:39 <VW> have you all seen backlog specs?
16:45:56 <VW> #link http://specs.openstack.org/openstack/nova-specs/specs/backlog/
16:46:22 <VW> John Garbutt hit the mailing list with them shortly before the summit
16:46:34 <klindgren> ah - so this is similar to the rfe stuff for neutron?
16:46:46 <rockyg> right
16:46:48 <VW> basically it's a way to make feature requests in psuedo-spec format without all the details
16:46:49 <VW> yeah
16:47:03 <klindgren> kk
16:47:19 <VW> klindgren will you link that for reference in the logs?
16:47:48 <klindgren> #link http://specs.openstack.org/openstack/nova-specs/specs/backlog/
16:47:58 <VW> no the Neutron bit
16:47:59 <VW> sorry
16:48:09 <klindgren> hehehe
16:48:45 <klindgren> #link http://docs.openstack.org/developer/neutron/policies/blueprints.html - see RFE section
16:49:08 <VW> sweet
16:49:10 <VW> thanks
16:50:10 <VW> I want to make sure this group is aware of these types of feature request mechanisms.  We often come up with the common needs, but don't necessarily have all the details
16:50:27 <VW> so I'd like to at least make sure we integrate them in to our regular meetings where appropriate
16:50:39 <rockyg> ++ and its under rapid change....
16:51:21 <VW> and since most LDT folks are busy running big clouds - it might help things from stalling out waiting on time for us to build full blueprints
16:52:28 <VW> so we are short on time, but are there any other specs - full, backlog, RFE or otherwise that anyone needs feedback on?
16:54:57 <VW> I guess not.  In the future, though, feel free to add them to agendas if they aren't already out on the ML
16:54:59 <klindgren> I dont have anything else
16:55:29 <jlk> well
16:55:45 <jlk> let me find something because there is an open bug on migration/resize/etc.
16:55:51 <jlk> let me see if I can find it real quick
16:56:00 <VW> cool - at least link it jlk
16:56:20 <rockyg> wanted to let folks know I've started an etherpad to collect detailed usecases for logging that speak to stalled specs : request-id and error-codes  I'll publish a note to the ML
16:56:21 <VW> we can keep discussing it, but want to honor the time from a "meeting" standpoint
16:56:35 <VW> thanks, rockyg
16:57:14 <jlk> yeah please move on I'm having trouble locating :)
16:57:19 <VW> no worries
16:57:33 <VW> so, tom confirmed that the new git meeting thing doesn's support monthly meetings
16:57:40 <VW> so, we'll stick to this channel going forward
16:58:00 <VW> I'll update all the wiki's and get a poll out becuase we need an official time for the alternating months that favors the APAC folks
16:58:04 <VW> with that...
16:58:11 <VW> #topic Other Business
16:58:12 <jlk> ah found it.
16:58:12 <rockyg> And, I'll be reaching out for help on a philosphy doc on how operators and other users want output/interactions/flow so it is useful for them.
16:58:14 <jlk> https://bugs.launchpad.net/nova/+bug/1293540
16:58:15 <openstack> Launchpad bug 1293540 in OpenStack Compute (nova) "nova should make sure the bridge exists before resuming a VM after an offline snapshot" [Low,In progress] - Assigned to Luo Gangyi (luogangyi)
16:58:28 <jlk> so it's a problem with any action that takes the last VM away from a host
16:58:48 <jlk> and the review seems stuck
16:58:57 <VW> hmm - I'm not sure we are seeing that universally, jlk
16:59:13 <VW> we've been doing quite a bit of live migartion
16:59:19 <jlk> VW: you probably don't have many hosts with only one instance on them that would get a non-live snapshot done
16:59:32 <VW> ah - snapshot
16:59:32 <jlk> https://review.openstack.org/#/c/149942/ is the review
16:59:34 <VW> missed that
16:59:34 <VW> sorry
16:59:57 <VW> Ok. I'm going to close the meeting bits down.  Thanks folks for this.  REALLY good discussion today
17:00:02 <jlk> VW: well, it could be snapshot, it could be resize, it could be just about anything that would stop the last instance on a host and then try to bring it back.
17:00:04 <VW> sorry about the confusion :\
17:00:32 <VW> #endmeeting