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