14:00:20 <sgordon> #startmeeting telcowg
14:00:20 <openstack> Meeting started Wed Apr 22 14:00:20 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:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:23 <openstack> The meeting name has been set to 'telcowg'
14:00:26 <sgordon> #link https://etherpad.openstack.org/p/nfv-meeting-agenda
14:00:31 <sgordon> #chair aveiga
14:00:32 <openstack> Current chairs: aveiga sgordon
14:00:37 <sgordon> #topic roll call
14:00:40 * sgordon here
14:00:41 <aveiga> hello
14:00:47 <matrohon> hi
14:00:58 <cloudon> hi
14:02:28 <sgordon> ok
14:02:31 <sgordon> some house keeping
14:02:36 <sgordon> #topic vancouver summit
14:02:53 <sgordon> #info ops summit draft schedule @ http://lists.openstack.org/pipermail/openstack-operators/2015-April/006730.html
14:03:06 <sgordon> #info opnfv day @ https://openstacksummitmay2015vancouver.sched.org/event/dbd2188f366a132cd38bd3e3811cb338#.VSUdI-TofCE
14:03:27 <sgordon> i still think we need more definition around goals for telco wg session in vancouver but let's come back to that in a minute
14:05:12 <sgordon> ok
14:05:15 <sgordon> #topic use cases
14:05:22 <sgordon> #link https://review.openstack.org/#/q/status:open+project:stackforge/telcowg-usecases,n,z
14:05:42 <sgordon> #topic use cases - new
14:05:45 <aveiga> ah, we have more reviews to do now
14:05:52 <sgordon> #info Adds Perimeta SBC use case as example of a fast data plane app - Calum Loudon - https://review.openstack.org/#/c/176301/
14:05:58 <sgordon> yes indeedy
14:06:00 <cloudon> Yup, uploaded the SBC one earlier
14:06:09 <sgordon> #topic use cases - existing
14:06:21 <sgordon> #info Add Service Chaining use case - Ralf Trezeciak - https://review.openstack.org/#/c/169201/
14:06:23 <cloudon> slightly tweaked from the wiki version that's been up a while but has now been replaced with pointer to gerrit
14:06:34 <sgordon> #info Adding BGP based IP VPNs attachment use case - Mathieu Rohon - https://review.openstack.org/#/c/171680/
14:06:46 <sgordon> #info Add Virtual IMS Core  use case - Calum Loudon  - https://review.openstack.org/#/c/158997/
14:07:15 <sgordon> #topic use cases - merged
14:07:28 <sgordon> #info Security Segregation (Placement Zones) - http://git.openstack.org/cgit/stackforge/telcowg-usecases/tree/usecases/sec_segregation.rst
14:07:35 <sgordon> so a few thoughts arise from the above
14:07:41 <sgordon> 1) need more reviews
14:07:50 <sgordon> 2) need to define how we expand core review team
14:08:07 <sgordon> 3) need to use security segregation as our guinea pig for defining process from here on out
14:09:48 <cloudon> why 3 in particular?
14:10:02 <sgordon> it's actually merged
14:10:22 <sgordon> if we can agree on one of the others quickly and merge it then that is an alternative
14:10:23 <cloudon> ok, makes sense
14:10:36 <aveiga> and since we need to start looking at how to get from merged usecase to bugs/specs, it will be the first
14:10:40 <sgordon> basically what im talking about is taking the gap/requirements specified in that to the next level
14:10:44 <sgordon> and yeah that
14:11:24 <dneary> Hi
14:11:28 <vkss> hi
14:12:10 <sgordon> so it seems to me we do have at least a couple of people doing reviews per (1)
14:12:24 <sgordon> what i would like to define is how / when we give additional people +2
14:12:33 <sgordon> atm it's just myself, aveiga, mkoderer
14:12:57 <adrian-hoban> I wasn't sure what the protocol is for that
14:13:02 <sgordon> and i don't feel my +2 is particularly meaningful when it comes to the use cases as im more of a facilitator than someone who works in a CSP or NEP directly if that makes sense
14:13:20 <sgordon> im more interested in the wider group being able to manage this
14:13:30 <dneary> sgordon: re reviewers, I can try to get some OPNFV participants involved in reviewing use cases
14:14:05 <sgordon> dneary, please do - see https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Reviewing_Use_Cases for setup info
14:14:09 <dneary> SFC closely matches a couple of the OPNFV projects (VNFFG and SFC)
14:15:43 <dneary> adrian-hoban, Protocol in general is that it requires unanimous agreement from existing +2 reviewers to add someone else
14:16:02 <dneary> Per repo
14:16:08 <aveiga> there are other qualifications as well, but I don't think we can enforce those in good faith
14:16:30 <adrian-hoban> dneary: ok, thanks
14:16:38 <aveiga> we're too new for that
14:16:57 <sgordon> yeah
14:18:07 <sgordon> let's go with that for now
14:18:19 <sgordon> since there are only 3 currently unanimous is a pretty low bar...
14:18:43 <sgordon> #info adding core reviewers requires unanimous agreement from existing cores for now
14:19:00 <sgordon> so on wars to the (3) thing i listed which we touched on
14:19:18 <sgordon> how to take a use case from its current form to a design/implementation
14:19:35 <sgordon> i believe in a previous week we discussed creating bugs under the telcowg LP project
14:19:40 <sgordon> to track each identified gap
14:19:45 <sgordon> and ownership thereof
14:20:31 <sgordon> (looking at http://git.openstack.org/cgit/stackforge/telcowg-usecases/tree/usecases/sec_segregation.rst as i mull this over)
14:21:16 <sgordon> so in this example gaps are primarily around AZ awareness in non-Nova services
14:21:27 <sgordon> (perhaps an oversimplification but what i am seeing)
14:24:36 <adrian-hoban> That, and policy oversight
14:24:56 <sgordon> indeed
14:25:30 <sgordon> so the question i have is who "owns" creating creating trackers for those items initially, use case drafter, wider group, etc.
14:26:05 <sgordon> i think subsequently picking those up and taking action (design, implementation) is a little clearer - anyone who is willing to do the work ;)
14:26:19 <aveiga> sgordon: perhaps the workflow approver?
14:26:44 <adrian-hoban> Is there a step needed to get the use case in front of some core devs/PTLs, so that any future blueprint submissions have some context?
14:27:24 <aveiga> adrian-hoban: are you referring to after bugs get filed with out LP, moving them to the proper OpenStack project?
14:27:30 <aveiga> our*
14:27:33 <matrohon> so a bug should be filled in TecloWG LP project, and it should also affect other concerned project
14:28:02 <adrian-hoban> I was thinking about blueprints more that bugs
14:28:31 <adrian-hoban> I would have thought bugs can be submitted against any of the projects
14:28:37 <aveiga> yeah
14:28:50 <aveiga> we'll need to file specs with other projects for some of this
14:29:18 <sgordon> the bugs against telcowg are more for tracking purposes of this group
14:29:28 <sgordon> who owns liaising with the projects on gap X
14:29:35 <matrohon> then the proposed code wil have the tag : implement-spec, and the tag partially-fix bug #Telco bug#
14:31:01 <adrian-hoban> The logical output from several of the use cases I reviewed are for new blueprints/specs to be submitted against the projects. I guess if these reference back to a Telco-wg approved (merged?) use case then that is sufficient context for the BP reviewers
14:31:38 <aveiga> it will likely be good enough to provide them with a reason why the feature is needed
14:33:09 <sgordon> indeed
14:33:15 <matrohon> What will be missing are implementation details for the project
14:33:44 <aveiga> we'll probably need to work with folks in the projects to get that bit figured out
14:33:46 <sgordon> aveiga, i am warming to your idea of whoever delivered +W ;)
14:33:48 <aveiga> nobody said this would be easy
14:33:52 <sgordon> yeah
14:34:32 <matrohon> but this debate concluded that implementation details might not be provided in a spec (at least for neutron) : http://lists.openstack.org/pipermail/openstack-dev/2015-April/061071.html
14:35:19 <sgordon> im not sure anything was concluded there just yet
14:35:45 <sgordon> but the general feeling expressed was that the balance of what is being implemented versus how it is being implemented in neutron specs i a little off
14:36:49 <matrohon> amuller just sent a conclusion that he expects new ideas to come soon...
14:37:42 <matrohon> I feel we're hitting the main issue here, most of us are able to provide some specs, but few have time to develop
14:38:24 <matrohon> and so to fill a detailled spec, that's exactly what amuller meant in his mail, IMO
14:40:36 <sgordon> from my POV the aim of this group as originally conceived was to assist with advocating for telco/nfv related proposals being pushed into OpenStack - so both the case where somebody is signed up to do the work themselves and where they only have a proposal
14:40:57 <sgordon> where the issue is, is that most projects aren't really interested in evaluating a spec unless there is someone signed up to do the work already
14:41:18 <sgordon> whether that is the original requester or someone else in the community
14:41:24 <aveiga> +1, not having assignees in a spec usually gets it -1'd
14:41:31 <matrohon> +1
14:41:42 <sgordon> (certainly there are some orgs that participate in this group that have developers who can pick up some of these, but that's not going to be possible for all of them)
14:42:22 <sgordon> and i think this is indeed where we have a key challenge
14:42:38 <sgordon> identifying who has the scope/capacity to do such work with us
14:42:44 <sgordon> scope/capacity/will
14:43:00 <matrohon> however, If you look at the BGPVPN UC, it has been proposed since 4 releases to neutron, with developers behind....
14:43:31 <sgordon> cases like that are really where the formation of the group came from
14:43:33 <matrohon> I feel, the main issue where that the UC were not well understood by the community, hope tjis WG will help
14:43:52 <sgordon> examples of proposals that existed, had developers behind them, but werent accepted because the use case wasnt understood
14:43:54 <matrohon> that's the way I see it too, great
14:44:11 <sgordon> this is actually the ideal case for me, as it means that it's a messaging/communication problem
14:44:36 <sgordon> fixing for proposals where it's a resourcing problem is more challenging
14:46:39 <sgordon> ok
14:47:00 <sgordon> #action sgordon to raise telcowg bugs based on security segregation proposal as an example
14:47:29 <sgordon> #action sgordon to draft a proposal for where we would go from there based on this discussion
14:47:53 <sgordon> i think perhaps it's best if i put a draft framework together and we try poke holes in it
14:48:05 <aveiga> that's probably a good idea
14:48:40 <sgordon> i would really like to have this nutted out pre-summit
14:49:59 <sgordon> ok
14:50:27 <sgordon> one last thing, cloudon i think i could do with some help w.r.t. https://review.openstack.org/#/c/158997/
14:50:40 <cloudon> sure - what do you need?
14:50:41 <sgordon> there are some questions there i don't think i can answer since it was originally your use case :)
14:51:03 <sgordon> i have a draft patch with fixes for the stuff i replied done to
14:51:22 <cloudon> ok - happy to look at that for you
14:51:23 <sgordon> but there is a lot more info in your responses beyond that which im not sure how to integrate
14:51:49 <cloudon> ok - want me to suggest mark-ups to you, or just re-submit the use case myself?
14:52:11 <sgordon> i think it might be easier if you pull the current patch there is up there and re-submit yourself
14:52:30 <sgordon> the changes i have locally are only the minor ones (remove template space, blank lines, etc.)
14:52:36 <sgordon> which are easily re-done
14:53:03 <cloudon> ok, will do
14:53:36 <sgordon> thanks for that, sorry
14:54:10 <cloudon> no probs.  After submitting the SBC one I am now gerrit-friendly :)
14:54:38 <sgordon> cool :)
14:54:39 <sgordon> ok
14:54:44 <sgordon> i am going to call it a wrap here
14:54:49 <sgordon> thank you all for your time!
14:54:58 <sgordon> #endmeeting