14:01:09 <sgordon> #startmeeting telcowg
14:01:10 <openstack> Meeting started Wed Aug 12 14:01:09 2015 UTC and is due to finish in 60 minutes.  The chair is sgordon. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:14 <openstack> The meeting name has been set to 'telcowg'
14:01:20 <sgordon> #link https://etherpad.openstack.org/p/nfv-meeting-agenda
14:01:25 <sgordon> #topic roll call
14:01:29 <aveiga> hello
14:01:34 <adrian-hoban> Hi
14:01:35 <sgordon> who's up and about
14:01:44 <cloudon> hi
14:01:47 <sgordon> \o/
14:02:07 <sgordon> #topic operators mid-cycle
14:02:16 <sgordon> just a reminder it's next week, no formal telcowg session
14:02:20 <jaypipes> morning all
14:02:28 <sgordon> additionally the product wg mid-cycle is next week as well
14:02:41 <sgordon> i have been talking with them about how we work together to avoid duplication...
14:04:08 <sgordon> #topic tokyo
14:04:28 <sgordon> i got an email from the organizers for tokyo, rooms for working groups are now available for signup
14:04:37 <sgordon> needs to be complete by august 24th
14:04:46 <jaypipes> sgordon: you have a link to the product-wg mid-cycle information?
14:04:52 <sgordon> #info working group rooms for tokyo available, need to be booked by 24th
14:05:02 <sgordon> jaypipes, sure let me grab it - it will also be in the bay area
14:05:08 <jaypipes> sgordon: cheers
14:05:40 <sgordon> #link https://wiki.openstack.org/wiki/Sprints/Product_WGLibertySprint
14:05:42 <sgordon> jaypipes, ^
14:06:05 <sgordon> i wont actually be there as i am going to linuxcon/kvm forum next week but most of the other members of that wg will be
14:06:50 <sgordon> w.r.t. tokyo i guess the question at this stage is do we need/want a F2F and what are our goals
14:07:10 <sgordon> the room sizes available are 30, 80, ~160 or ~250 in size
14:07:16 <sgordon> i suspect based on last time 30 would be enough
14:07:31 <sgordon> and then the other question is 1 40 min block or 2 but that needs to be goal driven
14:07:38 <jaypipes> sgordon: ty sir.
14:07:52 <sgordon> so for now i will just state the above as for informational purposes
14:08:02 <sgordon> need to think about this and nail it down over the next week or so
14:08:31 <sgordon> how we work with the productwg is also a key point in whether we need a dedicated session or not
14:08:52 <sgordon> their current thinking is that they would act as a funnel for use cases from the working groups (telco, wte, etc.)
14:09:05 <adrian-hoban> How many sessions will the productwg get?
14:09:25 <sgordon> to the project teams - how this will work in practice versus us filing backlog specs or RFEs directly is another question
14:09:36 <sgordon> adrian-hoban, unclear - i would expect them to ask for 2 x 40
14:09:40 <aveiga> sgordon: I think we could do with a single session this time, since we've done into/work process twice now
14:09:46 <sgordon> aveiga, yeah
14:09:55 <aveiga> might be better to just do working sessions
14:10:02 <sgordon> aveiga, i also think as it's compressed into 4 days people's time will be even more pressed than usual
14:10:19 <sgordon> aveiga, so getting people's attention for 2 slots might be challenging
14:10:21 <aveiga> yeah, that's not going to help
14:10:54 <sgordon> #info currently thinking 1 x 40 min session in a 30 person room as a focused working session
14:11:17 <sgordon> #action sgordon to block a slot with the organizers
14:14:40 <sgordon> #topic open reviews
14:15:18 <sgordon> #link https://review.openstack.org/#/q/status:open+project:stackforge/telcowg-usecases,n,z
14:17:50 <sgordon> ok
14:18:01 <sgordon> so the workflow patch
14:18:06 <sgordon> #link https://review.openstack.org/#/c/178347/
14:18:07 <adrian-hoban_> Do you guys think we're close to closing these reviews? Seem to be going for quite a while...
14:18:20 <sgordon> yeah it's an issue
14:18:28 <sgordon> one of the things was we only actually had three cores
14:18:30 <sgordon> we now have 5
14:18:43 <sgordon> also some adrian-hoban_ hoban guy keeps -1'ing my patches
14:18:44 <sgordon> ;p
14:19:11 <adrian-hoban_> ;-)
14:19:16 <sgordon> atm
14:19:27 <sgordon> we have the two workflow related patches which i had to iterate in the last week or so
14:19:32 <sgordon> 4 use cases with a -1
14:19:40 <sgordon> and the SBC use case which could probably be merged?
14:19:53 <sgordon> #link https://review.openstack.org/#/c/176301/
14:20:22 <adrian-hoban_> +1 on the SBC
14:20:24 <cloudon> On SBC one, just back form hols and need some help from Mark with some git commit voodoo before it can be merged
14:20:46 <aveiga> cloudon: did you do the dance? you have to do the dance
14:21:12 <adrian-hoban_> And put it on youtube
14:21:22 <cloudon> Did the dance.  Started raining.  But didn't merge.
14:23:45 <cloudon> Correction: that's the IMS one I was talking about.  SBC one has some good comments from Yuri I need to patch to address - mostly clarifying some terms though
14:24:12 <adrian-hoban_> A couple of weeks ago we mentioned the possibility of the BGP use case being a RFE candidate, with the affinity gap and IMS use cases good for backlog
14:24:44 <adrian-hoban_> Is it worth completing the reviews here if we agree to move forward with the other processes?
14:25:16 <adrian-hoban_> Use the current set of comments to refine the initial RFE/backlog submission drafts...
14:25:29 <aveiga> that's a good question
14:25:40 <aveiga> I think we should continue current workflow until/if we switch
14:27:18 <sgordon> yeah
14:27:19 <adrian-hoban_> aveiga: ok. Fair point. Should we switch sometime in Sept, so that we have some time to try these other methods, and have a greater chance of having the proposed changes discussed in design sessions?
14:27:21 <sgordon> i agree
14:27:46 <sgordon> i think we should proceed to try and turn it into RFEs/backlogs
14:27:51 <aveiga> it's up to sgordon and how far along he thinks the productwg is
14:28:03 <sgordon> it may also tie in neatly with a spec jaypipes has up around fixing/replacing server groups
14:28:07 <sgordon> aveiga, i think it's too early
14:28:12 <aveiga> oik
14:29:12 <cloudon> Given that is there any point converting existing use cases into the revised template format?
14:29:49 <sgordon> our revised format or productwg one
14:29:50 <sgordon> lol
14:29:51 <sgordon> :)
14:30:13 <cloudon> take your pick :)
14:30:19 <sgordon> #info Use BGP use case as a "guinea pig", turn into RFEs/backlog
14:30:29 <sgordon> i think we just use the template as it exists in telcowg repo
14:30:32 <sgordon> for now
14:31:43 <adrian-hoban_> Also consider the Affinity gap from the IMS use case for a Nova backlog item
14:33:57 <sgordon> right
14:33:59 <sgordon> soirry
14:34:05 <sgordon> #info Also consider the Affinity gap from the IMS use case for a Nova backlog item
14:34:50 <sgordon> so we need minor iteration on each of these and to merge them
14:35:00 <sgordon> and then a lucky volunteer or two to actually create the backlog items
14:35:47 <adrian-hoban_> Looks like the end to end workflow and optional template extensions are ready for approval too?
14:36:03 <sgordon> yeah i think so
14:36:13 <sgordon> i had a minor validation issue on those workflow updates
14:36:14 <sgordon> fixed now
14:36:26 <sgordon> im biased tho since i proposed them
14:36:30 <cloudon> I'll have a stab at the affinity gap one
14:38:53 <adrian-hoban_> Should we chat about the other three then?
14:39:17 <adrian-hoban_> SFC, VNF Bringup, and BGP
14:39:51 <sgordon> sure
14:40:22 <sgordon> #topic use case reviews - SFC
14:40:30 <sgordon> #link https://review.openstack.org/169201
14:40:49 <sgordon> sooo
14:40:55 <sgordon> this hasn't been touched in a while
14:41:10 <sgordon> where a while is like 2 weeks so not terrible
14:41:11 <sgordon> :)
14:41:16 <sgordon> but a lot of feedback to action
14:42:07 <adrian-hoban_> Lots of interesting items in this, but... I'm not sure we really need a dedicated Telco SFC item, or if we do, I'd recommend a brief one that only touches on gaps
14:42:16 <adrian-hoban_> SFC is getting lots of attention elsewhere
14:42:41 <adrian-hoban_> Possibly more effective to join those conversations
14:47:43 <sgordon> yeah
14:47:52 <sgordon> i think that is a fair comment
14:47:57 <sgordon> unsure how e.g. tacker relates
14:48:04 <sgordon> is that THE place to discuss this?
14:49:18 <sgordon> #info SFC conversation may need to be briefer and / or discussion moved to broader group
14:50:10 <adrian-hoban_> AFAIK, Tacker is being developed now as a proposed VNF manager. I was thinking of the SFC conversations related to this bug https://bugs.launchpad.net/neutron/+bug/1460222 and the networking-sfc project
14:50:10 <openstack> Launchpad bug 1460222 in neutron "Add 'labels', a list of opaque strings, to the neutron 'port' object" [Undecided,Won't fix]
14:50:11 <uvirtbot> Launchpad bug 1460222 in neutron "Add 'labels', a list of opaque strings, to the neutron 'port' object" [Undecided,Won't fix]
14:50:12 <uvirtbot> Launchpad bug 1460222 in neutron "Add 'labels', a list of opaque strings, to the neutron 'port' object" [Undecided,Won't fix] https://launchpad.net/bugs/1460222
14:50:38 <sgordon> #link https://bugs.launchpad.net/neutron/+bug/1460222
14:50:54 <sgordon> #link https://github.com/openstack/networking-sfc
14:51:10 <sgordon> ok
14:51:15 <sgordon> move on to the next one?
14:52:00 <adrian-hoban_> VNF Bring Up?
14:52:02 <sgordon> #topic use case reviews - Add initial VNF bring-up usecase
14:52:08 <sgordon> #link https://review.openstack.org/190080
14:52:13 <adrian-hoban_> https://review.openstack.org/#/c/190080/
14:54:55 <adrian-hoban_> Another spec with lots of good info, but IMO strays a bit from requirements into specifying implementation details. E.g. All VNFs should use cloud-init
14:55:40 <cloudon> Agree.  More a list of things VNFs should do (some questionable) than what we need from the cloud.
14:56:40 <sgordon> i guess the question is, is something of value salvageable from what is there so far?
14:58:32 <cloudon> think there are some gaps that manifest in VM instantiation which this touches on e.g. NIC metadata, being address in https://blueprints.launchpad.net/nova/+spec/metadata-service-network-info
14:59:12 <sgordon> #link https://blueprints.launchpad.net/nova/+spec/metadata-service-network-info
14:59:33 <sgordon> #info question of whether some gaps manifesting in VM instantiation are addressed by this BP
14:59:40 <adrian-hoban_> It's a great topic, as long as the write up focuses on OpenStack gaps rather than VNF requirements
15:00:02 <sgordon> #info Topic is relevant but needs to focus on openstack gaps rather than requirements for VNFs themselves
15:00:51 <sgordon> ok
15:00:57 <sgordon> looks like we are at the hour
15:01:06 <sgordon> we can move to #openstack-nfv if we want to discuss further
15:01:10 <sgordon> apologies
15:01:13 <sgordon> thanks all for your time
15:01:16 <sgordon> #endmeeting