14:00:52 #startmeeting telcowg 14:00:52 Meeting started Wed Aug 26 14:00:52 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:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:55 The meeting name has been set to 'telcowg' 14:00:58 #link https://etherpad.openstack.org/p/nfv-meeting-agenda 14:01:03 #topic roll call 14:01:05 \o/ 14:01:15 hello 14:01:55 anybody else around for the telco wg meeting? 14:02:00 * sgordon eyes off adrian-hoban 14:02:41 #topic openstack summit tokyo 14:02:57 :-) 14:03:05 #info Requested Tuesday 2:00 - 2:40, 30 person room 14:03:27 i put in a request for working group space based on the available slots 14:03:34 not much more to add on that for now 14:03:47 #topic lucky volunteers! 14:03:56 #info Taking BGP use case as a "guinea pig" to turn into RFEs/backlog 14:04:08 #info Taking Affinity gap from the IMS use case and doing same 14:04:15 we discussed these in an earlier meeting 14:04:25 but i am not sure we have anyone signed up to actually do it... 14:05:26 14:05:57 #action sgordon to email list about taking BGP use case and Affinity gap from IMS use case to RFEs/backlog 14:06:04 #topic reviews 14:06:14 i pinged mkoderer about these before the meeting 14:06:20 he cant make it as he is traveling 14:06:25 but we still have some stuck reviews 14:06:32 #link https://review.openstack.org/#/q/status:open+project:stackforge/telcowg-usecases,n,z 14:06:38 particularly the workflow one 14:07:51 What is holding that back from concluding? 14:08:14 someone other than DaSchab to +@ 14:08:16 +2 14:09:26 Same story for the optional template sections? 14:09:30 ok, let me dig into it 14:09:43 yah 14:09:59 aveiga, thanks 14:10:13 i think we have been through enough rounds on this that it should be good to go... 14:10:27 give me a bit, since it looks like gerrit is awfully slow on my end... 14:10:38 no problem 14:10:44 #topic other business 14:11:14 in addition to the ops midcycle there was a product wg midcycle last week, i wasnt able to attend because i went to linuxcon/kvm forum instead 14:11:16 sgordon: any news on the productwg discussions? I know they had face to face time in opsp 14:11:21 yeah that 14:11:36 so there was a de-brief email of sorts sent out 14:12:04 i am still filtering through it and need to catch up with nick barcet (my boss) who went as my proxy 14:12:15 to work out how the discussions impact us 14:12:36 they now have a series of use cases roughed out in google docs but are looking to move them into a git repo they have created 14:12:40 (sound familiar?) 14:12:59 which might be the point where we want to merge efforts 14:13:08 I believe they are looking at the template we created to help with that 14:13:12 they? Is the google doc public? 14:13:14 yes that is correct 14:13:19 yes it is public 14:13:46 #link http://lists.openstack.org/pipermail/product-wg/2015-August/000676.html 14:13:56 #link https://drive.google.com/folderview?id=0BxtM4AiszlEyfm9UTW5LMEQ5cUhHbmFsSkd5WFNfdTMwVFIwRUM1TVFXSHhhWHl6VHlpRzg&usp=sharing 14:14:00 I’m working with OPNFV looking for areas we might collaborate or share - thanks for link. 14:14:33 #link https://docs.google.com/spreadsheets/d/1d1ZKuZ6gsiG6CXXrfONBwAGGHA8SYINbYC9BSPBKllI/edit#gid=1956934401 14:15:32 as you might gather from those there is quite a lot to review 14:15:34 wow - lot’s of info - 14:15:38 yeha 14:15:42 Hi, I have been lurking - but this looks like some good stuff 14:15:59 Hi @bryan_att 14:17:09 sgordon, since you are in AOB - one question I could ask 14:17:23 sure 14:17:44 in OPNFV qwe are building traffic profiles for NFV platform testing 14:18:06 have any management / control plane / session profiles been developed in OpenStack? 14:18:21 for various use cases e.g. mobilty, IMS, CDN, etc 14:18:43 aveiga, ^^ 14:18:47 not that i am aware of 14:19:16 profiles? 14:19:24 not sure it directly relates to the charter of OPenStack but since this is a "telco" focused group thought i would ask 14:19:53 "profile" meaning e.g. a set of protocols and traffic volumes across the user plane in an average session 14:20:08 or control plane, or management plane, etc 14:20:24 for use in background traffic or performance testing 14:20:35 no, because I'm not sure what that would get abstracted to in an OpenStack sense 14:20:45 maybe you're looking for QoS configs? 14:21:15 yes, understood - only in how it might affect e.g. the autoscaling performance etc would it matter to OpenStack 14:21:25 hello 14:22:12 aviega, not specifically, just looking for input on typical traffic profiles for testing purposes 14:22:28 I don't think we have any right now 14:22:38 OpenStack officially only tests functionality at the gate 14:23:06 when we put the NFVI under load most will be focused on the data plane, but will also test the management plane (NFVI control) performance 14:23:11 thanks anyway 14:23:37 aveiga, thanks that was my understanding also 14:23:37 bryan_att: I've seen some OpenStack network scalability presentations 14:23:48 Let me dig out the link 14:23:57 some third parties do their own testing, like adrian-hoban_ pointed out 14:24:15 thanks, the input is appreciated 14:24:21 e.g. https://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/presentation/can-you-trust-neutron-a-tour-of-scalability-and-reliability-improvements-from-havana-to-juno 14:25:07 bryan_att: maybe explain the goal of these profiles? We want to understand the capacity of a given platform config 14:25:27 so many cpus, memory, nics, etc will allow so many calls or users 14:25:44 there is a packey loss of latency of the following with this given traffic profile 14:25:47 right? 14:26:22 iben: I wasn't thinking in the resource requirements spec direction but that could be a side-benefit of developing a traffic model for a service 14:26:47 i.e. give me a resource pool that can serve a particular profile 14:26:47 so there is no performance testing in the openstack gate process 14:27:09 iben, no 14:27:09 sorry o that was a question for aveiga 14:27:09 I also don't think there's a mechanism in OpenStack for guaranteed minimum performance 14:27:15 thanks sgordon 14:27:28 QoS will get one for min bandwidth, but there's nothign in nova that does that 14:27:30 keep in mind that the openstack gate is itself running on top of an openstack cloud 14:27:36 right 14:27:37 and using emulation for virt 14:27:54 (it doesnt use nested kvm, just qemu) 14:28:02 is the focus of this group mainly to ensure features needed by telcos are implemented in openstack? 14:28:13 There is some quota mgmt. capability in Nova, but doesn't get to the level bryan_att is referencing 14:28:20 things like letting a vm use vlan trunks? 14:28:22 iben: it's to facilitate Telcos in requesting capabilities from OpenStack 14:28:32 cpu pinning and pci passthrough? 14:28:46 adrian-hoban_: quota doesn't do guaranteed mins, i.e. IO profiles or clock cycles 14:29:25 it just does genral primitives like vcpu or RAM 14:29:53 and in most cases, the intent is to actually abstract most of that info anyway 14:30:10 aveiga: you can set some vif inbound and outbound average, burst and peak rates 14:30:21 right and iirc the cgroups stuff we have is setting maximums only 14:30:23 not minimums 14:30:28 adrian-hoban_: that depends on the vif driver, though 14:30:33 not all of them even support that 14:30:44 aveiga: +1 14:31:17 bryan_att: so to answer your question, there's no API object that would allow for setting minimum resource pools to guarantee a specific level of performance 14:31:36 at least, not currently 14:31:43 I can't speak to the plans for nova 14:32:03 aviega: yes, understood. it's something that a service orchestrator would need to do, today, above OpenStack 14:32:23 you'll want to rely on heat and TOSCA support to do a lot of that 14:32:44 based upon awareness of inventory 14:33:06 yes, the orchestration data models are a place to start 14:33:22 yup, it's just going to be difficult for some use cases (like RTP) that depend on IO interrupt handling to be perfect and cpu availability to be guaranteed 14:33:35 aveiga: Depends on the service orchestrator and what level is chosen to interface with OpenStack. Both Heat and TOSCA are certainly options 14:34:24 adrian-hoban_: yes, it depends on what you want from the platform. But guaranteed minimum performance levels aren't in OpenStack proper, so they'll have to be monitored and controlled for from the outside 14:35:17 that is why we have an OPNFV project on resource reservation 14:35:29 aveiga: +1 14:35:57 we need to incorporate openstack support for reservation but add to it active & available inventory 14:36:37 then make allocation decisions based upon various criteria etc 14:37:24 at some point this will come back to openstack as work in a project - for now it's a developing idea in OPNFV 14:38:27 bryan_att, i guess the key point of interest is how that will filter back into the community 14:38:33 bryan_att: This would make for a great use case when ready 14:38:42 there has been a lot of debate about how reservations should be handled in the past 14:38:44 adrian-hoban_: +1 14:39:42 I'm not sure when but there is active interest in oncovering related, ongoing work in OpenStack and pushing any new gaps/BPs in that direction 14:41:22 the two main aspects are resource requirements specs, and reservation capability 14:41:52 bryan_att: From what I've seen the requirements are resonably well understood and some have already been documented in the ETSI-NFV phase 2 docs. It would be great to get the use case out their for the OpenStack community to comment and share some of the previous debate conclusions 14:42:50 Sorry, I should say partially documented. The phase 2 specs are a work in progress 14:43:05 I will pass that back to the projects in OPNFV, to see if we can upstream a use case doc here in the short term 14:43:24 per our earlier discussion in Vancouver that is a goal - more and earlier interaction 14:43:44 just difficult in the blizzard of projects and meetings... 14:44:12 bryan_att: +1 14:47:14 Thanks team! 14:49:43 #endmeeting