14:00:17 #startmeeting telcowg 14:00:19 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:22 The meeting name has been set to 'telcowg' 14:00:24 #link https://etherpad.openstack.org/p/nfv-meeting-agenda 14:00:29 #topic roll call 14:00:41 let's see how optimistic it is holding a meeting in the middle of opnfv summit 14:00:51 who is up and about for the telco working group meeting 14:01:07 * sgordon will give it a few mins 14:01:12 +1 14:01:48 hi cloudon 14:02:20 just waiting to see if we get any more folks 14:02:42 will start in ~ a min 14:03:34 #topic OpenStack Summit working session readout 14:03:41 #link https://etherpad.openstack.org/p/TYO-telcowg 14:03:58 hi there 14:04:07 so we met at openstack summit and broke into groups to discuss primarily: 14:04:14 #info Session Border Controller 14:04:19 #info Adding BGP based IP VPNs attachment use case 14:04:25 #link https://review.openstack.org/171680 14:04:32 or at least those are the items we have links for ;) 14:04:36 links/notes 14:05:34 cloudon, did you get any useful feedback out of the SBC discussion that influences the use case at all? 14:06:02 i think the primary gripe i heard was what do we mean by high performance 14:06:17 Some useful discussion, but not I think any that fundamentally changes the use case - at least that was my take 14:06:42 right fair enough 14:07:04 yes on high perf gripe, but didn't hear any feasible counter-proposal... 14:07:06 for BGP i think it was roundly similar 14:07:10 in that there is a proposal up 14:07:23 ...somehow combining network streams simply doesn;t fly 14:07:59 :) 14:08:42 #topic Virtual IMS core Complex soft (anti-)affinity policies status 14:08:47 #link https://review.openstack.org/#/c/224325/ 14:08:51 so a spanner in the works 14:08:59 go on... 14:09:04 i noticed john had commented on this 14:09:14 "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 so as the second person to try and file a backlog spec afaict 14:09:33 that hasnt really worked out 14:09:41 (as a place for recording use cases/ideas) 14:09:47 so i'll need to take that to the mailing list 14:09:49 is there a counter-suggestion? 14:10:00 not yet 14:10:20 #action sgordon to take future of backlog for nova to the -dev list 14:10:25 so some discussion required 14:10:51 ok - pls let me know if I can help 14:10:56 i am not sure if RFE bugs in neutron are faring better? 14:11:03 Not noticeably... 14:11:11 right 14:11:19 ...sat in on two of the weekly neutron driver meetings... 14:11:19 perhaps feeding into the other item on my agenda... 14:11:35 oh yes? 14:11:52 First one got as far as discussing current RFEs then wrapped up 30 mins early without looking at new ones... 14:12:15 second one? 14:12:19 Second slot was the post-summit one but no-one was there (though I may have screwed up DST) 14:12:27 And I couldn't make yesterday's unfortunately 14:12:40 yeah last week was a bit of a crapshoot for that 14:12:53 #topic Future approach 14:12:54 But the status has been changed in a way I'm not sure is positive - let me just check exactly 14:13:00 #info Number of cores taking other roles and stepping down. 14:13:05 #info Lack of quorum (core is now Steve, Daniel, Yuriy once Anthony steps away) 14:13:11 #info Consider pushing use cases into openstack-userstories via product working group 14:13:21 #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 And get more involvement from OPNFV... 14:14:12 yes 14:14:29 My takeaway from summit was lots of interest in OPNFV... 14:14:41 though some of the service provider feedback is that they dont actually want to engage with opnfv 14:14:43 but anyway.... 14:14:59 ...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 i am still not sure if that is something that will change with time or not 14:15:10 right 14:15:59 so i am not clear right now on whether we continue to try and meet like this or not 14:16:07 but i do think moving into the user-stories repo would make sense 14:16:38 Agreed. Very lonely in here at the moment, despit the numbers turning up for the session 14:17:24 What's the remit of the userstories rep as part of the product working group? 14:18:35 pretty similar to this in many ways 14:18:44 let me grab the 'blurb' 14:19:17 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 ). 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 #link https://wiki.openstack.org/wiki/ProductTeam 14:20:23 Very laudable but clause on cross-project co-ord etc. sounds like it's focussed on big-ticket items... 14:20:29 yeahhh 14:20:40 Views on it as a tool to get specific small-ish changes through such as the anti-affinity? 14:20:57 examples are here: 14:20:59 #link http://git.openstack.org/cgit/openstack/openstack-user-stories/tree/user-stories/draft 14:21:12 well, i think anti-affinity is one small part of a large user story 14:21:15 if that makes sense? 14:21:53 i do need to broach this with the product wg 14:22:18 and there is also some discussion about whether the user committee might be the right place for that direct CSP engagement 14:22:29 allowing us perhaps to focus more on the opnfv side... 14:22:34 (and technical in general) 14:22:35 Agreed - but in that case I think the large story is "user wants to run highly reliable N+k apps" for lots of X - and there's relatively little missing 14:24:29 yeah 14:24:35 I think we probably have needs at multiple levels... 14:24:49 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 but i do wonder if there are also e.g. cinder implications we havent really considered 14:25:13 (at least so far) 14:26:01 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 cloudon, i thought orchestration was actually out of scope for opnfv 14:26:24 Not sure a single process is suitable for both 14:26:25 or has that changed 14:26:29 (at least for now) 14:26:42 Well, MANO was out of scope, then tacker started... 14:27:57 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 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 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 im not saying it has to be separate so much as has been out of scope of say opnfv 14:30:49 i know tacker exists but is that opnfv driven, or something that folks who happen to also be in opnfv drove 14:30:53 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 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 because orchestration wasnt in scope of opnfv 14:31:21 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 sgordon: I see 14:31:44 wznoinsk, plenty of work to do wrt NUMA yet 14:31:51 e.g ok we have SR-IOV numa locality 14:31:58 what about vswitch locality 14:31:58 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 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 sgordon: do you mean having ovs+dpdk on the same numa node as dpdk's pmd or else? 14:34:37 same node as the guest 14:34:51 also thread policy isnt done yet either for that matter 14:36:16 isn't it a scalability issue if you have 8 numa nodes? I guess you mean the 'preferred' rather than 'strict' 14:36:19 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 wznoinsk, why 8 14:36:48 i.e. mechanisms exist for those, it's raelly how best to grease the wheels 14:36:55 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 wznoinsk, same problem exists with any number > 1 14:38:07 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 sgordon: yes, with > 1 too, I never thought about vswitch <> numa locality, interesting 14:40:06 it's only really come up recently 14:40:18 once people started testing more ;) 14:40:32 i dont really have a proposed solution for that :) 14:40:32 apologies - fire alarm here... 14:40:35 np 14:40:38 im going to call it for now 14:40:46 i think we will need to continue this discussion though 14:40:59 i am also interested in daniel schab's thoughts as the other remaining core 14:41:54 sgordon: I'm interested in that as well, a bit concerned about the rest of the guests on the other numas 14:42:55 right 14:43:08 you cant give everyone vswitch locality 14:43:24 (not without leaving capacity on the table anyway) 14:43:36 anyway, i will close the meeting for now 14:43:59 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 #endmeeting