16:12:29 #startmeeting Large Deployments Team 16:12:29 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:12:33 The meeting name has been set to 'large_deployments_team' 16:12:34 huzzah! 16:12:38 look at that! 16:12:41 there's a bot - so there will be minutes :) 16:12:44 uhhh 16:12:50 sweet - decision made - well done, team 16:12:55 :) 16:13:11 jobs done, time to go home 16:13:28 nice 16:13:35 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 ++ 16:14:02 #action VW email ops list that LDT meetings are moving to #openstack-operators 16:14:15 Ok, now that the chaos is sorted 16:14:26 you know, this just might up attendance 16:14:27 lets go back to YVR :) 16:15:18 #topic Review LDT discussions at YVR 16:16:06 so, for reference, we had a triple length working session for LDT at the summit 16:16:10 notes are here - https://etherpad.openstack.org/p/YVR-ops-large-deployments 16:16:37 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 and spent a lot of time on Neutron and cells/network segments 16:17:09 klindgren, mdorman, belmoreira - any other high level details you guys would add? 16:17:23 or anyone else here that was there, for that matter? 16:17:48 that neutron bug that got created around that stuff is getting some good traction and discussion 16:18:06 that's good 16:18:13 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 https://bugs.launchpad.net/neutron/+bug/1458890 16:18:16 Launchpad bug 1458890 in neutron "Add segment support to Neutron" [Undecided,Triaged] 16:18:27 Mostly I've just had those conversations in my head as we plan out AZ/HGs 16:18:38 and what failure domains mean in various places 16:19:15 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 the background on this was we all pretty much had different network layouts, but similar needs 16:20:52 so the problem with "Neutron and cells" was really that Neutron doesn't understand segmentation of the network 16:20:59 accurate ^ ? 16:21:03 Yes 16:21:58 +1 16:21:59 We have had a lot of discussion around this network segmentation in Neutron. 16:22:11 why are you mention cells? 16:22:41 because there was some assumption that cells == network segmentation, which is not ht ecase 16:22:44 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 some sites segement the network within cells 16:23:00 and in the future, everything will have cells, at least 1 16:23:04 imho Cells doesn't even need to be in that mix. The problem is the same with and without cells 16:23:20 in the future there is no "with and without" 16:23:22 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 right 16:23:33 sorry if I confused 16:23:43 was walking back through how the discussion went 16:23:50 ah - kk 16:24:05 I think is a more generic problem. we don't segment per cell... but inside the cell. 16:24:07 for me a cell is a segment, for you a cab, etc 16:24:10 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 so, for me the scope is wider 16:24:41 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 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 If you have the work flows in detail, the devs can convert transition points to actionable code. 16:25:27 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 rockyg: ++ 16:25:57 carl_baldwin, isn't that just designware at the moment? 16:26:11 rockyg: Yes. 16:26:16 Also, write what you do now, and what would be the preferred flow/flows 16:26:26 so, I've shared this elswhere, but we solved it with a plug-in - https://github.com/rackerlabs/quark 16:27:07 rockyg: ++ because I would like to read these write-ups that you are requesting. 16:28:00 agreed - the write-ups will be useful 16:28:08 is it best to put those as comments in the spec above? 16:29:08 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 although we could probably try to regurgitate that in a more useful format in the spec, etherpad, something else 16:29:40 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 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 The product wg has a template for use cases 16:30:32 I'll see if I can dig up location, but likely in openstack/openstack-spec 16:30:32 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 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 In fact, product_wg is putting a repo together specifically for use cases. 16:31:22 we can set a goal of having that togehter by early next week for review before the mid-cycle 16:31:23 go for it, mdorman 16:31:37 w))t! 16:31:47 sorry. w00t! 16:31:49 mdorman: The Neutron mid-cycle? Yes, that would be great. We could center our discussion around it. 16:32:04 #action mdorman & klindgren to create etherpad and condense currecnt use cases around network segmentation ahead of neutron mid-cycle 16:32:06 carl_baldwin: yes 16:32:12 I'd reccomend pinging myself, belmoreira, sam and others to seed it before you send it out too 16:32:24 that would be amazing, carl_baldwin 16:32:35 carl_baldwin, rockyg regXboi - how much detail would you like to see? 16:32:36 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 klindgren: I think what rockyg said above would get us started... 16:33:23 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 also see* 16:34:04 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 Collecting network layouts would be *extremely* informative to neutron folks. And could be used by the people building SDN/NFV stuff 16:34:27 kk 16:35:04 What carl_baldwin said. Layouts as a set can be more midterm. But, start collecting! Get the whole set! 16:35:48 #action klindgren and modorman to set up etherpad to better collect network segmentation use cases for Neutron mid-cycle 16:37:01 I think the only other big "network" related output from our YVR sessions was the schedule by IP capacity bits 16:37:22 and that was really a spec that mdorman and klindgren were pushing prior to the summmit if I remember 16:37:31 but that's not solely a Neutron thing, obviously 16:37:37 Correct - which we purposed as a spec/blueprint 16:38:07 Since when we presented it at the mid-cycle in philly other people were interested 16:39:00 https://review.openstack.org/#/c/180803/ 16:39:24 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 if there’s time/desire, could also discuss that at neutron mid-cycle,too, if it makes sense. 16:39:56 yeah - as long as we are prepping for ops/dev discussion at mid cycle ... 16:40:03 mdorman types faster than me :) 16:40:12 hehe 16:40:38 kinda leaving that up to neutron team, if they do or do not want that on the agenda 16:40:44 FYI. I created an etherpad for the segmentation use cases: https://etherpad.openstack.org/p/Network_Segmentation_Usecases 16:40:53 awesome 16:41:17 +1 - don't want to railroad their meetup :-) 16:41:21 Yeah. meeting moderator, wanna do a #link to that to get it in the minutes 16:41:44 #link etherpad for the segmentation use cases: https://etherpad.openstack.org/p/Network_Segmentation_Usecases 16:41:56 thans :-) 16:42:00 np 16:42:16 I'm not completely sure that commands besides stop and start are working 16:42:23 since topic gave no output 16:42:25 but we'll see 16:42:27 mdorman: I’ll make time to discuss the usage BP too. 16:42:44 if not, I'll call it out in our wiki summarry too, rockyg 16:43:28 kewl! 16:43:32 carl_baldwin: cool cool, thanks 16:43:54 awesome! Anything else Neutron related? 16:44:56 * VW takes that as a no 16:44:58 I dont have anything 16:45:09 #topic Backlog Specs 16:45:31 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 have you all seen backlog specs? 16:45:56 #link http://specs.openstack.org/openstack/nova-specs/specs/backlog/ 16:46:22 John Garbutt hit the mailing list with them shortly before the summit 16:46:34 ah - so this is similar to the rfe stuff for neutron? 16:46:46 right 16:46:48 basically it's a way to make feature requests in psuedo-spec format without all the details 16:46:49 yeah 16:47:03 kk 16:47:19 klindgren will you link that for reference in the logs? 16:47:48 #link http://specs.openstack.org/openstack/nova-specs/specs/backlog/ 16:47:58 no the Neutron bit 16:47:59 sorry 16:48:09 hehehe 16:48:45 #link http://docs.openstack.org/developer/neutron/policies/blueprints.html - see RFE section 16:49:08 sweet 16:49:10 thanks 16:50:10 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 so I'd like to at least make sure we integrate them in to our regular meetings where appropriate 16:50:39 ++ and its under rapid change.... 16:51:21 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 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 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 I dont have anything else 16:55:29 well 16:55:45 let me find something because there is an open bug on migration/resize/etc. 16:55:51 let me see if I can find it real quick 16:56:00 cool - at least link it jlk 16:56:20 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 we can keep discussing it, but want to honor the time from a "meeting" standpoint 16:56:35 thanks, rockyg 16:57:14 yeah please move on I'm having trouble locating :) 16:57:19 no worries 16:57:33 so, tom confirmed that the new git meeting thing doesn's support monthly meetings 16:57:40 so, we'll stick to this channel going forward 16:58:00 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 with that... 16:58:11 #topic Other Business 16:58:12 ah found it. 16:58:12 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 https://bugs.launchpad.net/nova/+bug/1293540 16:58:15 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 so it's a problem with any action that takes the last VM away from a host 16:58:48 and the review seems stuck 16:58:57 hmm - I'm not sure we are seeing that universally, jlk 16:59:13 we've been doing quite a bit of live migartion 16:59:19 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 ah - snapshot 16:59:32 https://review.openstack.org/#/c/149942/ is the review 16:59:34 missed that 16:59:34 sorry 16:59:57 Ok. I'm going to close the meeting bits down. Thanks folks for this. REALLY good discussion today 17:00:02 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 sorry about the confusion :\ 17:00:32 #endmeeting