14:03:06 <sgordon_> #startmeeting nfv
14:03:06 <openstack> Meeting started Wed Sep 24 14:03:06 2014 UTC and is due to finish in 60 minutes.  The chair is sgordon_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:03:12 <openstack> The meeting name has been set to 'nfv'
14:03:12 <sgordon_> #topic roll call
14:03:14 <sgordon_> who is around
14:03:17 <bauzas> \o
14:03:20 <sgordon_> o/
14:03:23 <russellb> hi
14:03:28 <Imendel> hi
14:03:29 * sgordon_ waves to Imendel
14:03:31 <cloudon1> hi
14:03:35 <sgordon_> hi cloudon1
14:03:49 <zuqiang> hi
14:03:59 <sgordon_> #link https://etherpad.openstack.org/p/nfv-meeting-agenda
14:04:10 <sgordon_> #topic review actions
14:04:31 <sgordon_> ok, so i havent had much luck on identifying heat or glance participants as yet
14:04:44 <sgordon_> this may be something we want to revisit with specific proposals as we discuss them
14:05:03 <sgordon_> for example the OVF item in the list currently, and the heat sr-iov use case Imendel was planning to present
14:05:08 <sgordon_> speaking of which :)
14:05:14 <sgordon_> Imendel, did you have any luck defining this?
14:05:50 <Imendel> i check it and while defining it seems ts supported
14:06:15 <Imendel> if i got it right the port type for ariov
14:06:19 <sgordon_> oh ok
14:06:20 <Imendel> sriov is in
14:06:22 <sgordon_> cool :)
14:06:43 <sgordon_> so creation of a vm with sriov ports attached works from heat?
14:08:19 <sgordon_> Imendel, ^?
14:09:31 <sgordon_> ok we move on i guess
14:10:00 <sgordon_> #info Imendel checked while defining VM using heat and appears to support SR-IOV port type if it is selected.
14:10:14 * sgordon_ sgordon to     clear up project touch points on wiki page (sgordon,     16:06:28)
14:10:22 <sgordon_> so i did a *tiny* bit of wiki gardening
14:10:25 <sgordon_> still more to do
14:10:33 <russellb> i like the term, wiki gardening :)
14:10:34 <sgordon_> mainly updating the upcoming meeting dates/times
14:10:39 <sgordon_> and what landed in juno
14:10:41 <bauzas> :)
14:10:50 <sgordon_> would like to discuss today picking some top items for kilo
14:11:14 <sgordon_> obvious ones still at the top of the list are vlan trunking
14:11:18 <sgordon_> and unaddressed interfaces
14:11:36 <sgordon_> but i think we need to pick out some other candidates behind those and be sure to discuss with the relevant projects
14:11:57 <cloudon1> +1 for VLAN; also v interested in Luke Gorrie's SnabbSwitch accel data plane
14:12:02 <sgordon_> #link https://wiki.openstack.org/wiki/Teams/NFV#Development_Efforts
14:12:09 <russellb> finishing up some ones in progress would be good priorities
14:12:15 <sgordon_> russellb, right
14:12:16 <russellb> good ROI
14:12:42 <sgordon_> so in the case of vlan trunking and the unaddressed interfaces i think design proposals exist to revisit
14:12:45 <sgordon_> as well as code iirc
14:12:51 <sgordon_> and obviously there is in progress numa work
14:12:51 <Imendel2> where can i see the reasoning for the vlan one? at this forum terms...
14:12:54 <russellb> couple in nova come to mind (large pages, cpu pinning), both had specs approved before
14:13:23 <sgordon_> Imendel2, per i think ijw's updates to the description in the table there is some confusion here
14:13:32 <cloudon1> russellb: +1 to both of those
14:13:32 <sgordon_> as there are a couple of different requests on the line
14:13:54 <sgordon_> but my understanding is that the desire is to trunk VLANs into VMs over a tenant network when using Neutron/ML2 OVS
14:14:08 <sgordon_> currently this is not possible because when the OVS VLAN tags are removed so are all others
14:14:13 * sgordon_ hopes he got that all right :)
14:14:35 <Imendel2> ok. why its needed though...?
14:16:19 <Imendel2> asking as per our two weeks ago chat
14:16:20 <TapioT> Hi we need it since we want to terminate a large number of L2 networks in a VNF
14:16:29 <cloudon1> Imendel: thinking just of NFV, one case is session border control & detecting different customers with different policies to apply based on what VLAN they are using
14:16:40 <Imendel2> how and why we habe the need
14:16:55 <sgordon_> right
14:17:13 <sgordon_> i believe ijw has a similar use case to what cloudon1 is describing
14:17:59 <cloudon1> In general, edge functions may often want to differentiate based on VLAN
14:18:07 <Imendel2> so we have the same net but using inside vlans within a tenant net to describe users?
14:18:22 <Imendel2> on the same tenant net?
14:18:32 <sgordon_> yes
14:18:51 <sgordon_> keep in mind users of the VNF not necessarily == users/tenants of the openstack install
14:18:56 <sgordon_> it's not a 1:1 mapping
14:19:42 <Imendel2> right. feels like an "old" apo arch moved to os... or i am missing something here
14:19:53 <Imendel2> ?
14:21:07 <Imendel2> do we agree that for this discussions tenant net = internal app traffic?
14:21:36 <Imendel2> not to the end users? sbc end users for example?
14:21:59 <sgordon_> cloudon1, TapioT interested in your thoughts here
14:22:02 <cloudon1> Imendel2: the provider is implementing network functions from the cloud - but consumers of those function may well not be (often won't) in the cloud
14:22:17 <sgordon_> after all i work for an openstack vendor but this should be user driven
14:23:05 <sgordon_> #info Interesting discussion about VLAN trunking to VM use cases ensued while discussing kilo priorities.
14:23:11 <Imendel2> if not the right time to discuss this level of details we can take it offline....
14:23:40 <cloudon1> Imendel2: will try to send something to ML explaining use case in more detail
14:23:53 <Imendel2> tnx
14:24:21 <TapioT> Looks good to me
14:24:56 <sgordon_> thanks cloudon1 that would be great - seems like you have a good handle on it which matches my understanding
14:25:10 <sgordon_> but good to see it matching someone else lol :)
14:25:24 <sgordon_> #action cloudon1 to document VLAN trunking to VM use case for M/L post
14:25:30 <Imendel2> :)
14:25:32 <sgordon_> #topic juno status
14:25:39 <sgordon_> i dont really have a juno status update
14:25:51 <sgordon_> implementation for numa pinning to the node landed
14:25:54 <sgordon_> sriov landed
14:25:59 <sgordon_> both with feature freeze exceptions
14:26:28 <sgordon_> other numa and topology details to be continued in kilo (particularly memory and cpu pinning aspects)
14:26:49 <sgordon_> Imendel2, what did you do your sriov heat testing against? trunk?
14:27:04 <sgordon_> key now is kicking up any bugs :)
14:27:33 <Imendel2> dont recall... will come back on this one
14:29:07 <sgordon_> Imendel2, ok np
14:29:17 <sgordon_> #info testing, testing, testing
14:29:25 <sgordon_> release candidates should be getting cut...real soon now
14:29:27 <sgordon_> i think
14:30:00 <russellb> yep
14:30:04 <russellb> over the next couple weeks
14:30:23 <sgordon_> so keep an eye out for those
14:30:40 <sgordon_> the numa and sriov work in particular as i mentioned had FFEs so was only finalized in what will ultimately be RC-1
14:31:01 <sgordon_> #info expect SR-IOV and NUMA to be in RC-1 packages, available from trunk now for testing
14:31:10 <sgordon_> #info kilo planning
14:31:19 <sgordon_> we discussed this a little already
14:31:30 <sgordon_> but need to start curating the list of things that people are still working on for kilo
14:31:37 <sgordon_> thierry put out a draft schedule email
14:31:39 <sgordon_> #link http://lists.openstack.org/pipermail/openstack-dev/2014-September/046793.html
14:32:06 <sgordon_> that email and ensuing thread has tentative kilo dates in it
14:32:47 <sgordon_> the varios projects are also planning their design sessions via etherpads
14:32:51 <sgordon_> they are linked from here:
14:32:53 <sgordon_> #link https://wiki.openstack.org/wiki/Summit/Planning
14:33:17 <sgordon_> #action ALL please review relevant project design summit plans (Nova, Neutron, Heat, Glance, etc.)
14:33:39 <sgordon_> #info if you have items you wish to discuss at design summit bring them to the team meetings for each team to socialize and add to the etherpad
14:33:46 <sgordon_> we can of course also discuss here :)
14:34:10 <sgordon_> one of the tangential but important items on the nova pad is the future of the sheduler
14:34:13 <sgordon_> *scheduler
14:34:18 <bauzas> right
14:34:21 <sgordon_> this impacted the numa work in a big way
14:34:30 <sgordon_> and a lot of other things that are on the list on the nfv wiki page as well
14:34:34 <sgordon_> #link https://etherpad.openstack.org/p/kilo-nova-summit-topics
14:34:56 <Imendel2> its a big one yes
14:35:37 <bauzas> sgordon_: days 2 and 3 will be having a 40-min session style
14:35:39 <TapioT> Are you talking about the solver scheduler? Or the scheduler API?
14:35:58 <bauzas> sgordon_: so we don't know if we'll have one or more slots for discussing the split there
14:36:01 <sgordon_> TapioT, how to put interfaces on the scheduler to be more pluggable and potentially split it out
14:36:13 <sgordon_> but also some of the issues with the existing implementation
14:36:20 <bauzas> sgordon_: day 4 will be a meetup style, with open talks, so I open some discussions will be raised there too about the split
14:36:21 <sgordon_> particularly the way resources are currently tracked
14:36:43 <sgordon_> TapioT, part of the problem for the solver scheduler has been there is no nice place for it to plug on to
14:36:44 <bauzas> TapioT: Solver Scheduler is currently on-hold until we figure out how to split properly
14:36:46 <sgordon_> via a stable api
14:37:56 <sgordon_> did anyone have other items they want to highlight they have added to these pads?
14:38:07 <sgordon_> i am just scanning the neutron one
14:38:22 <cloudon1> Does that effectively mean any BPs that want to enhance scheduler fn are on-hold till that's resolved?
14:38:40 <bauzas> cloudon1: not exactly
14:38:51 <bauzas> cloudon1: that's on a case-by-case basis
14:39:11 <cloudon1> presumably though if they proceed now they are at risk of having to reimplement?
14:39:16 <bauzas> cloudon1: for example, we're still accepting new filters
14:39:18 <sgordon_> there are some proposals for continuing to work on sriov that might be of interest t the group
14:39:19 <sgordon_> #link https://etherpad.openstack.org/p/kilo_sriov_pci_passthrough
14:40:13 <bauzas> cloudon1: what could be delayed would be when needing new interfaces in between the scheduler and other Nova bits
14:40:39 <Imendel2> there is the tosca and heat one. need to check if bp exist. but was discussed in mid term
14:41:00 <bauzas> sgordon_: so, just to make sure, we won't ask for a cross-project session ?
14:41:18 <sgordon_> bauzas, im open to asking
14:41:37 <bauzas> sgordon_: because we exactly have the same concern with Gantt
14:41:38 <sgordon_> bauzas, i am getting a lot of developer feedback that openstack devs still dont know what nfv means and why they should care
14:41:55 <sgordon_> Imendel2 touched on a lot of this in an email recently but we need a way to illustrate
14:42:41 <sgordon_> as we've discussed before problem is design sessions have typically expected a very specific problem space or proposal to discuss
14:42:57 <sgordon_> there is no harm in suggesting one though
14:43:01 <bauzas> sgordon_: I'm just thinking we should maybe ask for some slots on the first day for projects or programs having multiple client projects as dependency
14:43:31 <Imendel2> +1
14:43:47 <bauzas> well, at least asking is free
14:43:53 <sgordon_> right
14:44:10 <sgordon_> until someone hooks it up to a metering system anyway and then who knows
14:44:24 <sgordon_> #link https://etherpad.openstack.org/p/kilo-crossproject-summit-topics
14:45:22 <sgordon_> need to frame it right
14:45:37 <sgordon_> in Imendel2's email there were these questions:
14:45:38 <sgordon_> *   Why (it) is special ?
14:45:38 <sgordon_> *   Why we need it now?
14:45:38 <sgordon_> *   Who will use it and why it can’t be achieve otherwise?
14:46:28 <sgordon_> i think it's important to ask and answer these both of those deploying NFV solutions and of the development community
14:46:44 <bauzas> sgordon_: Imendel2: email's link ?
14:46:49 <sgordon_> e.g. Why do CSPs/NEPs/etc. care about NFV? Why should OpenStack care about NFV?
14:47:01 <sgordon_> grabbing it
14:47:07 <keshava> Here are openstack requirement from NFV side from my perspective
14:47:17 <sgordon_> #link http://lists.openstack.org/pipermail/openstack-dev/2014-September/044614.html
14:47:18 <keshava> 1.Will openstack allows Service-VM to insert its data (like routing table) in the Compute node ?  2.Can Diffirent Service-VM can be chained, meaning the Flow derived from service-VM1 should act as input to Service-VM2 flows . 3. Can openstack allow Serivice to insert inside the Service-VM, if so where is the standard Service related API
14:47:51 <sgordon_> keshava, so that seems more specifically related to items on the neutron session planning page right?
14:48:18 <bauzas> sgordon_: thanks
14:48:26 <keshava> yes
14:48:28 <sgordon_> as in they would be well posed under the service insertion and servicevm items on the etherpad here:
14:48:31 <sgordon_> https://etherpad.openstack.org/p/kilo-neutron-summit-topics
14:48:40 <sgordon_> please add them to ensure it's included in the discussion
14:48:55 <keshava> but this is requirement is for NFV functionality
14:49:10 <keshava> implementation is from neutron side.
14:49:33 <sgordon_> sure, but i dont think it answers the more general question being posed in some of the development discussions
14:49:39 <sgordon_> which is why does openstack care and vice versa
14:49:46 <sgordon_> that is what we need to more clearly illustrate
14:50:00 <keshava> but service-insertion and flows chaining across service-VM framework can be from NFV side ?
14:50:12 <bauzas> keshava: NFV is a cross-project effort
14:50:23 <Imendel2> i think its two levels. the magnitude of the use case
14:50:49 <keshava> who owns 'Service Framework' at controller side ? and Flows chaining as compute node ?
14:50:50 <sgordon_> the intent here is to organize our efforts between many people working on NFV across the ecosystem
14:50:52 <bauzas> keshava: some changes can be done on Nova, others on Neutron, and once a Scheduler project would be there (aka. "Gantt"), some holistic placement decisions could be made there
14:50:58 <Imendel2> and then tne needs. which imho shall be described in general terms and with the trio questions
14:51:12 <sgordon_> the questions you are asking are very specific to how it will be implemented versus a user story for example
14:51:48 <Imendel2> right. those are for the use case "why"
14:51:58 <Imendel2> for each we describe
14:51:59 <keshava> scheduler, SRIOV, Kernal pass-though are smaller part of NFV requirement
14:52:46 <bauzas> keshava: I don't understand exactly your need, could you maybe rephrase it ?
14:52:53 <Imendel2> for each use case i suggest to describe in general terms and not nfv specific
14:53:03 <sgordon_> keshava, perhaps you could document a use case for us to illustrate better?
14:53:31 <sgordon_> then it can be compared against the work being done in ServiceVM/Tacker and we can determine what is or isn't underway?
14:53:59 <keshava> Ok i will document and send it across in the mailing list
14:54:31 <sgordon_> excellent, thanks!
14:55:01 <sgordon_> #action keshava to document their service insertion and chaining use case
14:55:10 <sgordon_> so we're running towards the top of the hour...
14:55:26 <sgordon_> #topic other discussion
14:55:40 <sgordon_> im traveling next week and cant make the meeting
14:55:44 <sgordon_> is anyone else able to lead?
14:55:49 <sgordon_> it's the thursday timeslot
14:55:50 <keshava> example use case is NFV1: NAT service VM,  and its forwarding out packet should be input to LB related functionality where is LB is NFV2: LB,
14:56:13 <sgordon_> #info need a chair for Thursday 2nd October 2014 	1600 UTC
14:56:55 <Imendel2> i can. need guidance on logistics..:)
14:57:07 <sgordon_> #action Imendel2 will chair next week
14:57:11 <sgordon_> Imendel2, ok
14:57:15 <keshava> based on order of  packet forwarding ( in compute node) we need to Service-VMs to chain/cascade on top of controller
14:57:34 <sgordon_> Imendel2, i can still help with framing up the agenda on https://etherpad.openstack.org/p/nfv-meeting-agenda
14:57:47 <Imendel2> tnx
14:57:48 <sgordon_> Imendel2, will just need to make sure i send you the info for controlling the meeting bot
14:57:59 <Imendel2> ok
14:58:03 <sgordon_> bauzas, and russellb also know how to use it if they are around so they can help
14:58:03 <sgordon_> :)
14:58:12 <bauzas> sgordon_: Imendel2: for sure
14:58:18 <Imendel2> :) lucky me
14:58:46 <sgordon_> ok, thanks all !
14:58:49 <sgordon_> #endmeeting