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