14:02:51 <sgordon_> #startmeeting nfv
14:02:51 <openstack> Meeting started Wed Sep 10 14:02:51 2014 UTC and is due to finish in 60 minutes.  The chair is sgordon_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:54 <openstack> The meeting name has been set to 'nfv'
14:03:00 <sgordon_> #link https://etherpad.openstack.org/p/nfv-meeting-agenda
14:03:05 <sgordon_> #topic roll call
14:03:11 <sgordon_> who is here for the nfv meeting...
14:03:15 <imendel> hey
14:03:17 <pczesno> hi
14:03:28 <sgordon_> sorry i am a few mins late
14:03:38 <beagles> `o
14:04:14 <sgordon_> no explicit action items were recorded last week so skipping straight into...
14:04:18 <adrian-hoban> Hello
14:04:19 <sgordon_> #topic juno status
14:04:32 <sgordon_> so there were two items with FFEs we discussed, NUMA and SR-IOV
14:04:44 <sgordon_> both could still theoretically land but the gate queue is enormous at this point
14:04:47 <sgordon_> ~18 hours
14:04:53 <sgordon_> and the cut off is friday
14:05:20 <ndipanov> sgordon_, so as for numa - likelu not to land
14:05:28 <sgordon_> #link https://review.openstack.org/#/q/status:open+project:openstack%2Fnova+topic:bp%2Fvirt-driver-numa-placement,n,z
14:05:34 <sgordon_> #link https://review.openstack.org/#/q/status:open+project:openstack%2Fnova+topic:bp%2Fpci-passthrough-sriov,n,z
14:05:48 <sgordon_> i would say looking at the patch list the sriov work is in the same position
14:06:03 <ndipanov> I've discussed it with other Nova folks - and they are of the opinion that if it's 1-2 patches they'll cut us some slack
14:06:04 <sgordon_> a lot of patchsets merged but not enough to give the full feature
14:06:18 <sgordon_> beagles, do you concur with my assessment i know you were following sriov
14:06:22 <ndipanov> but if it;s a lot more than that - we have to cut rc1
14:06:36 <sgordon_> #link https://launchpad.net/nova/+milestone/juno-rc1
14:06:42 <adrian-hoban> sgordon: What can be done to help better the outlook on these two?
14:06:44 <sgordon_> #link https://launchpad.net/neutron/+milestone/juno-rc1
14:06:55 <sgordon_> adrian-hoban, unfortunately at this point not much
14:06:57 <ndipanov> adrian-hoban, pray at this point really
14:07:21 <sgordon_> adrian-hoban, it's mostly twiddling thumbs, wait for it to get into the gate, verify whether failures are real or due to other race conditions etc
14:07:42 <sgordon_> adrian-hoban, at this point from doing that last step to the patch getting back to the top of the queue is around 18 hours
14:08:00 <beagles> sgordon_: there is a strong possibility you are correct.
14:08:29 <beagles> the patches themselves are in good shape, but there are a lot of variables that could interfere with them getting in by deadline
14:08:29 <sgordon_> i think owners, like ndipanov on the numa work, are pretty on top of getting the patches back in the queue asap but the time it's taking means we're quickly getting to the point where it's too late
14:09:14 <sgordon_> adrian-hoban, taking the longer term view have to continue to be involvement about how to better plan future releases
14:09:35 <sgordon_> adrian-hoban, e.g. the slots proposal, determining how features pushed out get (re)approved for the next release etc
14:09:48 <sgordon_> all fun stuff
14:10:27 <sgordon_> soo given that we're mostly at the thumb twiddling stage for things that could land i wanted to dedicate some time to discussing the issues imendel framed in an email recently
14:10:39 <adrian-hoban> sgordon: Yes indeed. Fun stuff and lots of hard work being put in by all involved
14:10:51 <sgordon_> #topic subteam future direction
14:11:03 <sgordon_> #link http://lists.openstack.org/pipermail/openstack-dev/2014-September/044614.html
14:11:08 <imendel> tnx...
14:11:09 <sgordon_> imendel's email is here ^
14:11:24 <imendel> happy to hear the team view
14:11:24 <sgordon_> some questions that were raised (and i am paraphrasing):
14:11:28 <sgordon_> Why (it) is special ?
14:11:28 <sgordon_> Why we need it now?
14:11:28 <sgordon_> Who will use it and why it can’t be achieve otherwise?
14:11:35 <sgordon_> where it of course is NFV
14:11:51 <sgordon_> and the questioner is arguably the wider openstack community
14:12:27 <sgordon_> i think one of the things ijw has raised in the path is that in many cases it is not necessarily special, versus some other use cases like HPC
14:12:33 <sgordon_> *past
14:12:36 <adrian-hoban> I think we also need to add "If/why/how the change needed by NFV also benefits the wider community?"
14:12:52 <sgordon_> #info Why (it) is special ?
14:13:02 <sgordon_> #info Why we need it now?
14:13:10 <sgordon_> #info Who will use it and why it can’t be achieve otherwise?
14:13:13 <imendel> right so for the wider community it's beneficial
14:13:16 <sgordon_> #info If/why/how the change needed by NFV also benefits the wider community?
14:13:20 <sgordon_> right
14:13:42 <imendel> I think that in most cases it's just true.
14:13:42 <sgordon_> so i think the wider benefit, and also "cloudiness" is more demonstrable on some nfv requirements than others
14:14:11 <imendel> agree and we need to descibe it as such
14:14:43 <sgordon_> we definitely need as a group to be sure that we are challenging ourselves to establish what level of control vs abstraction is required
14:14:59 <imendel> last week it was mentioned that the focus on the wiki might be wrong. What do you have in mind?
14:15:00 <sgordon_> rather than necessarily carrying over 1:1 "knobs" for want of a better word from existing systems
14:15:14 <sgordon_> i think the focus on the wiki is good for folks already versed in NFV
14:15:32 <imendel> agree on the abstraction. The numa is a good example
14:15:40 <sgordon_> i think the problem is that in terms of illustrating for wider community we did not ultimately come up with as many concrete examples that resonate
14:15:43 <imendel> what we need for the non NFV developers?
14:16:02 <sgordon_> ideally, user stories
14:16:22 <adrian-hoban> sgordon_: imendel: Yes, looking at NUMA, there is a real need in NFV, but also a real benefit for other workloads
14:16:22 <sgordon_> maybe personas to contribute the openstack personas efforts?
14:16:28 <sgordon_> i am just spitting out ideas here :)
14:17:00 <sgordon_> adrian-hoban, right - in particular for large VMs they are spanning numa nodes *today* but as there is no direction given by nova performance is not being optimized at all for it
14:17:02 <imendel> user stories are right personas too. But I woudln't framed those as NFv specific as then we are back to square one
14:17:35 <sgordon_> sure
14:17:47 <sgordon_> but there is a need to extend/add to existing user stories and personas
14:17:54 <sgordon_> otherwise nfv would already be being addressed no?
14:18:25 <sgordon_> there are really two challenges/ends to this
14:18:26 <imendel> Let's take the NUMA. The idea at the end is better use or optimisation of the existing resources
14:18:34 <imendel> in NFV it's (also) interesting
14:18:45 <sgordon_> on the one hand there is the overall user case
14:18:52 <sgordon_> on the other there are specific implementation proposals
14:18:52 <sgordon_> right
14:19:02 <sgordon_> but you will note the NFV spec etc was never positioned as being for NFV
14:19:21 <sgordon_> it's the ones that say "hey this is for NFV" in the spec without necessarily elaborating that i think are running into more issues
14:19:42 <imendel> but I saw claims that "I don't care about NFV", meaning I don't believe it's a real general need
14:19:56 <imendel> agree
14:19:58 <adrian-hoban> sgordon_: Good point, and the NUMA work has made it further than most of the others
14:20:18 <sgordon_> sorry meant *NUMA spec above
14:20:34 <sgordon_> so definitely within the scope of specific implementation proposals
14:20:35 <imendel> maybe we shall try to have (at least) one more use case per ask that is not NFV to make the point
14:20:48 <sgordon_> it is definitely necessary to illustrate why it is useful in the general case too
14:21:13 <sgordon_> in particular an aspect of this is explaining how it improves the default state for people who arent going to want/need to twiddle the knobs (if there are any)
14:21:31 <adrian-hoban> imendel: Perhaps that would be a good addition to our wiki. i.e. Add a column for non-NFV use case for each of the BPs
14:21:43 <imendel> yes
14:22:01 <sgordon_> #info Need to demonstrate usefulness of implementation proposals for general case, not just NFV (and NFV use case itself needs to be properly explained)
14:22:02 <beagles> I guess where we don't do selective column access of a row, there's no gain in to breaking data out of the blob and into column .. you are going to load it all anyways
14:22:07 <beagles> gah sorry
14:22:11 <sgordon_> beagles, good stuff
14:22:11 <sgordon_> ;)
14:22:31 * beagles blushes
14:22:32 <adrian-hoban> :-)
14:22:59 <imendel> from your experience. What is the right vehicle to address the developers and the core teams?
14:23:04 <sgordon_> #info Illustrate also how default state improves, what's the impact on people who wont twiddle any "knobs" exposed
14:23:20 <sgordon_> primarily the mailing list and their respective weekly meetings imo
14:23:48 <imendel> and there is a place there to represent the case, or it's all about implementation?
14:24:07 <sgordon_> design summit is challenging because sessions primarily relate to specific implementation proposals (although there is an effort to make them a little more like the midcycle meetings)
14:24:53 <sgordon_> imendel, i guess this comes back to what we were talking about earlier - it's easier to be a proponent of a specific implementation proposals or set of implementation proposals
14:25:10 <sgordon_> than high level use cases or personas
14:25:14 <imendel> so maybe we need to focus (maybe even assign responsibility) to each team?
14:25:20 <sgordon_> even though we arguably need both
14:25:31 <imendel> also agree we need both
14:25:35 <beagles> sgordon_ +1 - that was a big issue in SR-IOV. We tried to relate more "cloudy" labels to implementation but it was ... not productive.
14:25:50 <sgordon_> we have discussed before getting someone to at least report into each team's meeting
14:26:08 <imendel> and what was agreed?
14:26:15 <sgordon_> but the question has been report what, again outside of specific impl discussions
14:26:23 <sgordon_> we're well covered on the nova side
14:26:29 <sgordon_> not so much on the neutron side
14:26:37 <imendel> Heat/.
14:26:39 <imendel> ?
14:26:42 <sgordon_> none
14:27:06 <imendel> So maybe this is  good Action item for us...
14:27:07 <sgordon_> most of the focus within this group has been on nova/neutron so far, though there are heat and glance impacts as well
14:27:16 <imendel> yes
14:27:58 <imendel> as an example. The use of Sriov vie Heat. Is this loop closed? assuming sriov is in...
14:28:12 <sgordon_> no, because sriov itself hasnt landed
14:28:14 <imendel> besides other heat specific examples
14:28:31 <sgordon_> the heat project wont take the proposal to support it seriously until it exists
14:28:31 <imendel> understood.
14:28:43 <sgordon_> which is unfortunate but also fairly understandable
14:28:53 <sgordon_> given what will/wont land in other projects is so unpredictable
14:28:54 <imendel> so for Kilo it's the right timing, no?
14:29:02 <sgordon_> this however is a broader problem there is some discussion on
14:29:19 <sgordon_> there is an idea circulating on the list of having an openstack-specs process for cross-project efforts
14:29:44 <sgordon_> not sure if this is the right solution but difficulty in implementing cross project work at the same time is definitely an issue
14:29:44 <imendel> right. But maybe for specific and important needs we can try and close some loops, as a team.
14:30:17 <sgordon_> so for this specific example
14:30:23 <imendel> right. So maybe just focus on specific needs in Heat (or glance) that are relevant...
14:30:59 <imendel> On Neutron I thought we are "covered" with Chris
14:31:26 <sgordon_> chris is but one man :)
14:31:35 <sgordon_> nova and neutron are very large projects at this point
14:31:45 <imendel> anyway. Can we conclude some acrtions?
14:31:46 <sgordon_> #action sgordon identify heat and glance participants?
14:32:15 <sgordon_> imendel, would you be able to take writing a use case for sr-iov via heat?
14:32:27 <imendel> right.... :)
14:32:35 <sgordon_> basically what a user might expect to see/interact with at that level
14:32:38 <imendel> sure
14:32:49 <sgordon_> #action imendel to write a use case for sr-iov via heat
14:33:14 <sgordon_> #action sgordon to update on final sriov/numa status for juno next week
14:33:42 <sgordon_> #info Need to continue to follow discussion about how/when proposals for kilo might be handled
14:33:57 <imendel> do we want to take the action to better explain the use cases and the needs in the wiki, the summit, the mailing list and the mid term??
14:34:11 <imendel> per project?
14:34:21 <sgordon_> yes this is perhaps the most challenging one :)
14:34:42 <sgordon_> where do we want to start with this
14:34:53 <imendel> and to think when to aggregate and when to separate? at least as part of the thinking process..
14:35:01 <imendel> Maybe Paris...
14:35:25 <imendel> We can try and "declare" something
14:35:43 <imendel> in the spirit of what we just discuss...
14:36:27 <sgordon_> hmm
14:36:57 <imendel> what is the concern?
14:37:15 <sgordon_> well in terms of recording an action this is still very generic
14:37:29 <imendel> agree...:)
14:37:40 <sgordon_> is the action to define touch points with other projects, clean up the use cases in some way or declare to declare something in paris :)
14:38:11 <imendel> I thought the first two are the way to declare...
14:38:26 <sgordon_> ok
14:38:50 <sgordon_> #action sgordon_ to clear up project touch points on wiki page
14:39:03 <sgordon_> so that leaves the use cases and how we want to better handle them...
14:39:12 <imendel> unless you think we can have an NFV meeting with developers (cross projects) that can be attractive...
14:39:20 <imendel> to them
14:39:56 <sgordon_> not immediately
14:39:59 <sgordon_> perhaps over time :)
14:40:07 <imendel> ok...:)
14:40:17 <sgordon_> but then perhaps over time the need for a separate are to strategize/discuss will go away
14:40:22 <sgordon_> that is in some ways actually my hope
14:40:28 <imendel> my too
14:40:29 <sgordon_> that it will become more mainstream
14:40:33 <adrian-hoban> imendel: That would be a nice thing to have, particularly as a type of breakout or pod session...
14:40:41 <sgordon_> right
14:41:02 <sgordon_> apparently pod space is going to be pretty limited due to the venue but i think we should try do this again if at all possible
14:41:25 <imendel> adrian: how it works... sorry for my ignorance..
14:41:27 <sgordon_> #action sgordon_ aim to have a BoF session at a pod in paris if at all possible
14:41:33 <imendel> tnx..:)
14:43:25 <adrian-hoban> imendel: Design sessions are very focused, so I'm suggesting we need time to get the NFV focused community and the project communities together in a forum less focused on a single problem. Where we can talk about general topics and direction... THe BoF are good for this
14:43:54 <imendel> ok
14:46:25 <imendel> are we done?
14:47:58 <adrian-hoban> imendel: I think it's an open discussion next
14:48:09 <imendel> tnx
14:48:20 <adrian-hoban> I don't see anything else on the agenda
14:49:12 <adrian-hoban> Any opens?
14:50:19 <adrian-hoban> #topic opens
14:50:50 <bauzas_> adrian-hoban: you need to be chair for opening a new topic
14:50:53 <bauzas_> sgordon_: ^
14:50:58 <adrian-hoban> :-)
14:51:00 <sgordon_> sorry
14:51:04 <sgordon_> #topic open discussion
14:51:11 <adrian-hoban> Doh
14:51:14 <bauzas_> sorry folks, was lurking
14:51:23 <sgordon_> fwiw i am happy to make anyone else chair as well
14:51:27 <sgordon_> :)
14:51:39 <ndipanov> so - one thing that I got from the Juno effort is
14:51:40 <sgordon_> does anyone else have anything for this week?
14:51:45 <sgordon_> :D
14:52:10 <bauzas_> sgordon_: do you plan to see which time is good for the meeting ?
14:52:33 <bauzas_> sgordon_: IIRC, the alternative meetings was a temporary solution
14:52:46 <ndipanov> that adding some of these features at least to Nova has uncovered some problems in the codebase that we need to work on
14:52:58 <ndipanov> and the whole Nova team seems to be very serious about fixing those
14:53:00 <ndipanov> for K
14:53:03 <ndipanov> at least for now
14:53:07 <sgordon_> bauzas_, i am willing to give it a few more weeks
14:53:13 <bauzas_> sgordon_: sure thing
14:53:17 <sgordon_> bauzas_, i dont really have a clear read on which is better attended
14:53:26 <bauzas_> k
14:53:31 <sgordon_> it feels like i get similar response but from slightly different people involved
14:53:42 <bauzas_> ndipanov: +1, that will depend on if/when slots are implemented
14:53:45 <ndipanov> so in the spirit of communicating ideas clearly - I am thinking that the NFV interested parties should hear about those efforts
14:53:55 <sgordon_> #info nova is likely to require increased focus on technical debt in kilo, which will impact feature delivery
14:54:26 <ndipanov> sgordon_, but will also make it easier in the future
14:54:37 <ndipanov> hopefully
14:54:43 <bauzas_> :)
14:54:56 <ndipanov> bauzas_, I would not rely on a single idea like slots to solve any issues
14:54:59 <adrian-hoban> Is this an approach that is likely for other projects too?
14:55:05 <ndipanov> this is a massive effort
14:55:12 <ndipanov> and slots will not just magically solve it
14:55:19 <sgordon_> adrian-hoban, unclear
14:55:20 <ndipanov> we need actual hands on it
14:55:25 <bauzas_> ndipanov: yeah, I was just saying that slots could impact dramatically the feature delivery
14:55:39 <ndipanov> bauzas_, imho that is not a good way to put it
14:55:39 <sgordon_> as we touched on last week nova has some specific areas where if you are touching them your feature is basically in trouble
14:55:41 <sgordon_> particularly scheduler
14:55:49 <ndipanov> what impacts feature delivery is debt we have in Nova
14:56:18 <bauzas_> ndipanov: well, you know my opinion too, I think it's a velocity problem, not a prioritization problem
14:57:08 <sgordon_> debatable
14:57:12 <ndipanov> what I am saying is that we should se NFV as being the main driver for the changes
14:57:24 <sgordon_> i think you could easily say the velocity problem results from the prioritization one
14:57:25 <bauzas_> sgordon_: indeed
14:57:31 <ndipanov> not something that will be cast aside while we go and polish our nice nova
14:57:44 <ndipanov> s/se/see
14:58:03 <bauzas_> sgordon_: well, see the ratio patch/reviewers
14:58:29 <ndipanov> bauzas_, but this is not the place for this discussion really imho
14:58:33 <sgordon_> +1
14:58:33 <ndipanov> sgordon_,
14:58:36 <sgordon_> time to close it out
14:58:38 <sgordon_> #endmeeting