14:00:25 <sgordon> #startmeeting telcowg
14:00:26 <openstack> Meeting started Wed Jul 29 14:00:25 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:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:30 <openstack> The meeting name has been set to 'telcowg'
14:00:32 <sgordon> #link https://etherpad.openstack.org/p/nfv-meeting-agenda
14:00:36 <sgordon> #topic roll call
14:00:43 <adrian-hoban> Hello
14:00:47 <sgordon> who is about to talk telco?
14:01:23 <adrian-hoban> Love talking telco ;-)
14:01:28 <aveiga> hello
14:01:59 <sgordon> aight
14:02:09 <sgordon> couple of quick things before we get into the meat of it
14:02:12 <ralfT> hi
14:02:15 <sgordon> #info Added Daniel Schabarum and Yuriy Babenko as telcowg-usecases cores
14:02:25 <DaSchab> hi
14:02:37 <sgordon> after the discussion in last week's meeting and no negative feedback to the proposal on the list i added those two to core
14:02:39 <adrian-hoban> Congrats guys
14:02:45 <DaSchab> thx
14:02:49 <sgordon> #info Moving telcowg-usecases under User Committee in openstack/ namespace
14:02:59 <sgordon> we discussed this last week as well but didn't have quorum
14:03:15 <sgordon> it kind of blends into the next topic which aveiga had raised previously in regards to workflow
14:03:31 <sgordon> which is to say that it feels like we're on the treadmill somewhat
14:03:52 <sgordon> in terms of the workflow itself (https://review.openstack.org/#/c/178347/) and the use case work
14:04:11 <sgordon> in particular a couple of new things have come up since we started talking about this process
14:04:21 <sgordon> primarily the "rfe" process in neutron and backlog specs in nova
14:04:55 <sgordon> and also the use case process the product working group are putting together
14:05:25 <sgordon> (the working theory there being that working groups like this one would be feeding into the product working group though it seems there is a desire for even more abstract use cases at that level)
14:05:34 <sgordon> EOF
14:05:56 <adrian-hoban> Do those topics only affect the workflow after line 134?
14:06:28 <adrian-hoban> i.e. what to do once the use case is agreed to?
14:06:31 <aveiga> adrian-hoban: that depends on how we decide to scope it
14:06:39 <mkoderer> hi folks
14:07:11 <sgordon> adrian-hoban, that's what im trying to ascertain
14:07:11 <aveiga> if the user committee for some reason became the use case depot and the rfe/backlog became implementation, it could conceivably be all of it
14:07:47 <aveiga> but yes, it's mostly the bug/spec sections (i.e. post-analysis actions)
14:08:41 <sgordon> right
14:08:56 <sgordon> it at the very least can simplify that part of it
14:09:46 <mkoderer> sgordon: aveiga asked me about my opinon to get rid of the telco-usecase repo
14:09:57 <mkoderer> is it the same topic?
14:10:09 <aveiga> mkoderer: yes, but a chat about degrees
14:10:45 <aveiga> I'm trying to understand what the point of continuing is if we have multiple, broader community efforts to do the same thing we do but not be telco-specific
14:11:01 <aveiga> if they already exist and fully overlap, then it's a matter of getting a telco glossary to those groups
14:11:11 <aveiga> if they don't overlap, then we need to provide coverage
14:11:17 <sgordon> there is also a level of detail issue, do the backlog specs for example need more or less detail than we're capturing
14:11:49 <mkoderer> aveiga: anything that brings us closer to the dev community is a good thing
14:11:52 <sgordon> seems like we are spinning our wheels on some of these trying to come up with the perfect use case definition in isolation
14:12:00 <sgordon> versus getting it in front of the dev community and iterating
14:12:04 <aveiga> +1
14:12:33 <mkoderer> sgordon: +1
14:13:07 <ybabenko> sgordon: what must happen to be "in front of dev com"?
14:13:26 <sgordon> ybabenko, rfe or backlog spec in the relevant project in this case i think
14:13:44 <mkoderer> ybabenko: we need to involve them... and this happends if we start open design specs
14:13:49 <DaSchab> than we need more details in our use cases, right?
14:13:55 <sgordon> ybabenko, obviously everything is happening in the open but that doesnt mean there are a huge number of devs reviewing our repo
14:14:03 <sgordon> certainly there are some but not many
14:14:25 <ybabenko> is not openstack summit a good platform to kick this?
14:14:29 <ybabenko> if not then what?
14:14:57 <sgordon> not really to be honest
14:15:10 <sgordon> invariably any sessions we have at summit clashes with the dev tracks
14:15:22 <adrian-hoban_> Are the RFE and backlog specs expected to be more detailed than the use case level we've mostly been focusing on?
14:15:23 <sgordon> and besides stagnating for 4 months doesnt seem like a good plan
14:15:23 <mkoderer> ybabenko: getting a design slot at the summit need already many technical details
14:16:55 <DaSchab> how should we proceed?
14:17:05 <aveiga> adrian-hoban_: from what I can tell, the RFE is about the same detail
14:17:16 <aveiga> it doesn't require a proposed implementation like specs do
14:17:22 <mkoderer> DaSchab: we should focues on use-cases that we already have and try to get them implemented
14:17:38 <sgordon> aveiga, right and my impression is the nova backlog spec is similar
14:17:49 <sgordon> you dont need an implementation plan so much as a problem statement
14:17:55 <mkoderer> we could work on spec for our placement zone use case... shouldn't be that hard to create specs out of it
14:18:06 <DaSchab> what must be the level of detail? more or less?
14:18:16 <DaSchab> I assume more
14:18:26 <mkoderer> DaSchab: http://specs.openstack.org/
14:18:29 <aveiga> DaSchab: nope, it's the same
14:18:36 <aveiga> oh, if you mean specs, it's more
14:19:49 <mkoderer> aveiga: do you have a example for an RFE?
14:19:55 <adrian-hoban_> aveiga: sgordon: Thanks. Both RFE and backlog specs as I understand it are intended to focus on features rather than use cases. Early feedback on some asks coming from Telco community centered on a lack of info on why the telco folks were asking for particular items which is why we started this use case initiative
14:20:15 <aveiga> mkoderer: let me get one for you
14:20:37 <aveiga> adrian-hoban_: right, and that is what the User Committee was created to address
14:20:49 <mkoderer> aveiga: are they tracked in launchpad in the bugtracker?
14:21:00 <aveiga> mkoderer: yes, RFEs begin as a bug
14:21:05 <ybabenko> I mean we have at least two very critical use-cases which a lot of folks need: placement zones and sfc ... the question is not how to attract rigth people to these
14:21:25 <mkoderer> aveiga: ok so linking an RFE to a telco use-case is easy then
14:21:53 <aveiga> yes
14:21:58 <sgordon> yes
14:22:13 <aveiga> here's an RFE my team submitted: https://bugs.launchpad.net/neutron/+bug/1468353
14:22:14 <openstack> Launchpad bug 1468353 in neutron "QoS DSCP marking rule support" [Undecided,In progress] - Assigned to James Reeves (james-reeves5546)
14:22:14 <uvirtbot> Launchpad bug 1468353 in neutron "QoS DSCP marking rule support" [Undecided,In progress]
14:22:15 <uvirtbot> Launchpad bug 1468353 in neutron "QoS DSCP marking rule support" [Undecided,In progress] https://launchpad.net/bugs/1468353
14:23:06 <adrian-hoban_> ybabenko: On the SFC case, there is already lots of attention happening. From a telco use case perspective, I don't think a gap in the current work items has been clearly identified in the use case spec yet.
14:23:39 <aveiga> there's actually a subteam on SFC
14:23:54 <aveiga> it seems to me that one was big enough that our use cases definition won't cut it
14:23:58 <sgordon> aveiga, mmm - that does seem to get into implementation a little no?
14:24:14 <aveiga> sgordon: only because we already had an implementation discussed from Vancouver
14:24:22 <sgordon> fair enough
14:26:21 <ralfT> I'm in contact with Cathy on the SFC topic
14:26:41 * mkoderer dislikes launchpad as bug tracker :)
14:27:02 <adrian-hoban_> Rather than debate the SFC use case here too much (yet), more generally are you thinking that our use cases with a focus on what is needed, why it is needed, and known gaps, would get more developer attention under the user groups?
14:27:31 <adrian-hoban_> And allow a shorter path to detailed discussions on those gaps?
14:29:19 <sgordon> adrian-hoban_, im concerned that at the moment we're back to primarily circulating them within this team searching for perfection
14:29:27 <sgordon> and not getting that external discussion
14:30:03 <adrian-hoban_> sgordon: +1
14:30:09 <DaSchab> +1
14:30:24 <adrian-hoban_> Would a new home help?
14:30:31 <aveiga> we have to get some kind of ask in front of each project or there won't be progress
14:31:41 <adrian-hoban_> aveiga: +1. I thought the use case was to help define what that ask would be.
14:31:53 <DaSchab> would it help to have our merged use cases visible and integrated on a website instead of rst?
14:32:07 <sgordon> well there's kind of a "new home" question anyway, in that i do need to move the repo to openstack/ regardless
14:32:17 <sgordon> but separately it caused us to question the workflow
14:32:42 <aveiga> adrian-hoban_: to sgordon's point, we have to move.  If we're moving, why not end up where the other user-originated use cases are?
14:33:59 <adrian-hoban_> aveiga: I'm fully supportive of any move that makes things run smoother. Just trying to understand how/where that is...
14:35:01 <adrian-hoban_> Can someone share a pointer to other user originated use cases?
14:36:10 <sgordon> http://specs.openstack.org/openstack/nova-specs/specs/backlog/
14:36:30 <sgordon> aveiga, is there a link somewhere for the rfe process other than kyle's blog
14:36:38 <sgordon> #link http://specs.openstack.org/openstack/nova-specs/specs/backlog/
14:36:43 <sgordon> #link http://www.siliconloons.com/posts/2015-06-01-new-neutron-rfe-process/
14:37:07 <aveiga> sgordon: I'd ask him, but he's not online
14:37:10 <aveiga> I'd sure hope so
14:37:16 <sgordon> #info discussing need to move from stackforge and whether process can take advantage of backlog specs/rfes/productwg
14:37:43 <sgordon> #link https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst
14:37:56 <sgordon> aveiga, that looks to be it in the repo itself
14:37:58 <aveiga> http://docs.openstack.org/developer/neutron/policies/blueprints.html
14:38:05 <aveiga> it's a subheading in there
14:38:06 <sgordon> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=rfe
14:38:14 <sgordon> #link http://docs.openstack.org/developer/neutron/policies/blueprints.html
14:38:29 <sgordon> you get a link, and you get a link, and YOU get a link
14:38:41 <aveiga> sgordon: href Oprah
14:39:40 <adrian-hoban_> The template in the backlog spec does have a section for the use case. That could hold some (all?) of the info we've been capturing
14:40:31 <aveiga> adrian-hoban_: yup, it just means we have to duplicate use-case docs if the gaps are cross-project
14:40:31 <sgordon> right
14:40:55 <sgordon> for those cases do we duplicate or advocate for some handling of that in the cross-project specs repo
14:41:07 <sgordon> i know its target so far has been specs that touch *everything* tho
14:41:16 <aveiga> sgordon: advocate linking to it from the backlog item
14:41:36 <adrian-hoban_> But a user submitting it may not be able to fill in some of the more detailed sections such as Data Model Impact. Perhaps it would be ok to have blank sections and ask for dev support in filling those in... That could help address the problem statement driving this discussion
14:42:42 <sgordon> adrian-hoban_, i want to raise that bit on list actually
14:42:54 <sgordon> adrian-hoban_, i dont really see how that is appropriate for the stated intent of a backlog spec
14:43:02 <aveiga> +1
14:43:04 <sgordon> adrian-hoban_, unless it's meant to be optional
14:43:10 <sgordon> but that isnt made clear currently
14:43:11 <ybabenko> so who will lead this effort
14:43:23 <ybabenko> sgordon: is it you who can push for the move?
14:43:35 <sgordon> #action sgordon to provide feedback on nova backlog spec template on list
14:44:32 <adrian-hoban_> sgordon: aveiga: What I meant was that if our existing use case repo goes away, and we want to drive a Nova related change, we could start submitting a nova backlog spec and ask in the nova dev community for help in completing that spec
14:45:18 <adrian-hoban_> From the backlog spec page: "These specifications have the problem description completed, but all other sections are optional"
14:46:23 <sgordon> ah right
14:46:30 <sgordon> #undo
14:46:30 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0xadecc90>
14:47:35 <sgordon> #action sgordon to update workflow draft to see how it would look leveraging backlog specs/rfes
14:47:55 <sgordon> it would also be great if a lucky volunteer could identify one of the existing use cases to try this out with
14:50:35 <sgordon> crickets.. ;)
14:50:36 <sgordon> ok
14:51:09 <sgordon> #topic other business
14:51:15 <sgordon> that was the main thing i wanted to discuss
14:51:24 <sgordon> so let me reframe the workflow doc and see how we feel
14:51:42 <sgordon> on a different tangent
14:51:49 <adrian-hoban_> I'm after reviewing all of the use cases that are listed. The BGP VPN use case (https://review.openstack.org/#/c/171680/) might be a good candiate for RFE, and the Affinity gap from the virtual IMS use case (https://review.openstack.org/#/c/179142/) could be good for the backlog...
14:51:53 <sgordon> i am traveling next week during the meeting
14:52:19 <sgordon> #info The BGP VPN use case (https://review.openstack.org/#/c/171680/) might be a good candiate for RFE, and the Affinity gap from the virtual IMS use case (https://review.openstack.org/#/c/179142/) could be good for the backlog
14:52:36 <ybabenko> sgordon: I suggest to go for placement zones as this is a straigforward use-case
14:52:56 <sgordon> ybabenko, do you think you might be able to frame a backlog spec around this?
14:53:09 <mkoderer> sgordon: should be possible
14:53:09 <adrian-hoban_> ybabenko: +1
14:53:16 <DaSchab> +1
14:53:23 <ybabenko> sgordon: frankly, I have no idea what baclog spec is
14:53:42 <mkoderer> ybabenko: :) no worries
14:53:55 <ybabenko> sgordon: but can try my best if you give me some support
14:54:02 <adrian-hoban_> ybabenko: Check this link out: http://specs.openstack.org/openstack/nova-specs/specs/backlog/
14:54:37 <sgordon> ybabenko, you are the perfect guinea pig then!
14:54:38 <ybabenko> adrian-hoban_: thx
14:54:58 <sgordon> the idea is actually supposed to be that someone shouldnt need to understand nova process too much to submit one
14:55:07 <sgordon> so if that's not the case then we can suggest changes
14:56:33 <sgordon> any takers to run next week's meeting?
14:59:20 <sgordon> ok i will follow up on m/l
14:59:26 <sgordon> thanks all, we are at the time limit :)
14:59:29 <sgordon> #endmeeting