14:00:17 <sgordon> #startmeeting telcowg
14:00:19 <openstack> Meeting started Wed Nov 11 14:00:17 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:22 <openstack> The meeting name has been set to 'telcowg'
14:00:24 <sgordon> #link https://etherpad.openstack.org/p/nfv-meeting-agenda
14:00:29 <sgordon> #topic roll call
14:00:41 <sgordon> let's see how optimistic it is holding a meeting in the middle of opnfv summit
14:00:51 <sgordon> who is up and about for the telco working group meeting
14:01:07 * sgordon will give it a few mins
14:01:12 <tvvcox> +1
14:01:48 <sgordon> hi cloudon
14:02:20 <sgordon> just waiting to see if we get any more folks
14:02:42 <sgordon> will start in ~ a min
14:03:34 <sgordon> #topic OpenStack Summit working session readout
14:03:41 <sgordon> #link https://etherpad.openstack.org/p/TYO-telcowg
14:03:58 <cloudon> hi there
14:04:07 <sgordon> so we met at openstack summit and broke into groups to discuss primarily:
14:04:14 <sgordon> #info Session Border Controller
14:04:19 <sgordon> #info Adding BGP based IP VPNs attachment use case
14:04:25 <sgordon> #link     https://review.openstack.org/171680
14:04:32 <sgordon> or at least those are the items we have links for ;)
14:04:36 <sgordon> links/notes
14:05:34 <sgordon> cloudon, did you get any useful feedback out of the SBC discussion that influences the use case at all?
14:06:02 <sgordon> i think the primary gripe i heard was what do we mean by high performance
14:06:17 <cloudon> Some useful discussion, but not I think any that fundamentally changes the use case - at least that was my take
14:06:42 <sgordon> right fair enough
14:07:04 <cloudon> yes on high perf gripe, but didn't hear any feasible counter-proposal...
14:07:06 <sgordon> for BGP i think it was roundly similar
14:07:10 <sgordon> in that there is a proposal up
14:07:23 <cloudon> ...somehow combining network streams simply doesn;t fly
14:07:59 <sgordon> :)
14:08:42 <sgordon> #topic Virtual IMS core Complex soft (anti-)affinity policies status
14:08:47 <sgordon> #link https://review.openstack.org/#/c/224325/
14:08:51 <sgordon> so a spanner in the works
14:08:59 <cloudon> go on...
14:09:04 <sgordon> i noticed john had commented on this
14:09:14 <sgordon> "The backlog is not proving as useful as we had hoped, I think we need to look for a better place to record these ideas. Happy to work though that with you."
14:09:29 <sgordon> so as the second person to try and file a backlog spec afaict
14:09:33 <sgordon> that hasnt really worked out
14:09:41 <sgordon> (as a place for recording use cases/ideas)
14:09:47 <sgordon> so i'll need to take that to the mailing list
14:09:49 <cloudon> is there a counter-suggestion?
14:10:00 <sgordon> not yet
14:10:20 <sgordon> #action sgordon to take future of backlog for nova to the -dev list
14:10:25 <sgordon> so some discussion required
14:10:51 <cloudon> ok - pls let me know if I can help
14:10:56 <sgordon> i am not sure if RFE bugs in neutron are faring better?
14:11:03 <cloudon> Not noticeably...
14:11:11 <sgordon> right
14:11:19 <cloudon> ...sat in on two of the weekly neutron driver meetings...
14:11:19 <sgordon> perhaps feeding into the other item on my agenda...
14:11:35 <sgordon> oh yes?
14:11:52 <cloudon> First one got as far as discussing current RFEs then wrapped up 30 mins early without looking at new ones...
14:12:15 <sgordon> second one?
14:12:19 <cloudon> Second slot was the post-summit one but no-one was there (though I may have screwed up DST)
14:12:27 <cloudon> And I couldn't make yesterday's unfortunately
14:12:40 <sgordon> yeah last week was a bit of a crapshoot for that
14:12:53 <sgordon> #topic Future approach
14:12:54 <cloudon> But the status has been changed in a way I'm not sure is positive - let me just check exactly
14:13:00 <sgordon> #info Number of cores taking other roles and stepping down.
14:13:05 <sgordon> #info Lack of quorum (core is now Steve, Daniel, Yuriy once Anthony steps away)
14:13:11 <sgordon> #info Consider pushing use cases into openstack-userstories via product working group
14:13:21 <sgordon> #info Feedback that service providers still want an interface to the community - need to determine if this is it in current form, or should be realigned with the user committee
14:14:07 <cloudon> And get more involvement from OPNFV...
14:14:12 <sgordon> yes
14:14:29 <cloudon> My takeaway from summit was lots of interest in OPNFV...
14:14:41 <sgordon> though some of the service provider feedback is that they dont actually want to engage with opnfv
14:14:43 <sgordon> but anyway....
14:14:59 <cloudon> ...but lots of questions from floor along the lines of "do you know that OpenStack project X is diong Y?" with answer "no"
14:15:02 <sgordon> i am still not sure if that is something that will change with time or not
14:15:10 <sgordon> right
14:15:59 <sgordon> so i am not clear right now on whether we continue to try and meet like this or not
14:16:07 <sgordon> but i do think moving into the user-stories repo would make sense
14:16:38 <cloudon> Agreed.  Very lonely in here at the moment, despit the numbers turning up for the session
14:17:24 <cloudon> What's the remit of the userstories rep as part of the product working group?
14:18:35 <sgordon> pretty similar to this in many ways
14:18:44 <sgordon> let me grab the 'blurb'
14:19:17 <sgordon> We will support the OpenStack developer community in their desire to build open-source cloud software that reflects the needs of the various markets adopting the platform by creating user stories that reflect the voice of the end-users/operators. These user stories will focus on items that have traditionally been harder to implement based on the need for cross-project coordination and significant development time (spanning multiple releases
14:19:17 <sgordon> ). Finally, the team will also focus on sharing regular updates on directional insights for the platform (gathered from key members from the development community) in the form of a multi-release roadmap. The ultimate mission is to create a focus on areas that are high-impact and remove barriers to adoption/operation/scale of OpenStack clouds.
14:19:23 <sgordon> #link https://wiki.openstack.org/wiki/ProductTeam
14:20:23 <cloudon> Very laudable but clause on cross-project co-ord etc. sounds like it's focussed on big-ticket items...
14:20:29 <sgordon> yeahhh
14:20:40 <cloudon> Views on it as a tool to get specific small-ish changes through such as the anti-affinity?
14:20:57 <sgordon> examples are here:
14:20:59 <sgordon> #link http://git.openstack.org/cgit/openstack/openstack-user-stories/tree/user-stories/draft
14:21:12 <sgordon> well, i think anti-affinity is one small part of a large user story
14:21:15 <sgordon> if that makes sense?
14:21:53 <sgordon> i do need to broach this with the product wg
14:22:18 <sgordon> and there is also some discussion about whether the user committee might be the right place for that direct CSP engagement
14:22:29 <sgordon> allowing us perhaps to focus more on the opnfv side...
14:22:34 <sgordon> (and technical in general)
14:22:35 <cloudon> Agreed - but in that case I think the large story is "user <X> wants to run highly reliable N+k apps" for lots of X - and there's relatively little missing
14:24:29 <sgordon> yeah
14:24:35 <cloudon> I think we probably have needs at multiple levels...
14:24:49 <sgordon> tbh for that specific example i think it's a matter of having that info in front of the nova folks for if/when server groups gets reworked
14:25:03 <sgordon> but i do wonder if there are also e.g. cinder implications we havent really considered
14:25:13 <sgordon> (at least so far)
14:26:01 <cloudon> Looking at NFV as a whole and asking "what gaps do we have that make OpenStack currently unsuitable?", there are some big pieces missing (e.g. orchn) which the OPNFV folks tend to be looking at, plus some relatively-speaking very detailed things (anti-affinity, NUMA, DPDK OVS etc.)
14:26:23 <sgordon> cloudon, i thought orchestration was actually out of scope for opnfv
14:26:24 <cloudon> Not sure a single process is suitable for both
14:26:25 <sgordon> or has that changed
14:26:29 <sgordon> (at least for now)
14:26:42 <cloudon> Well, MANO was out of scope, then tacker started...
14:27:57 <cloudon> You're right on cinder, I think - general issue to do with having matching (anti)affinity at compute and storage levels - also crops up in my "efficiently running NoSQL" use case
14:29:43 <cloudon> The advantage of this group from my perspective is that it allowed for people without existing project standing to propose realtively small tweaks and get help explaining and justifying them
14:29:46 <wznoinsk> hi sgordon cloudon, i'm only new to the MANO in openstack subject but as far as I can say the IETF ISG NFV diagram everbody (probably) knows doesn't imply MANO component has to be separate from the other components (like VIM) - Tacker, firstly not anticipated MANO in Openstack, may work well if done well
14:30:31 <sgordon> im not saying it has to be separate so much as has been out of scope of say opnfv
14:30:49 <sgordon> i know tacker exists but is that opnfv driven, or something that folks who happen to also be in opnfv drove
14:30:53 <cloudon> Hi wznoinsk - correct on the NFV picture, but when OPNFV started up they drew a ring around the NFVI and said "that's us"
14:30:58 <wznoinsk> cloudon: btw. NUMA and DPDK OVS are working in Openstack, unless you have some specific example which may not be covered yet
14:30:58 <sgordon> because orchestration wasnt in scope of opnfv
14:31:21 <sgordon> it was actually one of the biggest complaints in paris from some in the room that orchestration wasnt in scope for opnfv at the time
14:31:35 <wznoinsk> sgordon: I see
14:31:44 <sgordon> wznoinsk, plenty of work to do wrt NUMA yet
14:31:51 <sgordon> e.g ok we have SR-IOV numa locality
14:31:58 <sgordon> what about vswitch locality
14:31:58 <cloudon> Bit hazy on the timeline, but I think tacker started in OPNFV, has transitioned to OpenStack but is now largely driven by OPNFV folk stil
14:32:57 <wznoinsk> cloudon: that's what I think as well, it doesn't necessary mean a bad thing I guess, maybe even a good one if it comes to adoption (it's backed by OPNFV so some may like it more)
14:34:24 <wznoinsk> sgordon: do you mean having ovs+dpdk on the same numa node as dpdk's pmd or else?
14:34:37 <sgordon> same node as the guest
14:34:51 <sgordon> also thread policy isnt done yet either for that matter
14:36:16 <wznoinsk> isn't it a scalability issue if you have 8 numa nodes? I guess you mean the 'preferred' rather than 'strict'
14:36:19 <cloudon> Agreed.  Broader point though IMO is that for bigger higher-up-the-stack gaps like orchn mechanisms exist for people to launch whole new projects if necessary; doesn't apply to getting the small but necessary changes through existing projects
14:36:47 <sgordon> wznoinsk, why 8
14:36:48 <cloudon> i.e. mechanisms exist for those, it's raelly how best to grease the wheels
14:36:55 <wznoinsk> sgordon: I think the cpu thread policy which is in review (didn't make it in Liberty) is a prereq for that?
14:36:58 <sgordon> wznoinsk, same problem exists with any number > 1
14:38:07 <wznoinsk> sgordon: I think there are platform that could have that many numa nodes, IBMs I think - I'll try to find exactly what it was
14:39:10 <wznoinsk> sgordon: yes, with > 1 too, I never thought about vswitch <> numa locality, interesting
14:40:06 <sgordon> it's only really come up recently
14:40:18 <sgordon> once people started testing more ;)
14:40:32 <sgordon> i dont really have a proposed solution for that :)
14:40:32 <cloudon> apologies - fire alarm here...
14:40:35 <sgordon> np
14:40:38 <sgordon> im going to call it for now
14:40:46 <sgordon> i think we will need to continue this discussion though
14:40:59 <sgordon> i am also interested in daniel schab's thoughts as the other remaining core
14:41:54 <wznoinsk> sgordon: I'm interested in that as well, a bit concerned about the rest of the guests on the other numas
14:42:55 <sgordon> right
14:43:08 <sgordon> you cant give everyone vswitch locality
14:43:24 <sgordon> (not without leaving capacity on the table anyway)
14:43:36 <sgordon> anyway, i will close the meeting for now
14:43:59 <sgordon> i am interested to hear what comes out of both opnfv summit and the user committee discussions going on atm to help guide where we go from here
14:44:01 <sgordon> #endmeeting