14:00:56 <sgordon> #startmeeting telcowg
14:00:57 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:00 <openstack> The meeting name has been set to 'telcowg'
14:01:21 <sgordon> #link https://etherpad.openstack.org/p/nfv-meeting-agenda
14:01:23 <sgordon> #topic roll call
14:01:25 * sgordon here
14:01:28 <jaypipes> sgordon: mornin. (from 38000 feet)
14:01:30 <amitry> present
14:01:46 <dcw> hello
14:01:46 <sgordon> jaypipes, i will be joining you at that alt very shortly ;p
14:01:47 <cloudon1> hi
14:02:03 <sgordon> ok
14:02:09 <sgordon> #topic vancouver summit
14:02:34 <sgordon> 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 <sgordon> #link https://etherpad.openstack.org/p/YVR-ops-meetup
14:02:44 <dneary> Morning
14:02:57 * dneary here
14:03:10 <sgordon> we created a placeholder entry for telco working group in the relevant etherpad
14:03:22 <sgordon> but we need to flesh out what we would like to achieve with that session if we want to keep it
14:03:50 <sgordon> as it stands we have a number of use cases in various states of review
14:04:02 <sgordon> the key appears to be once we merge one (and we're very close to merging the first)
14:04:09 <dneary> 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 <sgordon> how to then move from that to gaps, to specifications, to implementation
14:05:04 <aveiga> That process needs to be well defined and posted somewhere
14:05:14 <aveiga> so we can do it fairly and in the open
14:05:21 <sgordon> indeed
14:05:23 <bryan_att> hi
14:05:36 <ian_ott> hi
14:05:47 <vks> hi
14:05:52 <sgordon> how/where to track gaps separately
14:06:04 <sgordon> as bugs under the telcowg project?
14:06:11 <sgordon> linking back to the use cases
14:06:18 <sgordon> e.g. one gap might facilitate multiple use cases
14:06:40 <sgordon> from there it becomes an issue of ownership by someone who is actually willing/able to draft a BP and implement
14:07:08 <aveiga> sgordon: that might be a good idea, since they can be triaged and linked to multiple use cases as 'affected' items
14:07:20 <sgordon> right
14:07:28 <sgordon> i am thinking this because just by virtue of setting everything up
14:07:35 <sgordon> we ended up with a LP area we dont currently really use
14:07:49 <vks> sgordon, LP?
14:07:51 <vks> :)
14:07:52 <sgordon> launchpad
14:07:55 <vks> aah
14:08:03 <sgordon> the alternative would be storyboard (DUN DUN DUN)
14:08:36 <aveiga> sgordon: let's not force people to use any more new tools than they have to
14:08:41 <sgordon> agree
14:08:52 <dneary> sgordon, To date, has anyone active in OPNFV been involved in the Telco use-case definition?
14:09:06 <jaypipes> 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 <sgordon> dneary, yes, those who participate in both groups
14:09:22 <dneary> OK, thanks
14:09:41 <sgordon> 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 <iben> #info Iben Rodriguez from spirent - #opnfv
14:10:20 <sgordon> #info Need to define process for taking merged use cases to the next step, gap definition, design, implementation
14:10:49 <jaypipes> sgordon: OK, fair enough. I think creating BPs in a telco-wg project on LP would work then, sure
14:11:02 <vks> sgordon, if we able to close one use case as first step it will be gud
14:11:13 <sgordon> #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 <dneary> One more dumb newcomer question: where can I see in-draft use cases?
14:11:47 <sgordon> vks, yes - i am raising this because the security segregation use case is close to merge
14:11:50 <sgordon> dneary, please read the agenda
14:11:51 <sgordon> thanks
14:11:57 <dneary> sgordon, OK
14:12:00 <sgordon> it was the first link pasted
14:12:04 <vks> sgordon, i am willing to help in implementation
14:12:09 <aveiga> jaypipes: we need to do the gap analaysis before we decide to file against a project though
14:12:09 <aveiga> we were going to do the analysis as bugs as well
14:12:09 <aveiga> otherwise I agree with you, the gaps should probably go against the project they affect
14:12:10 <aveiga> dneary: here!
14:12:10 <aveiga> #link https://review.openstack.org/#/q/project:stackforge/telcowg-usecases,n,z
14:12:41 <dneary> aveiga, sgordon: Thanks
14:12:41 <sgordon> aveiga, yeah i think we are in rough agreement - i dont think we want to file/stage blueprints themselves against telcowg
14:13:00 <sgordon> just tracking for "hey we need to create a blueprint for X that relates to use cases Y, Z"
14:13:08 <aveiga> sgordon: correct. The BPs should be in the project containing the gap
14:13:11 <sgordon> which seems ok to use bugs for to me
14:13:24 <aveiga> step 1 is file a use case
14:13:33 <aveiga> step 2 is to bug the use case for gap analysis
14:13:38 <sgordon> key point once we have those bugs is finding an owner who is willing to own implementation
14:13:46 <aveiga> step 3 is to generate a list of gaps in said bug
14:13:48 <sgordon> (for volunteers such as vks above to pick up)
14:13:58 <aveiga> step 4 is either open bugs against a project or file a BP for fixes
14:14:11 <sgordon> expectation of projects will be that there will be an owner for the BP who actually intends to work on it
14:15:09 <sgordon> #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 <sgordon> ok
14:15:22 <vks> sgordon, +1
14:15:35 <sgordon> 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 <sgordon> though we will hopefully start moving on this before summit
14:15:47 <sgordon> it will be a good checkpoint
14:16:03 <sgordon> #topic vancouver summit - design summit
14:16:17 <sgordon> a question was asked above about the design summit so let's go into where planning for that is at
14:16:27 <sgordon> #link https://wiki.openstack.org/wiki/Summit/Planning
14:16:47 <sgordon> most projects have already created etherpads for people to enter potential session topics in
14:16:53 <sgordon> they are linked from the above wiki page
14:17:11 <sgordon> 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 <sgordon> 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 <sgordon> this isn't necessarily true
14:18:13 <sgordon> primarily the sessions are intended to cater to discussion of larger or more controversial bodies of work
14:18:44 <aveiga> or for things that aren't fully defined yet
14:18:48 <sgordon> right
14:19:22 <sgordon> just as an example from the nova list "Quotas - how to make them better"
14:19:27 <sgordon> there's no one specific work item as such
14:19:29 <ian_ott> 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 <iben> Is there still a triple-o project? Isn't that ironic now?
14:19:44 <sgordon> just an acknowledgement that the way quotas work is not ideal and there is a need for improvement
14:19:59 <sgordon> iben, tripleo and ironic are not 1:1
14:20:25 <aveiga> 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 <sgordon> ian_ott, it really depends on the session, how well ATC access to the area is policed etc.
14:20:46 <sgordon> but i would expect the telco ops session if we have one to be pretty well attended
14:20:54 <sgordon> as well as anything that says containers in the title
14:21:22 <sgordon> basically if you intend to actively participate in a session sit close to the front
14:21:26 <sgordon> if you don't, don't ;)
14:21:35 <aveiga> +1
14:21:48 <sgordon> dneary, does the above kind of answer your questions from an OPNFV point of view?
14:21:56 <aveiga> also all of these sessions will have etherpads so participation comes in more than one form
14:22:02 <sgordon> yes
14:22:23 <dneary> sgordon, Just back from the wiki page... catching up with backlog
14:22:23 <iben> Hum.  And compass too. There are so many openstack installer projects now.
14:22:39 <sgordon> iben, ironic isnt an installer
14:22:49 <sgordon> it is a baremetal hypervisor driver that tripleo *uses*
14:22:52 <dneary> "larger or more controversial bodies of work" sounds like it applies to many telco related topics
14:23:26 <margaret__> 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 <sgordon> margaret__, yeah this is going to kind of segue into my next topic
14:23:52 <dneary> iben, Ironic = bare metal provisioning, triple-O = deploying OpenStack using Heat
14:24:02 <bryan_att> 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 <sgordon> #action sgordon to update YVR ops summit proposal
14:24:13 <dneary> sgordon, So, in summary:
14:24:29 <sgordon> bryan_att, probably - more controversial will be whether that belongs in openstack versus a focus on e.g. congress
14:24:50 <dneary> * 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 <bryan_att> not sure I understand - Congress is in OpenStack
14:24:57 <sgordon> bryan_att, exactly
14:25:12 <bryan_att> OK, how for the Telco WG session?
14:25:16 <sgordon> bryan_att, it seems like you are talking about an external user of congress and other cloud policy systems
14:25:34 <sgordon> dneary, no but having a blueprint will certainly help (and more importantly a specification)
14:25:36 <dneary> * 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 <dneary> sgordon, OK
14:25:47 <bryan_att> yes, as part of a multi-domain policy engine - SNDC and Compute/Storage VIMs
14:25:59 <sgordon> dneary, correct, but it would again be recommended to have blueprints/specifications sooner rather than later
14:26:09 <aveiga> 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 <aveiga> relevant, even
14:26:19 <dneary> So clearly (?) the various HA, multisite projects would need a design summit session
14:26:30 <sgordon> 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 <dneary> While mybe fault management doesn't?
14:27:08 <adrian-hoban> dneary: Not so sure fault mgmt doesn't deserve a session, particularly if you get into fault delivery performance
14:27:19 <bryan_att> 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 <dneary> adrian-hoban, OK
14:27:30 <sgordon> bryan_att, we're not talking about the telco wg atm
14:27:36 <sgordon> we are talking about the design summit sessions
14:27:43 <sgordon> and how they are scheduled
14:27:44 <bryan_att> OK, the design summit. got it.
14:27:52 <bryan_att> I'll wait
14:27:55 <HKirksey> 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 <dneary> 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 <sgordon> there wont be a telco-specific session in the design summit
14:28:26 <sgordon> design session topics are generally more specific to a) a project and b) a particular problem
14:28:42 <aveiga> 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 <dneary> HKirksey, design summit is for projects, ops summit is for use-cases, which can traverse many projects
14:29:12 <sgordon> 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 <sgordon> (im assuming here dneary is talking about VM HA)
14:30:12 <aveiga> yes, we would ideally take identified project gaps to design summit sessions
14:30:24 <sgordon> right
14:30:25 <dneary> 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 <dneary> Does a design summit session have to restrict its scope to a single OpenStack project?
14:30:47 <sgordon> yeah so almost inevitably the ceilometer response to that iwll
14:30:49 <sgordon> be
14:31:00 <sgordon> "nova doesnt emit such events, come back when it does"
14:31:19 <sgordon> there is the possiblity of a cross-project session
14:31:31 <dneary> sgordon, I'm talking about: https://wiki.opnfv.org/requirements_projects/high_availability_for_opnfv - so VM HA
14:31:32 <sgordon> but typically this has been seen as more for items that touch *every* project
14:31:41 <dneary> But multisite is VIM "HA"
14:31:55 <dneary> sgordon, OK, understood
14:32:52 <sgordon> 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 <sgordon> and the community direction was not to actively pursue it within the existing projects
14:33:18 <sgordon> (not that this prevents anyone working on it in the stackforge repo it currently has)
14:33:29 <adrian-hoban> 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 <margaret__> 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 <margaret__> Multi-site is important for telcos - so we should somehow pursue it - but with progress
14:34:23 <sgordon> margaret__, i am actually referring to the session where actual design work occurs
14:34:59 <margaret__> sgordon_ yes i understand..
14:35:00 <sgordon> 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 <sgordon> anyway
14:35:15 <dneary> sgordon, Noted
14:35:21 <sgordon> one last summit topic i want to hit !
14:35:30 <margaret__> multi-site is an OPNFV topic..
14:35:58 <sgordon> so multi-site doesnt require changes to OpenStack?
14:36:04 <dneary> margaret__, We're still working through what exactly multisite means in OPNFV afaict
14:36:35 <sgordon> #topic OPNFV day
14:36:41 <sgordon> one last thing i wanted to highlight
14:36:46 <margaret__> dneary_ yes once we decide what we mean by multi-site - we can then decide how it fits into openstack
14:36:54 <sgordon> there is again early in the week some space allocated for "related" projects
14:36:57 <dneary> margaret__, Agreed.
14:36:58 <sgordon> including OPNFV
14:37:13 <sgordon> OPNFV will have space on the monday from after the keynotes until the booth crawl in the evening
14:37:23 <sgordon> #link https://openstacksummitmay2015vancouver.sched.org/event/dbd2188f366a132cd38bd3e3811cb338#.VSUdI-TofCE
14:37:44 <sgordon> 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 <HKirksey> Yes, it’s still being planned
14:38:06 <sgordon> 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 <bryan_att> 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 <HKirksey> If anyone from this group has suggestions, we’re open to them
14:38:46 <sgordon> bryan_att, for the telco wg session if we get it then it will be a 90 minute working group session
14:39:05 <bryan_att> OK, so not much time
14:39:08 <sgordon> 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 <adrian-hoban> HKirksey: We should discuss OPNFV/TelcoWG collaboration
14:39:25 <adrian-hoban> And if possible, include ETSI-NFV spec alignment in that too
14:39:29 <sgordon> we can try and schedule time to discuss evolving use cases on a more adhoc basis i think
14:40:16 <adrian-hoban> Quite a long chain of events to get a feature from ETSI-NFV, through OPNFV and into OpenStack right now...
14:41:26 <bryan_att> we are trying to collapse that waterfall
14:41:38 <bryan_att> start in the middle and work outward
14:41:43 <sgordon> adrian-hoban, at the moment we're more focussed on opnfv<->telcowg i think
14:41:59 <sgordon> 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 <adrian-hoban> sgordon: Ok, fair enough
14:42:22 <margaret__> we are trying to get the ETSI to go through OPNFV...
14:43:12 <sgordon> margaret__, yes
14:43:35 <sgordon> margaret__, pragmatically though we havent really seen a lot of energy from ETSI going through anyone though
14:43:58 <sgordon> but anyway
14:44:19 <bryan_att> the good thing is that we (as members) are in both places and can make the agile collaboration happen anyway
14:44:55 <adrian-hoban> bryan_att: Agreed
14:45:40 <sgordon> #topic use cases
14:45:52 <sgordon> 15 min left so i wanted to make sure we touch this
14:45:54 <dneary> 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 <sgordon> #link https://review.openstack.org/#/q/status:open+project:stackforge/telcowg-usecases,n,z
14:47:45 <sgordon> sooo we have the three use cases in the queue atm
14:47:54 <sgordon> #link https://review.openstack.org/#/c/163399/
14:48:04 <sgordon> security segregation being the one closest to merge
14:48:11 <matrohon> 4; I just added the BGPVPN use case :)
14:48:21 <aveiga> good!
14:48:25 <bryan_att> my impression is that the use cases are pretty broadly defined in some cases
14:48:29 <aveiga> all of them deserve reviews
14:48:39 <sgordon> just wanted to get Dennis's feedback to ensure that the comments were actioned
14:48:41 <sgordon> aveiga, +1
14:48:52 <cloudon1> soon will be 5 once I add virtual SBC
14:49:35 <sgordon> 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 <bryan_att> I guess I meant that the scope is large in some cases
14:50:21 <sgordon> that is probably to be expected
14:50:40 <sgordon> comes back to what aveiga was talking about earlier about tracking out the gaps into actionable work items
14:51:07 <vks> sgordon, that wd be gud
14:51:11 <bryan_att> 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 <aveiga> 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 <aveiga> bryan_att: I think that's a discussion worth having as not everyone even understands that problem
14:52:39 <bryan_att> 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 <sgordon> i think it might be
14:53:00 <sgordon> the thing with the sessions is typically a design session is 40 mins
14:53:07 <sgordon> 90 mins for one of these ops summit working groups
14:53:12 <aveiga> it's possible that's a good pod discussion
14:53:17 <sgordon> if you have to spend too much time baselining people
14:53:26 <sgordon> then you are already racing the clock
14:53:35 <sgordon> aveiga +1
14:53:38 <bryan_att> agreed
14:54:10 <aveiga> 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 <sgordon> yeah
14:54:59 <adrian-hoban> 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 <sgordon> #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 <aveiga> adrian-hoban: this sounds like a pod discussion too, since it's active work on a topic
14:56:01 <aveiga> I'd say a BoF, but there's no officially designated space for those
14:56:08 <sgordon> yeah
14:56:24 <sgordon> there were some complaints about that last time but i believe vancouver space had already been allocated
14:56:37 <sgordon> i think they are going to try do something more formal for BoFs for tokyo
14:58:13 <HKirksey> Would some time for that be a useful thing to possisbly do at OPNFV Day at Monday?
14:58:22 <aveiga> HKirksey: yes!
14:58:37 <sgordon> yes i think so
14:58:57 <adrian-hoban> aveiga: Do you think we would get suitable representation from the projects at the pod sessions?
14:59:33 <aveiga> adrian-hoban: I do not know
14:59:49 <aveiga> it depends on how we phrase the topic
14:59:58 <aveiga> and how interested individuals are
14:59:59 <sgordon> #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 <sgordon> yeah
15:00:06 <sgordon> i would look at it this way
15:00:09 <HKirksey> Ok, another stupid question…what are pod sessions?
15:00:14 <sgordon> if a topic is not accepted to the design session
15:00:19 <sgordon> doesnt fit in the time for the ops session
15:00:34 <sgordon> what other option do you currently have that would get more project representation?
15:00:46 <HKirksey> ok thanks, sgordon
15:00:49 <sgordon> HKirksey, basically there are some informal "pods"
15:00:54 <sgordon> in the design summit area usually
15:01:00 <sgordon> basically a round table with ~8 chairs
15:01:08 <sgordon> that can be booked for a session at a time
15:01:18 <aveiga> ad-hoc bookings, btw
15:01:24 <sgordon> usually they have some kind of project name or general topic so that they are roughly grouped by area of interest
15:01:24 <aveiga> usually first come first served
15:01:36 <dneary> thanks
15:02:17 <adrian-hoban> 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 <sgordon> adrian-hoban, do you mean pre summit or the sessions during summit?
15:04:02 <adrian-hoban> sgordon: During
15:04:25 <sgordon> ack
15:04:36 <sgordon> i had discussed with HKirksey producing a cheat sheet again
15:04:39 <adrian-hoban> 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 <sgordon> relevant sessions for telco/nfv
15:04:55 <sgordon> well in fairness i was at the priority session
15:05:12 <HKirksey> Will having more of us at a priority session be useful?
15:05:18 <sgordon> so it was represented but not seen as being as important as the items that did have core buy in
15:05:29 <adrian-hoban> Several were, but we didn't have the same representation as the day before
15:05:38 <adrian-hoban> If numbers count...
15:05:40 <sgordon> in general i would say it's useful to have more technical people who own the actual implementation
15:05:48 <sgordon> i need to cut this off
15:05:55 <sgordon> we're 5m over and i need to follow jaypipes into the skies
15:05:56 <sgordon> ;p
15:06:04 <adrian-hoban> Tends to bite at the backend when there is core reviewer pressure
15:06:15 <sgordon> #info need to ensure design session representation
15:06:17 <sgordon> #endmeeting