14:00:56 #startmeeting telcowg 14:00:57 Meeting started Wed Apr 8 14:00:56 2015 UTC and is due to finish in 60 minutes. The chair is sgordon. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:00 The meeting name has been set to 'telcowg' 14:01:21 #link https://etherpad.openstack.org/p/nfv-meeting-agenda 14:01:23 #topic roll call 14:01:25 * sgordon here 14:01:28 sgordon: mornin. (from 38000 feet) 14:01:30 present 14:01:46 hello 14:01:46 jaypipes, i will be joining you at that alt very shortly ;p 14:01:47 hi 14:02:03 ok 14:02:09 #topic vancouver summit 14:02:34 last week we touched on summit briefly and i wanted to re-visit here as i know in particular tom is working to nail down scheduling for the operators tracks 14:02:42 #link https://etherpad.openstack.org/p/YVR-ops-meetup 14:02:44 Morning 14:02:57 * dneary here 14:03:10 we created a placeholder entry for telco working group in the relevant etherpad 14:03:22 but we need to flesh out what we would like to achieve with that session if we want to keep it 14:03:50 as it stands we have a number of use cases in various states of review 14:04:02 the key appears to be once we merge one (and we're very close to merging the first) 14:04:09 sgordon, Would it be possibleto talk about the design summit scheduling process afterwards? There are a few OPNFV folks who don't understand it very well & want to make sure we don't miss that boat 14:04:31 how to then move from that to gaps, to specifications, to implementation 14:05:04 That process needs to be well defined and posted somewhere 14:05:14 so we can do it fairly and in the open 14:05:21 indeed 14:05:23 hi 14:05:36 hi 14:05:47 hi 14:05:52 how/where to track gaps separately 14:06:04 as bugs under the telcowg project? 14:06:11 linking back to the use cases 14:06:18 e.g. one gap might facilitate multiple use cases 14:06:40 from there it becomes an issue of ownership by someone who is actually willing/able to draft a BP and implement 14:07:08 sgordon: that might be a good idea, since they can be triaged and linked to multiple use cases as 'affected' items 14:07:20 right 14:07:28 i am thinking this because just by virtue of setting everything up 14:07:35 we ended up with a LP area we dont currently really use 14:07:49 sgordon, LP? 14:07:51 :) 14:07:52 launchpad 14:07:55 aah 14:08:03 the alternative would be storyboard (DUN DUN DUN) 14:08:36 sgordon: let's not force people to use any more new tools than they have to 14:08:41 agree 14:08:52 sgordon, To date, has anyone active in OPNFV been involved in the Telco use-case definition? 14:09:06 sgordon: I think as much as possible, we should focus on the upstream projects (nova, neutron, etc) and ensure that bugs are tagged with "telco" or "telcowg". We can also, if it's specifically a telco thing and not necessarily useful outside of telco, prefix blueprints with "telco-" 14:09:10 dneary, yes, those who participate in both groups 14:09:22 OK, thanks 14:09:41 jaypipes, yeah my fear if we raise a bug for tracking a gap while we work on a BP is that in the core projects it will be closed "raise a bp!" 14:09:53 #info Iben Rodriguez from spirent - #opnfv 14:10:20 #info Need to define process for taking merged use cases to the next step, gap definition, design, implementation 14:10:49 sgordon: OK, fair enough. I think creating BPs in a telco-wg project on LP would work then, sure 14:11:02 sgordon, if we able to close one use case as first step it will be gud 14:11:13 #info Options include a) raise a bug under telcowg area for each gap, linking back to use cases, while BP is being drafted b) Filing directly in core projects with telco tag (for bugs) or telco- prefix (for blueprints) 14:11:33 One more dumb newcomer question: where can I see in-draft use cases? 14:11:47 vks, yes - i am raising this because the security segregation use case is close to merge 14:11:50 dneary, please read the agenda 14:11:51 thanks 14:11:57 sgordon, OK 14:12:00 it was the first link pasted 14:12:04 sgordon, i am willing to help in implementation 14:12:09 jaypipes: we need to do the gap analaysis before we decide to file against a project though 14:12:09 we were going to do the analysis as bugs as well 14:12:09 otherwise I agree with you, the gaps should probably go against the project they affect 14:12:10 dneary: here! 14:12:10 #link https://review.openstack.org/#/q/project:stackforge/telcowg-usecases,n,z 14:12:41 aveiga, sgordon: Thanks 14:12:41 aveiga, yeah i think we are in rough agreement - i dont think we want to file/stage blueprints themselves against telcowg 14:13:00 just tracking for "hey we need to create a blueprint for X that relates to use cases Y, Z" 14:13:08 sgordon: correct. The BPs should be in the project containing the gap 14:13:11 which seems ok to use bugs for to me 14:13:24 step 1 is file a use case 14:13:33 step 2 is to bug the use case for gap analysis 14:13:38 key point once we have those bugs is finding an owner who is willing to own implementation 14:13:46 step 3 is to generate a list of gaps in said bug 14:13:48 (for volunteers such as vks above to pick up) 14:13:58 step 4 is either open bugs against a project or file a BP for fixes 14:14:11 expectation of projects will be that there will be an owner for the BP who actually intends to work on it 14:15:09 #info telcowg project would not be used to file/stage blueprints themselves, simply to track "gap X exists that relates to use cases Y, Z and needs a blueprint to resolve" 14:15:15 ok 14:15:22 sgordon, +1 14:15:35 so w.r.t. YVR i think this gives me plenty to flesh out the etherpad entry in https://etherpad.openstack.org/p/YVR-ops-meetup 14:15:43 though we will hopefully start moving on this before summit 14:15:47 it will be a good checkpoint 14:16:03 #topic vancouver summit - design summit 14:16:17 a question was asked above about the design summit so let's go into where planning for that is at 14:16:27 #link https://wiki.openstack.org/wiki/Summit/Planning 14:16:47 most projects have already created etherpads for people to enter potential session topics in 14:16:53 they are linked from the above wiki page 14:17:11 the PTLs will be taking this input to try and work out the scheduling for the slots allocated for their project(s) 14:17:50 in the past there has been an assumption/belief that "if I have a BP then I need it to be discussed in a design session to be successful" 14:17:58 this isn't necessarily true 14:18:13 primarily the sessions are intended to cater to discussion of larger or more controversial bodies of work 14:18:44 or for things that aren't fully defined yet 14:18:48 right 14:19:22 just as an example from the nova list "Quotas - how to make them better" 14:19:27 there's no one specific work item as such 14:19:29 at the last summit, the turn out was huge, despite these meetings having only a few participants - will it be the same in Vancouver? 14:19:37 Is there still a triple-o project? Isn't that ironic now? 14:19:44 just an acknowledgement that the way quotas work is not ideal and there is a need for improvement 14:19:59 iben, tripleo and ironic are not 1:1 14:20:25 ian_ott: probably, since people may already be there for other reasons and notice that "Hey, there's this Telco thing going on" 14:20:30 ian_ott, it really depends on the session, how well ATC access to the area is policed etc. 14:20:46 but i would expect the telco ops session if we have one to be pretty well attended 14:20:54 as well as anything that says containers in the title 14:21:22 basically if you intend to actively participate in a session sit close to the front 14:21:26 if you don't, don't ;) 14:21:35 +1 14:21:48 dneary, does the above kind of answer your questions from an OPNFV point of view? 14:21:56 also all of these sessions will have etherpads so participation comes in more than one form 14:22:02 yes 14:22:23 sgordon, Just back from the wiki page... catching up with backlog 14:22:23 Hum. And compass too. There are so many openstack installer projects now. 14:22:39 iben, ironic isnt an installer 14:22:49 it is a baremetal hypervisor driver that tripleo *uses* 14:22:52 "larger or more controversial bodies of work" sounds like it applies to many telco related topics 14:23:26 OPNFV members are slowly trying to get more engaged - but we have a near term release coming out. We see the Telco group as a venue for us once we have SW to upstream 14:23:51 margaret__, yeah this is going to kind of segue into my next topic 14:23:52 iben, Ironic = bare metal provisioning, triple-O = deploying OpenStack using Heat 14:24:02 Would people consider discussing needs/ideas around how policy can be managed across VIMs (OpenStack being one) a "large or controversial" issue? 14:24:12 #action sgordon to update YVR ops summit proposal 14:24:13 sgordon, So, in summary: 14:24:29 bryan_att, probably - more controversial will be whether that belongs in openstack versus a focus on e.g. congress 14:24:50 * If there are OPNFV blueprints which we suspect will be controversial, do we need a blueprint in Gerrit to propose a session? 14:24:51 not sure I understand - Congress is in OpenStack 14:24:57 bryan_att, exactly 14:25:12 OK, how for the Telco WG session? 14:25:16 bryan_att, it seems like you are talking about an external user of congress and other cloud policy systems 14:25:34 dneary, no but having a blueprint will certainly help (and more importantly a specification) 14:25:36 * If there are changes we don't expect to be controversial, then there is no hard & fast requirement to have a design smmit session for the blueprint to get into the Liberty roadmap 14:25:44 sgordon, OK 14:25:47 yes, as part of a multi-domain policy engine - SNDC and Compute/Storage VIMs 14:25:59 dneary, correct, but it would again be recommended to have blueprints/specifications sooner rather than later 14:26:09 dneary: you'll need to get a spec in with the revelant core project by their planning deadline, but that deadline is almost never the summit 14:26:17 relevant, even 14:26:19 So clearly (?) the various HA, multisite projects would need a design summit session 14:26:30 bryan_att, right so what i am saying is from an openstack design summit point of view, that is something you would implement outside of openstack no? 14:26:31 While mybe fault management doesn't? 14:27:08 dneary: Not so sure fault mgmt doesn't deserve a session, particularly if you get into fault delivery performance 14:27:19 Yes, but I would think that how OpenStack could/would be used as part of a larger picture would be important to the telco WG 14:27:20 adrian-hoban, OK 14:27:30 bryan_att, we're not talking about the telco wg atm 14:27:36 we are talking about the design summit sessions 14:27:43 and how they are scheduled 14:27:44 OK, the design summit. got it. 14:27:52 I'll wait 14:27:55 Sorry if this is a dumb question, but what’s the difference of intent between the telco session in Ops and design summit sessions? 14:28:09 adrian-hoban, My goal is to figure out how much of a hurry I need to put on project owners to get blueprint drafts in shape for Gerrit review, and how they would go about proposing a summit session once they are (Steve answered the 2nd part) 14:28:11 there wont be a telco-specific session in the design summit 14:28:26 design session topics are generally more specific to a) a project and b) a particular problem 14:28:42 design summit is for ATCs only and focused on the projects like nova/ neutron, etc. Telco ops session is for operators to discuss issues/needs 14:28:55 HKirksey, design summit is for projects, ops summit is for use-cases, which can traverse many projects 14:29:12 what makes more sense is kind of what dave is getting at which is that a Nova session on HA for example might make sense - *if* a relevant proposal exists to illustrate why a session is needed 14:29:24 (im assuming here dneary is talking about VM HA) 14:30:12 yes, we would ideally take identified project gaps to design summit sessions 14:30:24 right 14:30:25 One more follow-up re fault management: there are 3 blueprints right now being worked on - one for Nova (expose hardware events through Nova) and two for Ceilometer (reacting to hardware events) 14:30:43 Does a design summit session have to restrict its scope to a single OpenStack project? 14:30:47 yeah so almost inevitably the ceilometer response to that iwll 14:30:49 be 14:31:00 "nova doesnt emit such events, come back when it does" 14:31:19 there is the possiblity of a cross-project session 14:31:31 sgordon, I'm talking about: https://wiki.opnfv.org/requirements_projects/high_availability_for_opnfv - so VM HA 14:31:32 but typically this has been seen as more for items that touch *every* project 14:31:41 But multisite is VIM "HA" 14:31:55 sgordon, OK, understood 14:32:52 dneary, my fair warning with multi site would be that unless the proposal has changed significantly this actually had a session last summit 14:33:04 and the community direction was not to actively pursue it within the existing projects 14:33:18 (not that this prevents anyone working on it in the stackforge repo it currently has) 14:33:29 Re alarms, a more fundamental discussion is what is the required performance of alarm delivery. This has not shown up in OPNFV yet 14:33:47 I understand it was a 2 hour discussion at the Openstack board - multi-site and what is the defnition of multi-site 14:34:17 Multi-site is important for telcos - so we should somehow pursue it - but with progress 14:34:23 margaret__, i am actually referring to the session where actual design work occurs 14:34:59 sgordon_ yes i understand.. 14:35:00 for a variety of reasons that i dont necessarily agree with i would say the community doesnt have great visibility into the ins and outs of any discussions that happen in the context of the board 14:35:11 anyway 14:35:15 sgordon, Noted 14:35:21 one last summit topic i want to hit ! 14:35:30 multi-site is an OPNFV topic.. 14:35:58 so multi-site doesnt require changes to OpenStack? 14:36:04 margaret__, We're still working through what exactly multisite means in OPNFV afaict 14:36:35 #topic OPNFV day 14:36:41 one last thing i wanted to highlight 14:36:46 dneary_ yes once we decide what we mean by multi-site - we can then decide how it fits into openstack 14:36:54 there is again early in the week some space allocated for "related" projects 14:36:57 margaret__, Agreed. 14:36:58 including OPNFV 14:37:13 OPNFV will have space on the monday from after the keynotes until the booth crawl in the evening 14:37:23 #link https://openstacksummitmay2015vancouver.sched.org/event/dbd2188f366a132cd38bd3e3811cb338#.VSUdI-TofCE 14:37:44 i defer to HKirksey on how that space/time might be divided up at the moment which is i believe still being planned 14:37:57 Yes, it’s still being planned 14:38:06 but wanted to highlight it again just so people are aware that there will be like minded folk gathering to discuss topics that are likely of interest 14:38:13 do we need to issue a use case (step #1 above) to propose a session topic for the OPNFV day or the Telco WG sessions? 14:38:22 If anyone from this group has suggestions, we’re open to them 14:38:46 bryan_att, for the telco wg session if we get it then it will be a 90 minute working group session 14:39:05 OK, so not much time 14:39:08 we would likely try and structure it based on time for process updates/review and then working through examples based on use cases submitted/merged 14:39:15 HKirksey: We should discuss OPNFV/TelcoWG collaboration 14:39:25 And if possible, include ETSI-NFV spec alignment in that too 14:39:29 we can try and schedule time to discuss evolving use cases on a more adhoc basis i think 14:40:16 Quite a long chain of events to get a feature from ETSI-NFV, through OPNFV and into OpenStack right now... 14:41:26 we are trying to collapse that waterfall 14:41:38 start in the middle and work outward 14:41:43 adrian-hoban, at the moment we're more focussed on opnfv<->telcowg i think 14:41:59 adrian-hoban, i would like to deal with the ETSI end as well but that's a bit too much for me to chew ;p 14:42:21 sgordon: Ok, fair enough 14:42:22 we are trying to get the ETSI to go through OPNFV... 14:43:12 margaret__, yes 14:43:35 margaret__, pragmatically though we havent really seen a lot of energy from ETSI going through anyone though 14:43:58 but anyway 14:44:19 the good thing is that we (as members) are in both places and can make the agile collaboration happen anyway 14:44:55 bryan_att: Agreed 14:45:40 #topic use cases 14:45:52 15 min left so i wanted to make sure we touch this 14:45:54 sgordon, margaret__: There has been some good change recently in ETSI NFV processes - I'm hopeful we can get ppl from ETSI engaged in project definition in OPNFV, and ensure they're providing guidance and comments on blueprints being reviewed in OpenStack 14:45:58 #link https://review.openstack.org/#/q/status:open+project:stackforge/telcowg-usecases,n,z 14:47:45 sooo we have the three use cases in the queue atm 14:47:54 #link https://review.openstack.org/#/c/163399/ 14:48:04 security segregation being the one closest to merge 14:48:11 4; I just added the BGPVPN use case :) 14:48:21 good! 14:48:25 my impression is that the use cases are pretty broadly defined in some cases 14:48:29 all of them deserve reviews 14:48:39 just wanted to get Dennis's feedback to ensure that the comments were actioned 14:48:41 aveiga, +1 14:48:52 soon will be 5 once I add virtual SBC 14:49:35 bryan_att, i think the expectation is that if people think they should be more detailed in places then they add comments to that effect 14:50:07 I guess I meant that the scope is large in some cases 14:50:21 that is probably to be expected 14:50:40 comes back to what aveiga was talking about earlier about tracking out the gaps into actionable work items 14:51:07 sgordon, that wd be gud 14:51:11 if I were to address the larger issues around policy management across VIMs and why we likely need a bifurcated approach across VIMs for now, and how OpenStack might change to address that bifurcation, would that fit into what "use cases" are meant to be? 14:51:25 I think scoping on the use cases is going to depend on the case. Sometimes getting more granular doesnt' necessarily help the gap analysis 14:52:02 bryan_att: I think that's a discussion worth having as not everyone even understands that problem 14:52:39 that's where I was going with the session ideas note for Vancouver - but I can work on a use case doc if that's the best first step 14:52:50 i think it might be 14:53:00 the thing with the sessions is typically a design session is 40 mins 14:53:07 90 mins for one of these ops summit working groups 14:53:12 it's possible that's a good pod discussion 14:53:17 if you have to spend too much time baselining people 14:53:26 then you are already racing the clock 14:53:35 aveiga +1 14:53:38 agreed 14:54:10 why don't we get a pod discussion up about that when the etherpads open? If it's policy maybe we start with the Congress pod? 14:54:25 yeah 14:54:59 It would be great if we could use the time together to identify actionable gaps on the use cases that we merge beforehand 14:55:02 #info Need to create pod discussions once the etherpads for them open for topics that may not quite fit into a design session mold 14:55:46 adrian-hoban: this sounds like a pod discussion too, since it's active work on a topic 14:56:01 I'd say a BoF, but there's no officially designated space for those 14:56:08 yeah 14:56:24 there were some complaints about that last time but i believe vancouver space had already been allocated 14:56:37 i think they are going to try do something more formal for BoFs for tokyo 14:58:13 Would some time for that be a useful thing to possisbly do at OPNFV Day at Monday? 14:58:22 HKirksey: yes! 14:58:37 yes i think so 14:58:57 aveiga: Do you think we would get suitable representation from the projects at the pod sessions? 14:59:33 adrian-hoban: I do not know 14:59:49 it depends on how we phrase the topic 14:59:58 and how interested individuals are 14:59:59 #action HKirksey to look at allocating some time in OPNFV day for additional telco working group time to look at actionable gaps for existing use cases 15:00:01 yeah 15:00:06 i would look at it this way 15:00:09 Ok, another stupid question…what are pod sessions? 15:00:14 if a topic is not accepted to the design session 15:00:19 doesnt fit in the time for the ops session 15:00:34 what other option do you currently have that would get more project representation? 15:00:46 ok thanks, sgordon 15:00:49 HKirksey, basically there are some informal "pods" 15:00:54 in the design summit area usually 15:01:00 basically a round table with ~8 chairs 15:01:08 that can be booked for a session at a time 15:01:18 ad-hoc bookings, btw 15:01:24 usually they have some kind of project name or general topic so that they are roughly grouped by area of interest 15:01:24 usually first come first served 15:01:36 thanks 15:02:17 One more topic, possibly for next time. When it comes to prioritization discussions in the projects, we need Telco representation, or risk any traction being lost 15:03:27 adrian-hoban, do you mean pre summit or the sessions during summit? 15:04:02 sgordon: During 15:04:25 ack 15:04:36 i had discussed with HKirksey producing a cheat sheet again 15:04:39 Last time, we had a great joint discussion with the Nova guys, the next day they had a priority discussion, and several of the Telco items didn't make the cut 15:04:40 relevant sessions for telco/nfv 15:04:55 well in fairness i was at the priority session 15:05:12 Will having more of us at a priority session be useful? 15:05:18 so it was represented but not seen as being as important as the items that did have core buy in 15:05:29 Several were, but we didn't have the same representation as the day before 15:05:38 If numbers count... 15:05:40 in general i would say it's useful to have more technical people who own the actual implementation 15:05:48 i need to cut this off 15:05:55 we're 5m over and i need to follow jaypipes into the skies 15:05:56 ;p 15:06:04 Tends to bite at the backend when there is core reviewer pressure 15:06:15 #info need to ensure design session representation 15:06:17 #endmeeting