14:00:49 <sgordon> #startmeeting nfv
14:00:50 <openstack> Meeting started Wed Aug  6 14:00:49 2014 UTC and is due to finish in 60 minutes.  The chair is sgordon. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:53 <openstack> The meeting name has been set to 'nfv'
14:00:55 <sgordon> hi all
14:01:01 <aleksandr_null> hi
14:01:02 <aleksandr_null> o/
14:01:04 <sgordon> #topic roll call
14:01:17 <smazziotta> hi
14:01:20 <sgordon> who is here for the nfv meeting?
14:01:23 <aleksandr_null> o/
14:01:27 <sgordon> hi aleksandr_null, smazziotta
14:01:35 <niclem> Hi
14:01:38 <yamahata> hi
14:01:44 <cloudon> hi
14:01:46 <aleksandr_null> sgordon: Hi!
14:01:54 <sgordon> #topic review actions from last week
14:02:11 <sgordon> #info bauzas to update list with link to new dash
14:02:19 <sgordon> #link nfv.russellbryant.net
14:02:36 <sgordon> per an email to the list during the week the dash is now working again
14:02:52 <sgordon> please continue using it to review nfv related work
14:03:00 <sgordon> (we will go through some of the items later in the meeting)
14:03:37 <sgordon> #info sgordon was to confirm future meeting times at next week's meeting
14:03:38 <sgordon> so
14:03:48 <sgordon> i received ~26 responses to the when is good
14:04:02 <sgordon> #info received ~26 responses to whenisgood req
14:04:06 <russellb> o/
14:04:17 <sgordon> bets clustering of responses is actually around the current time or *earlier*
14:04:35 <sgordon> which doesnt really address the original concern of not catering at all to people on PST
14:04:46 <sgordon> so i am wondering if an alternate would make sense
14:04:59 <russellb> yeah, that's what the nova team ended up doing
14:05:00 <sgordon> clustering of responses for current time indicate 16 can make it
14:05:02 <russellb> alternating each week
14:05:09 <sgordon> best clustering for pst is 1600 UTC with 10
14:05:21 <sgordon> 1600 UTC on a thursday that is
14:05:51 <sgordon> right
14:06:00 <sgordon> so i will send that for M/L to confirm
14:06:01 <russellb> though this group isn't *that* big ...
14:06:07 <sgordon> right
14:06:11 <russellb> so it may be tough to have inconsistent attendance
14:06:18 <russellb> but doesn't hurt to try and see how it goesw
14:06:20 <sgordon> it's a challenge
14:06:35 <sgordon> i did have some key participants from the west coast reach out to me about this so i would like to try it
14:06:48 <cloudon> how many attendees were common to both times?
14:07:49 <sgordon> cloudon, some but not all
14:08:04 <sgordon> cloudon, basically as you would expect - later is less palatable for european contributors
14:08:08 <sgordon> cloudon, still works for US east
14:09:11 <aleksandr_null> 16 UTC definitely better than 14.
14:09:58 <sgordon> #info current time works for most respondents (16)
14:10:27 <sgordon> #info 1600 UTC Thursdays has most respondents (10) of times palatable for US West
14:10:39 <sgordon> #info Some overlap for both times from US East, not so much Europe
14:10:40 <smazziotta> for US west. current time is better than earlier :-)
14:10:46 <sgordon> right
14:11:03 <sgordon> there were actually an equalish number of responses for current time *or earlier*
14:11:13 <sgordon> which doesnt really address the original concern raised
14:11:31 <sgordon> #action sgordon to email list about alternating schedule
14:11:59 <sgordon> #info adrian-hoban was to follow up on M/L regarding potential for pre-loading the early kilo milestones
14:12:17 <sgordon> adrian-hoban, did you get a chance to follow up on the above or holding off a little while people focus on j-3?
14:12:38 <aleksandr_null> This reaaly means that number of participants from Europe equals to American ones :)
14:12:50 <adrian-hoban> sgordon: It was the latter I'm afraid. Also there was some other ML traffic related to blueprint process
14:13:02 <sgordon> adrian-hoban, yeah - no problem
14:13:07 <adrian-hoban> I will follow up this week for sure
14:13:27 <sgordon> adrian-hoban, unclear how to best proceed with that but it's a project wide discussion we need to have
14:13:55 <sgordon> #info smazziotta was to report on outcome of ETSI NFV gaps discussion at this week's meeting
14:14:03 <sgordon> smazziotta, how goes it :)
14:14:39 <adrian-hoban> sgordon: I think I'll start a thread on harmonizing the blueprint process... Uncertainty related to timing and what to do when bps are not progressing as the author would like seems to be the key themes to address
14:15:00 <sgordon> adrian-hoban, right
14:16:10 <adrian-hoban> Does this team agree there would be value in having BPs dealt with in a consistent way across projects?
14:17:23 <sgordon> adrian-hoban, i think the pain points remain the same
14:17:31 <sgordon> adrian-hoban, the most active projects (nova, neutron)
14:17:41 <smazziotta> sorry. was on another chat
14:17:44 <sgordon> adrian-hoban, have additional constraints that cause them to implement additional checkpoints
14:17:59 <sgordon> adrian-hoban, but communication and expectation setting around those is not always clear
14:18:34 <smazziotta> the rapporteur committed we will have a consolidated gaps before mid october. that was our requirement.
14:18:55 <sgordon> smazziotta, ok
14:19:10 <sgordon> smazziotta, is that to be communicated by a draft on the ETSI NFV site or some other mechanism?
14:19:18 <smazziotta> they said for sure by mid september perhaps before.
14:19:23 <sgordon> excellent
14:19:33 <smazziotta> this will be posted on the open ared
14:19:39 <smazziotta> area
14:20:07 <sgordon> #info smazziotta reports good progress on ETSI NFV gap analysis and hopeful of publication by mid september - before mid october deadline set by this group for lead in to kilo summit
14:20:19 <sgordon> smazziotta, sounds good thanks for the update
14:20:36 <sgordon> so now that the dashboard is actually working....i want to lead in to blueprints
14:20:41 <sgordon> #topic blueprints
14:20:48 <smazziotta> I will monitor progress and make sure we have asap
14:20:57 <sgordon> i have been following up on a few of these in between meetings but could do with some help
14:21:07 <sgordon> #link https://review.openstack.org/#/q/status:open+project:openstack%2Fnova+topic:bp%2Fmultiple-if-1-net,n,z
14:21:19 <sgordon> this was one of our priority items and is progressing well afaict
14:21:40 <sgordon> some minor feedback to integrate on the latest reviews
14:22:14 <sgordon> #link https://review.openstack.org/#/q/status:open+project:openstack%2Fnova+topic:bp%2Fpci-passthrough-sriov,n,z
14:22:31 <russellb> i have that on my todo for today
14:22:34 <sgordon> there are still a number of sriov related patches outstanding
14:22:35 <russellb> to do another pass through the sr-iov patches to nova
14:22:47 <sgordon> cool
14:22:50 <russellb> i was trying last week but the patches were broken by bad rebases
14:22:56 <russellb> seems to be good now
14:23:00 <sgordon> yes beagles filled me in on that
14:23:06 <sgordon> hopefully all under control now
14:23:27 <sgordon> so there are 4 patchsets there, would be great if people could take a look
14:23:42 <sgordon> one of the challenges with this has been the breadth of the work and getting everything into a release
14:24:00 <sgordon> #link https://review.openstack.org/#/q/status:open+project:openstack%2Fnova+topic:bp%2Fvirt-driver-numa-placement,n,z
14:24:23 <sgordon> the virt driver numa awareness work is similar in that there are a large number of associated patchsets in varying states of review
14:24:45 <bauzas> \o (damn, forgot the meeting)
14:24:54 <sgordon> should note this is topic is related to the above as well
14:25:09 <sgordon> #link https://review.openstack.org/#/q/status:open+project:openstack%2Fnova+topic:bp%2Finput-output-based-numa-scheduling,n,z
14:25:51 <sgordon> (for anyone following along despite some issues with spec approvals there is still an enormous amount of code to review out there for juno....)
14:26:08 <sgordon> these next two i am not as familiar with
14:26:10 <sgordon> so need some help
14:26:13 <sgordon> #link https://review.openstack.org/#/q/status:open+project:openstack%2Fneutron+topic:bp%2Ftraffic-steering-abstraction,n,z
14:26:29 <sgordon> is anyone closely following the traffic steering abstraction work and familiar with current state?
14:26:47 <sgordon> oh nm
14:26:52 <sgordon> -2 spec wasnt approved
14:26:58 <sgordon> not sure how that was still on my list for today
14:27:19 <jchapman> sgordon: #link https://review.openstack.org/#/q/status:open+project:openstack%2Fnova+topic:bp%2Finput-output-based-numa-scheduling,n,z begin reworked at present
14:27:40 <sgordon> #info input-output-based-numa-scheduling being reworked at present by jchapman
14:27:49 <sgordon> jchapman, thanks for the update - much appreciated
14:28:12 <sgordon> jchapman, do you need any assistance with that and is it all gelling ok with what danpb and ndipanov are doing with the rest of the NUMA stuff?
14:29:49 <sean-k-mooney> the input-output-based-numa-scheduling work is dependent on #link https://review.openstack.org/#/q/status:open+project:openstack%2Fnova+topic:bp%2Fvirt-driver-numa-placement,n,z
14:30:02 <sgordon> sean-k-mooney, right
14:30:14 <sean-k-mooney> i belive jchapman is having connection issues
14:30:19 <sgordon> sean-k-mooney, that's the work i am referring to - danpb and ndipanov mainly seem to be driving that
14:30:30 <sgordon> sean-k-mooney, np
14:30:34 <russellb> guess i need to review those, too :)
14:30:43 <russellb> these things will be my review priorities for this milestone
14:31:28 <sgordon> russellb, thanks - much appreciated
14:31:46 <sgordon> so the next thing on the list is the extensible resource tracker
14:31:48 <sgordon> #list https://review.openstack.org/#/q/status:open+project:openstack%2Fnova+topic:bp%2Fextensible-resource-tracking,n,z
14:32:07 <bauzas> sgordon: seems like PaulMurray is on vacation
14:32:11 <russellb> are the numa patches still depending on that?
14:32:11 <sgordon> now i believe this was added because if implemented some of the vcpu pinning and or numa awareness work will need to depend on it
14:32:15 <russellb> or did that get worked around?
14:32:18 <bauzas> sgordon: at least, I was unable to get him by the last days
14:32:19 <sgordon> i am not sure that it is really an nfv thing though?
14:32:27 <russellb> it's not
14:32:28 <bauzas> sgordon: +1
14:32:34 <russellb> only if we depend on it for somethign else
14:32:34 <sgordon> russellb, right i was under the impression numa stuff was being developed without it
14:32:39 <russellb> sgordon: xlnt
14:32:40 <bauzas> sgordon: this BP is not dependent for NFV
14:32:41 <sgordon> russellb, and if it hits is easily modified to use it
14:32:50 <bauzas> the numa BPs are not depending on it
14:33:02 <sgordon> #info extensible resource tracker not a hard dependency of numa work
14:33:02 <bauzas> at least until now... :;)
14:33:27 <sgordon> #action sgordon to remove extensible resource tracker from nfv list (for now...)
14:33:34 <bauzas> sgordon: well ,unless s/o says the contrary when reviewing :)
14:33:40 <sgordon> lol right
14:33:49 <sgordon> couple more to get through here
14:33:58 <sgordon> i just picked these up by skimming the dash btw
14:34:11 <sgordon> so if anyone has some they believe i am missing, then by all means
14:34:18 <sgordon> #link https://review.openstack.org/#/q/status:open+project:openstack%2Fpython-novaclient+topic:bp%2Ffind-host-and-evacuate-instance,n,z
14:34:34 <bauzas> mmm
14:34:48 <bauzas> lemme check but IIRC, this bp is merged no ?
14:34:54 <bauzas> oh
14:34:58 <sgordon> bauzas, just the client bits to go
14:35:02 <sgordon> bauzas, afaict
14:35:03 <bauzas> right, not for client indeed
14:35:09 <sgordon> bauzas, have +2s need one more each
14:35:21 <sgordon> not much more to say about that because as you say core of the work landed in j-2
14:35:37 <sgordon> # find host and evacuate instance landed in j-2, client changes still in progress
14:35:42 <sgordon> #info find host and evacuate instance landed in j-2, client changes still in progress
14:35:50 <russellb> yay
14:35:51 <sgordon> ok
14:36:00 <russellb> client changes should be small ...
14:36:00 <sgordon> the last two i had were
14:36:09 <sgordon> #link https://review.openstack.org/#/q/status:open+project:openstack%2Fnova+topic:bp%2Fvif-vhostuser,n,z
14:36:16 <sgordon> #link https://review.openstack.org/#/q/status:open+project:openstack%2Fneutron+topic:bp%2Fsnabb-nfv-mech-driver,n,z
14:36:23 <sgordon> i dont actually see lukego here though
14:36:36 <sgordon> i know he has been trying to take the discussion from the reviews to the M/L
14:37:18 <sgordon> basically it looks like there are some concerns among the neutron core team that were not picked up in the original spec review
14:37:28 <sgordon> so further discussion required there...
14:38:37 <sgordon> #link http://lists.openstack.org/pipermail/openstack-dev/2014-August/041895.html
14:38:41 <sgordon> ^ is also relevant
14:39:31 <sgordon> so that is the list i hd
14:39:41 <sgordon> does anyone have other bps or even bugs they wish to discuss?
14:41:18 * bauzas hears the wind in the trees...
14:41:32 <sgordon> #topic Topics/Goals for cross-project discussion for summit?
14:41:51 <sgordon> so, hopefully you have all recovered from general summit submission season
14:41:58 <sgordon> and the ensuing onslaught of voting requests
14:42:23 <sgordon> last week we started to discuss how we might work on a cross-project session for nfv for paris
14:42:25 <bauzas> is there any etherpad/collaborative doc for all NFV related proposals ?
14:42:32 <sgordon> design summit submissions wont open for a while yet
14:42:53 <sgordon> but last time we had a few competing design summit submissions (i think a cross project, a nova, a neutron)
14:43:04 <sgordon> none of which were quite specific enough in terms of outline and goals
14:43:09 <sgordon> and as a result none got accepted
14:43:43 <bauzas> we can at least ask for a pod ?
14:43:47 <cloudon> There seem to be ~60 proposals for the main summit mentioning NFV...
14:43:53 <sgordon> cloudon, minimum
14:44:01 <bauzas> cloudon: uh...
14:44:27 <sgordon> cloudon, but here we're talking about how best to utilize the design summit to make progress on some of the actual work ;)
14:44:44 <vjardin> http://www.openstack.org/vote-paris/SearchForm
14:44:50 <vjardin> too many!
14:45:05 <sgordon> i have no doubt that NFV will be well covered in the general tracks particularly now there is a track specifically for telco strategies as well
14:45:17 <smazziotta> need to make sure that there will be the concept of POD. last time I discuss it there will be less space overall for the summit
14:45:24 <sgordon> #info around 60 proposals for general summit mentioning NFV
14:45:35 <sgordon> #info need to work out how best to make progress in design summit though
14:45:45 <sgordon> #info POD would be ideal
14:45:52 <sgordon> #info cross-project session also
14:46:02 <russellb> there will be pods available for sure
14:46:04 <sgordon> smazziotta, yes the venue is smaller
14:46:06 <russellb> don't have to have a dedicated one
14:46:08 <adrian-hoban> sgordon: If we had an updated list of NFV related BPs for discussion, then having a few time slots allocated for reviewing the entire set would be great
14:46:22 <sgordon> adrian-hoban, right
14:46:39 <sgordon> adrian-hoban, one thing i think we need to do is to update the wiki to reflect current state
14:46:44 <vjardin> no 75 NFV posts for Paris!
14:46:55 <sgordon> adrian-hoban, what is on track for juno and what is outstanding that we need to discuss
14:47:07 <vjardin> cat nfv.txt | wc -l => 75
14:47:21 <sgordon> adrian-hoban, particularly as ijw has pointed out since a number of key items considered priority in this group did not get approved
14:47:30 <sgordon> e.g. VLAN trunking into VMs
14:48:00 <sgordon> i will take an action to try and clean that up
14:48:07 <bauzas> that shows the need for at least one design session per project related to NFV :)
14:48:07 <smazziotta> if we have an issue. we can organize ad-hoc meeting at enovance office
14:48:16 <sgordon> #action sgordon to update wiki to reflect on track for juno vs outstanding
14:48:26 <sgordon> smazziotta, as russell said i think we can get at least pod time
14:48:44 <sgordon> smazziotta, if not a dedicated pod necessarily (book nova or neutron pod for a specific session for example)
14:48:55 <bauzas> +1
14:48:55 <adrian-hoban> bauzas: Maybe not for every project, but certainly Nova, Neutron, Glance, Heat
14:49:06 <sgordon> +1
14:49:12 <sgordon> that is why i like the idea of a cross-project one
14:49:22 <bauzas> adrian-hoban: you just readed in my mind :)
14:49:23 <sgordon> challenge is of course ensuring representation from each project at those
14:49:26 <smazziotta> I was just proposing it in case we have an issue with dedicated cross session.
14:49:51 <bauzas> sgordon: the problem with cross-project sessions is that you don't get attention from the project themselves
14:49:54 <sgordon> main feedback last time seemed to be that items listed in the cross-project session were either already covered (e.g. SRIOV had separate proposals)
14:50:00 <sgordon> or too nebulous
14:50:06 <cloudon> reviewing individual BPs is good but if problem is lack of understanding & concerns about being uncloudy don't we need to address head on with session giving NFV primer + explicit use cases + discuss  why we need to expose fine detail?
14:50:22 <bauzas> at least, we need to explain what we do to each community (Nova, Neutron, Glance, Heat ;) )
14:50:34 <sgordon> challenge is audience
14:50:39 <bauzas> +1
14:50:44 <sgordon> a lot of that type of discussion goes to general summit track
14:50:57 <sgordon> developers dont necessarily want to attend
14:51:12 <sgordon> conversely design session requires specific actionable goals
14:51:16 <russellb> part of the issue is that the design summit is supposed to be about concrete work, not higher level discussion of use cases and requirements
14:51:17 <sgordon> not really a place to present
14:51:19 <bauzas> we need at least to present the impacts on each project
14:51:26 <bauzas> and to make sure our views are shared
14:51:43 <russellb> identify the concrete blueprints, and suggest a session on them (either single BPs, or a group of related ones)
14:51:44 <bauzas> russellb: +1
14:51:47 <sgordon> bauzas, so to me it comes back to identifying work items based on the BP list
14:51:55 <bauzas> sgordon: agreed
14:51:56 <sgordon> bauzas, not even necessarily labelling as NFV
14:52:01 <bauzas> +1
14:52:10 <bauzas> we just have work to do
14:52:12 <sgordon> bauzas, just "here are X related items for project Y we would like to discuss in a session"
14:52:19 <bauzas> +1
14:52:43 <adrian-hoban> Many design sessions jump into the change details. What if for the NFV items, the lead submitter also provides a brief intro into the use case for each change to help set the context?
14:52:45 * bauzas thinks he is in violent agreement here
14:52:49 <russellb> sgordon: exactly
14:52:54 <sgordon> #info need to identify concrete list of proposals for kilo and group according to project and relationships between items
14:53:12 <russellb> otherwise, it will be rejected for sure
14:53:21 <sgordon> adrian-hoban, right - to me it is basically "here is the features i want to implement, here is how a user would use them and why they care"
14:53:25 <russellb> also, something that touches just nova+neutron is unlikely to make the cross-project cut
14:53:25 <bauzas> adrian-hoban: I guess that's part of the introduction when starting a session
14:53:29 <russellb> should propose to nova and/or neutron instead
14:53:43 <vjardin> but VIF driver is in between...
14:53:49 <russellb> the cross-project track gives priority to things that affect *everything*
14:54:07 <sgordon> #info cross-project session would need to touch more than just nova/neutron, heat, glance, etc. as well
14:54:13 <vjardin> VIF driver should migrate to neutron (or Nova) but not both
14:54:17 <sgordon> vjardin, this is a constant challenge
14:54:17 <vjardin> or be standalone
14:54:34 <sgordon> vjardin, where/how to progress on changes that touch both nova and neutron specifically is a real challenge
14:55:04 <bauzas> that's all about client and APIs you know...
14:55:05 <sgordon> both are large projects with a diverse contributor base that does not necessarily overlap as significantly as you might expect
14:55:19 <vjardin> could we have a hierachy of contributions? related to NFV
14:55:30 <vjardin> system contributions: VIF, Numa
14:55:46 <vjardin> protocol contributions: L3, NAT, firewalling, etc...
14:56:34 <sgordon> well, i think conceptually most in this group have an understanding of this
14:56:46 <bauzas> we have blueprints and groups of blueprints
14:56:50 <bauzas> that's in wiki
14:56:54 <sgordon> our real challenge is illustrating to the wider developer community that dont necessarily care about this
14:57:10 <bauzas> once OpenStack will move to Storyboard instead of Launchpad, we'll get Epics
14:57:19 <sgordon> they want to understand what the specific changeset they are looking at is for and why it exists
14:57:21 <bauzas> (like Scrum epics...)
14:57:35 <sgordon> without having to go out of their way to look at this groups categorization etc
14:58:15 <bauzas> I think grouping in Wiki is enough for a developer PoV
14:58:38 <bauzas> s/developer/reviewer
14:59:06 <sgordon> ok
14:59:16 <sgordon> i think i took my eye off the clock and we're actually out of time
14:59:26 <bauzas> 45 secs left :)
14:59:27 <sgordon> still more discussion on the above to have i suspect
14:59:42 <sgordon> feel free to move to #openstack-nfv to continue discussion banix vjardin russellb
14:59:51 <sgordon> whoops, bauzas not banix
14:59:52 <sgordon> :)
14:59:53 <vjardin> but got lost into the blueprints: https://wiki.openstack.org/wiki/Teams/NFV#Active_Blueprints which one are actives (yes Luke is). We'll continue later. thanks. Some BP are not NFV
15:00:01 <vjardin> Numa: why is it NFV?!
15:00:26 <sgordon> vjardin, infrastructure performance requirements driven by nfv appliances
15:00:33 <sgordon> nobody else actually requested it prior to this
15:00:36 <sgordon> #endmeeting