20:00:59 <ttx> #startmeeting tc
20:00:59 * devananda lurks
20:00:59 <annegent_> o/ here
20:01:00 <openstack> Meeting started Tue Feb 23 20:00:59 2016 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:02 <russellb> thanks (sorry, was supposed to be in the air for this, delays)
20:01:04 <openstack> The meeting name has been set to 'tc'
20:01:12 <ttx> Hi everyone! I made it back from snowland
20:01:20 <flaper87> ttx: in how many pieces ?
20:01:24 <ttx> We have a pretty long agenda for today, not sure we'll get to the bottom of it...
20:01:28 <ttx> flaper87: single piece!
20:01:31 <jeblair> ttx: welcome back!
20:01:34 <flaper87> ttx: good good!
20:01:35 <annegent_> welcome back!
20:01:41 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:42 <thingee> o/
20:01:44 <mestery> No way we make it through the agenda, but lets try!
20:01:49 <Keedya> Safe trip!!
20:01:50 <ttx> #topic Propose an update to the OpenStack mission statement.
20:02:02 <ttx> Let's start with this item as it may be helpful for Russell to push it at the board meeting
20:02:04 <russellb> this is on the board meeting agenda for right after this as well
20:02:04 <ttx> (or not)
20:02:16 <ttx> Personally I think that wording still fills the objective we had (adding "interoperability" and "users")
20:02:25 <ttx> #link https://review.openstack.org/281463
20:02:26 <annegent_> yep
20:02:26 <dougwig> timebox?
20:02:39 <flaper87> I'm good with the wording
20:02:39 <ttx> I think we can approve it now, has enough votes
20:02:51 <russellb> lots of +1s, no -1s, yay
20:02:52 <mestery> ++
20:02:56 <flaper87> w00h000
20:02:56 <sdague> it's got 9 +1s so far, and I think everyone that spoke up in the thread has voted here
20:02:56 <russellb> thanks
20:02:58 <ttx> unless someone wants to try to convince most of the current +1s
20:03:04 <dhellmann> o/
20:03:05 <flaper87> russellb: thanks for working on that
20:03:05 <ttx> to switch
20:03:13 <russellb> i just did the paperwork
20:03:14 <ttx> ok, approving in 30 seconds
20:03:19 <russellb> thanks to several others for nice work on the wording
20:03:42 <ttx> ok, it's in
20:03:49 <annegent_> sweet
20:03:51 <russellb> hopefully the board will be happy this time
20:03:53 <ttx> russellb: you can bring it to the board meeting now
20:03:57 <russellb> thanks
20:03:57 <annegent_> russellb: thanks for taking it across the finish line
20:04:12 <lifeless> o/
20:04:16 <ttx> russellb: yes, thanks russellb
20:04:22 <russellb> np :)
20:04:23 <ttx> #topic Add project Dragonflow to OpenStack big-tent
20:04:29 <ttx> #link https://review.openstack.org/277153
20:04:37 <ttx> It's more of a governance clarification than a project addition, so I'm +1 on this
20:05:05 <russellb> i hadn't voted on the latest one, added +1
20:05:06 <ttx> or as I said on the review, "unless we think it was a complete mistake for the Neutron team to accept it under the Neutron stadium, we should accept it here"
20:05:08 <sdague> right, this was part of neutron, now it stands on it's own, right?
20:05:16 <russellb> yes
20:05:20 <russellb> it's a neutron backend
20:05:21 <sdague> ship it
20:05:22 <ttx> sdague: yes
20:05:23 <russellb> is the tl;dr
20:05:43 <ttx> ok, we have 7 +1s. Objections ?
20:05:51 <mestery> No objections here
20:05:58 <markmcclain> none from me
20:06:01 <jaypipes> nope.
20:06:01 <sdague> importantly we have 7 +1s, including all the network specialists
20:06:06 <ttx> yep
20:06:08 <dhellmann> ttx: I think we're going to have to be very careful with these neutron spin-outs given the recent open-core analysis for poppy
20:06:18 <markmcclain> dhellmann: ++
20:06:21 <russellb> sure.
20:06:21 <annegent_> dhellmann: agreed
20:06:26 <dhellmann> it doesn't apply here, but something that only works if you've bought equipment from someone...
20:06:27 <russellb> in this case, all the code is dragonflow itself
20:06:31 <russellb> right
20:06:32 <ttx> dhellmann: yes, but I don't think dragonflow (or kuryr) are in the grey area
20:06:35 <jaypipes> dhellmann: s/neutron spinouts/all projects applying for big tent/
20:06:46 <mestery> The open core discussion pops up earlier than I would have thought
20:06:52 <ttx> approving now
20:06:57 <mestery> dragonflow and kuryr are not open core
20:07:03 <dhellmann> jaypipes : yes, though my impression of the number of spin-outs from neutron with a high chance of encountering that issue is greater than average
20:07:16 <ttx> #topic Add project Kuryr to OpenStack big-tent
20:07:18 <russellb> i don't even know what the spin outs are going to be yet
20:07:20 <dougwig> dhellmann: it is. there are a lot of networking-bigphathardware repos.
20:07:21 <dhellmann> mestery : right, I don't think so. I'm just pointing out a side-effect of that other discussion
20:07:26 <ttx> #link https://review.openstack.org/280522
20:07:35 <ttx> I think this is the same case as Dragonflow
20:07:36 <mestery> Hard to argue against Kuryr being added here
20:07:37 <markmcclain> this one already has 10 +1s too
20:07:38 <russellb> kuryr is an easy one for me
20:07:38 <mestery> Right
20:07:39 <ttx> might even be easier
20:07:40 <mestery> Easy one
20:07:45 <mestery> Ship it ttx!
20:07:50 <ttx> shipping
20:07:52 <flaper87> neeeeeeext
20:08:06 <ttx> next should likely trigger more discussion
20:08:11 <dougwig> 3 agenda items and no bikeshedding.  is a virus going around or something?
20:08:15 <ttx> #topic Vote on whether Poppy is open core or not
20:08:20 <ttx> #link https://review.openstack.org/278247
20:08:20 <flaper87> dougwig: sssshh
20:08:26 <russellb> dougwig: saving up energy for other stuff
20:08:30 <ttx> So... Poppy raised non-technical and technical issues. The latter could be fixed before inclusion.
20:08:42 <ttx> But since it's unfair to ask them for technical changes if we intend to reject them on non-technical changes anyway, this review was calling for an early determination on the non-technical issues
20:08:49 <russellb> i'm not sure "open core" is the right term, but i still don't think this is openstack
20:08:51 <ttx> It feels like there are now 3 parties on this one
20:08:55 <sdague> russellb: ++
20:09:07 <ttx> The first one looks at the "how" and says Poppy's team behaves like an OpenStack project, its intentions are pure and it's a useful project, and therefore it should be allowed in (that would be mordred, dhellmann, jeblair, flaper87 and markmcclain)
20:09:12 <mestery> russellb: ++
20:09:22 <ttx> The second one looks at the "what", sees the lack of open source reference implementation, and considers it should therefore be rejected under our current understanding of the "no open core" requirement (that would be sdague, russellb and mestery)
20:09:26 <edleafe> not being open core isn't enough to make it openstack
20:09:42 <ttx> The third party looks at the "why". While it considers Poppy can't really be considered "open core" in any way, it looks at Poppy's mission, which is to proxy to external non-OpenStack cloud services, and considers that it's not what "OpenStack" mission is (that would be dtroyer, jaypipes, annegentle and me)
20:09:59 <ttx> The "why" and "what" parties add up, so NO leads 7-5 at this stage
20:10:09 <russellb> nice summary
20:10:12 <flaper87> yup
20:10:14 <sdague> I would also consider myself part of group 3
20:10:25 <sdague> but we didn't get multi select :)
20:10:29 <ttx> sdague: heh
20:10:34 <ttx> 2 and 3
20:10:35 <mestery> sdague: I'm also in group 3 :)
20:10:36 <dhellmann> sdague : yeah, no voting twice :-)
20:10:48 <flaper87> I guess that's the result
20:10:49 <annegent_> heh sdague :)
20:11:19 <ttx> Unless someone wants to make a case to move the lines, feels like No wins. Who didn't vote yet ?
20:11:22 <ttx> lifeless
20:11:32 <lifeless> hai
20:11:33 <flaper87> One thing I want to make sure is that we don't kick the project out of the openstack organization
20:11:36 <sdague> I feel like all the words that are going to be said have been. People were pretty expressive in the reviews.
20:11:39 <ttx> hi! Where do you side ?
20:11:49 <ttx> I'd like to say that my NO is pretty weak. I could survive a Yes
20:11:56 <lifeless> I'm certainly no *as it stands*
20:11:58 <jeblair> sdague: i agree
20:12:06 <flaper87> I don't remember who said that or where I read that but I just want to make sure the project is allowed to stay in the organization and use CI resources
20:12:13 <lifeless> I think the what aspects can be addressed, if the team chooses
20:12:16 <ttx> lifeless: on this review we are saying "No even if they fix things"
20:12:17 <annegent_> flaper87: same here
20:12:22 <sdague> flaper87: yes, agreed
20:12:26 <dhellmann> flaper87 : yes, I don't think that's in question
20:12:29 <jeblair> lifeless: i think we're only focusing on the 'soft' aspects right now
20:12:33 <ttx> so a yes here doesn't mean an immediate addition
20:12:38 <anteaya> flaper87: the project is not in danger of losing access to ci resources
20:12:50 <flaper87> coolio, I just remember reading it and pulled my hair off
20:12:59 <jeblair> lifeless: i am 'no' because of other issues (that poppy can fix)
20:13:15 <dhellmann> jeblair, lifeless : ditto
20:13:19 <jeblair> it is worth being clear on that (and i do think the change is clear on that)
20:13:39 <mestery> So how to proceed? Unless people are changing votes this looks like it won't make it.
20:13:41 <flaper87> All that said, I think this was an awesome case for us to use as reference in the future. Lots of study and discussions happened and although I'm on the Yes side, I think the result shows a good community work on finding the answer for such hard question
20:13:43 <ttx> I think everyone agrees that Poppy shouldn't be accepted today. The question is... we shouldn't list the gaps if we intend to reject them anyway
20:14:23 <mestery> The 7-5 vote here makes it seem like that's the case
20:14:27 <annegent_> I think a natural next extension of that good discussion is "what does purposeful expansion look like?"
20:14:30 <ttx> mestery: If this is rejected, the other one should be rejected too
20:14:32 <sdague> ttx: agreed, that just seems like extra work that's not useful
20:14:33 <annegent_> but I don't want to conflate yet
20:14:40 <mestery> ++
20:15:02 <ttx> I guess they could reapply one day if they feel the lines have moved
20:15:19 <flaper87> or if an open source solution is created
20:15:21 <ttx> but as they stand today, they can be hosted under openstack infra, but should not become an official project
20:15:40 <lifeless> ok, words said, +1 voted
20:15:47 * ttx reads
20:15:57 <lifeless> error server unavailale.
20:15:59 <lifeless> thanks gerrit
20:16:12 <mestery> lol
20:16:12 <flaper87> lifeless: lol
20:16:21 <lifeless> right, there
20:16:23 <ttx> if you vote +1, that makes it a pretty weak decision, especially considering how strongly I feel about a NO vote
20:16:39 * flaper87 is having a deja-vu
20:16:44 <annegent_> lifeless: hah
20:16:45 <ttx> so maybe we should decide to reject them today but consider revisiting next cycle
20:16:50 <sdague> I think we decide and move on
20:16:51 <flaper87> It feels a lot like Zaqar days but different topic :P
20:17:01 <flaper87> ttx: decide, move on
20:17:18 <ttx> alright, I'll abandon this review
20:17:19 <russellb> they can re-apply later if they want
20:17:19 <flaper87> I guess I'd rather have a weak rejection than a weak addition
20:17:24 <sdague> because there were votes that flip to -1 on the second patch which were +1 on the first
20:17:27 <russellb> if sands shift
20:17:48 <flaper87> I've been on both sides now and even when Zaqar was rejected, the weak rejection made more sense
20:17:57 <ttx> We should reapply our -1s on https://review.openstack.org/273756 as well
20:18:02 <mestery> ++ to possibly re-applying later
20:18:29 <lifeless> flaper87: your -1 seems to be entirely pragmatic - 'we can't test this'
20:18:46 <ttx> #link https://review.openstack.org/273756
20:18:52 <flaper87> lifeless: I +1'd it
20:18:57 <dhellmann> I'm not sure why we would encourage them to reapply until there was a way to solve the issues for the open core folks, or the "not just a proxy" folks.
20:18:59 <flaper87> lifeless: mmh
20:19:03 <lifeless> flaper87: ah, cool
20:19:08 <flaper87> lifeless: :P
20:19:20 <lifeless> flaper87: oh, nick confusion actully :)
20:19:48 <flaper87> dhellmann: ++
20:20:31 * russellb boarding plane ... sorry
20:20:40 <flaper87> russellb: take care
20:20:41 <sdague> ok, next topic?
20:20:44 <annegent_> travel safe russellb!
20:20:46 <russellb> 403063
20:20:48 <annegent_> safely? I dunno.
20:21:08 <flaper87> annegent_: "make sure you land" works too
20:21:11 <anteaya> annegent_: I use travel safe
20:21:19 <flaper87> ttx: ?
20:21:22 <dougwig> flaper87: landing is guaranteed.
20:21:29 <flaper87> dougwig: lol
20:21:37 <annegent_> ha
20:21:43 <ttx> redacting the answer
20:21:49 <lifeless> dougwig: *stopping* is guaranteed...
20:21:57 <ttx> I just abandoned the main Poppy review
20:22:00 <lifeless> dougwig: landing is more narrowly defined :)
20:22:19 <ttx> Alright, next topic
20:22:33 <ttx> #topic Applying Tacker for Big Tent
20:22:38 <ttx> #link https://review.openstack.org/276417
20:22:42 <ttx> Another difficult edge case here...
20:22:50 * russellb delays getting on
20:22:50 <ttx> I'm leaning towards yes at this stage, for the reasons outlined in my review comment
20:23:13 <annegent_> I'll be honest, that one has me struggling to understand. Is it docs/ref arch? Or code?
20:23:14 <russellb> it's another IaaS+ like project, focused on some NFV use cases, they have good intentions around integration
20:23:16 <russellb> seems fine to me
20:23:23 <russellb> code
20:23:27 <ttx> but again I could survive the opposite result, and some people fell a lot more strongly about this than I seem to do
20:23:35 <ttx> feel*
20:23:49 <ttx> I think we should still list a set of integration gaps that we'd like them to fill before/after being approved though
20:23:50 <dhellmann> russellb : if the integration isn't done, is the project mature enough to be official?
20:23:51 <annegent_> do we have a jaypipes?
20:24:04 <markmcclain> I think I'm only negative vote... my concern is the lack of proper integration
20:24:07 <annegent_> ttx: that would help, yeah
20:24:15 <ttx> markmcclain: no; jaypipes was pretty vocal
20:24:32 <annegent_> heh right markmcclain that's why I'd like to hear more from jaypipes
20:24:33 <markmcclain> ttx: ah right
20:24:40 <jaypipes> annegent_: yes, I am here :)
20:24:50 <jaypipes> annegent_: what more would you care for me to expand on?
20:24:53 <mestery> They have plans for integration which I'm comfortable with
20:25:02 <mestery> I think jaypipes concerns are more interesting here
20:25:04 <mestery> E.g. "Is this really OpenStack?"
20:25:15 <markmcclain> mestery: plans are great would just like to wait for execution of them
20:25:32 <flaper87> markmcclain: FWIW, we've let other projects with "plans" in
20:25:35 <mestery> Right
20:25:50 <flaper87> And those plans have been executed, AFAIK.
20:25:58 <anteaya> have they?
20:26:02 <flaper87> I don't see why we should block Tracker on that
20:26:03 <markmcclain> flaper87: but those projects already some level of integration
20:26:11 <anteaya> thingee has been doing work on this with some projects
20:26:21 <lifeless> explain to me again how this isn't neutron's advanced services?
20:26:22 <jaypipes> flaper87: it's Tacker.
20:26:29 <annegent_> jaypipes: if we rejected anything on "simple to implement" the list would be long :)
20:26:38 <jaypipes> annegent_: indeed.
20:26:41 <ttx> Personally I think enabling the NFV use case is a part of making a ubiquitous cloud computing platform. I'd prefer if the glue code lived in the consumer side, but as it stands I think it will end up being better integrated if official than if non-official
20:26:56 <mestery> ttx: Well said
20:27:05 <dhellmann> mestery, flaper87 : I'll repeat my question for you then since I think russellb boarded his flight: If the integration isn't already done, how much of this exists and how much is a plan? Is it mature enough to be official?
20:27:17 <jaypipes> ttx: OK, I will add my purpose-built business application orchestrator to OpenStack then.
20:27:17 <annegent_> jaypipes: also is it NFV MANO that is the distinct issue for you?
20:27:35 <mestery> dhellmann: Did you read Sridhar's comment? They have shifted priority to make the integraiton the thing they are doing right now (I haven't looked to see if it's merged yet)
20:27:43 <mestery> "@Russell - For the record, we don't have any code in our repo today that circumvents neutron. For our upcoming efforts, we have rearranged our tasks such that neutron integration will happen first [1]. For any integration with SDN Controllers (like ODL) we will go through neutron. This should address the concerns related to neutron integration. "
20:27:44 <russellb> just got back on sirry
20:27:46 <russellb> they do have some integration (uses Heat)
20:27:48 <russellb> the network side isn't done, but it's not that it doesn't exist
20:27:48 <mestery> From Sridarh in hte review
20:27:52 <mestery> Right
20:27:57 <mestery> russellb: See my ^^^ pasted above
20:28:01 <lifeless> the bit that worries me specifically is 'tacker will use neutron-sfc as the default underlying sfc of choice'...
20:28:06 <flaper87> dhellmann: my understanding, from russellb's research and comments, is that it's mature enough. I don't think my knowldege about networking and neutron is broad enough to be 100% sure but yeah, I think it's mature enough
20:28:08 <dhellmann> mestery : ok, but we've typically rejected projects that say "right now I'm going to build something that doesn't exist, it should be official"
20:28:10 <lifeless> like, if its part of openstack, why is that going to be pluggab;e ?
20:28:30 <ttx> jaypipes: what does MANO mean already ? I'm lost in acronyms again
20:28:31 <jaypipes> annegent_: it is the purpose-built part that shapes the direction and customs of OpenStack towards NFV specificity (for the worse) that concerns me. That, and the fact that it's a monolithic application that should, by nature, live in the application ecosystem.
20:28:44 <jaypipes> ttx: welcome to telco. management and orchestration.
20:28:48 <dhellmann> lifeless : good point, what other options are there?
20:28:58 <russellb> i don't think it shapes anything when it's a separate optional projcet that most wont' have to use/care about
20:29:11 <annegent_> MANO MANagement & Orchestration
20:29:17 <mestery> lifeless: You could bypass Neutron completely and use some bizzare ODL SFC API
20:29:27 <mestery> lifeless: That appears to be what they WERE doing with POC code
20:29:28 <russellb> re: "is NFV MANO" in scope, i tihnk that question should be more broad about where we want to draw the line for openstack
20:29:31 <dhellmann> annegent_ : maybe you and I can teach some network vendors words instead of acronyms
20:29:33 <russellb> and this review shouldn't become the proxy battle
20:29:35 <mestery> My understanding is they abanonded that
20:29:43 <annegent_> dhellmann: srsly
20:29:50 <anteaya> dhellmann: ++
20:29:57 <russellb> several vendors are bypassing openstack and neutron to do this
20:29:59 <lifeless> mestery: sure - on a technical level. I'm trying to understand how that makes sense - it would be like Nova bypassing keystone and using kerberos directly
20:30:00 <sdague> dhellmann: I don't think that's possible
20:30:01 <markmcclain> annegent_: that should be vsrsly
20:30:04 <russellb> at least they're trying to do some unification
20:30:07 <jaypipes> russellb: I understand your viewpoint. I just happen to disagree. I ask you to ponder my question of what you would think if I proposed a Let's-Orchestrate-Jaypipes-Website-Topology application to OpenStack.
20:30:11 <mestery> lifeless: Right, that's why they abanonded that approach
20:30:25 <ttx> jaypipes: So the alternative is to let it live outside of OpenStack (hosted on OpenStack infra since OpenNFV doesn't have code). I just feel like it won't be as deeply integrated as it should be though, resulting in an inferior integration
20:30:25 <annegent_> russellb: bypass might be perfectly okay to not overload OpenStack though.
20:30:33 <lifeless> mestery: the words from sirdhar leave me feeling unsure that they *have* abandoned it
20:30:38 <russellb> annegent_: i'd argue bypass makes openstack irrelevant
20:30:46 <mestery> jaypipes: Your concerns are the ones that make me thinkg to be honest
20:30:50 <sdague> ttx: in what way? Isn't it only using published APIs
20:30:52 <russellb> part of our mission is creating useful abstractions
20:31:07 <mestery> The question of "is this openstack" is something I *think* I can answer as yes, but I could be swayed the other way too
20:31:09 <ttx> sdague: it could use more of Heat, iiuc
20:31:14 <russellb> jaypipes: i hear you, i look at it more like Magnum, or trove, or murano, or some other orchestration level projcet
20:31:17 <sdague> ttx: how?
20:31:32 <russellb> jaypipes: i guess i don't see how this crosses the line but those don't
20:31:34 <mestery> russellb: Those are good comparisons
20:31:36 <jaypipes> ttx: I do not want to be held hostage by the telco community threatening to run away and play in their own sandbox and fork OpenStack, true. but I'm wary of getting telco-specific components in OpenStack that lead us down a slippery slope.
20:31:41 <sdague> I actually don't understand how you can use more / less of Heat, or Neutron if you are part of openstack or not
20:32:02 <russellb> sdague: re: Heat, particularly around VM monitoring and failure recovery
20:32:13 <sdague> less of openstack might directly consume you if you are not openstack
20:32:15 <russellb> Heat is working in that domain, they've started an early approach of their own, which we discussed in the review
20:32:16 <jaypipes> russellb: magnum, murano, and trove are not purpose-built for one industry.
20:32:16 <sdague> but not the other way around
20:32:31 <lifeless> how does this compare with akanda btw ?
20:32:37 <ttx> sdague: what russellb said
20:32:42 <dhellmann> lifeless : lots of overlap
20:32:53 <russellb> jaypipes: this is useful beyond telco IMO
20:33:05 <russellb> it's a more generally useful network thingy to me
20:33:15 <russellb> NFV is the driver, but it's not *only* applicable there
20:33:25 <sdague> hmmm... I guess if you have to be OpenStack to use Heat to it's fullest, that seems like a different problem
20:33:26 <russellb> very applicable to enterprise security
20:33:46 <jaypipes> russellb: name one application outside of telco.
20:34:21 <flaper87> Do we have Tracker folks around?
20:34:29 <ttx> sdague: no, my point is, we can encourage smarter integration with OpenStack if it's under the TC's oversight, and we don't have that much influence to get them to do the right things if they are merely hosted under openstack infra
20:34:32 <mestery> flaper87: No, but we have Tacker folks around I bet ;)
20:34:32 <sridhar_ram> flaper87: I'm here...
20:34:38 <mestery> sridhar_ram: Howdy :)
20:34:46 <ttx> sdague: it's arguably a pretty weak argument
20:34:48 <russellb> jaypipes: a more complex firewall that does deep packet inspection
20:34:54 <russellb> is not a telco specific thing
20:34:58 <jaypipes> russellb: enterprise security would *consume* the telco VNFs that would be orchestrated by Tacker, though. that doesn't make Tacker not telco-specific.
20:35:02 <ttx> sdague: as I said elesewhere, I'm a bit on the fence on this one, just leaning towards yes
20:35:25 <russellb> it's definitely "networking services" specific
20:35:26 <jeblair> jaypipes: what makes them telco-specific at that point?
20:35:29 <annegent_> sdague: jaypipes: yeah the orchestration part is an interesting parallel but frankly that decision was made already, that orchestration works better when teams/projects work together.
20:35:33 <russellb> and i see that more broad than telco
20:35:40 <flaper87> sridhar_ram: hey, thanks for joining. It'd be useful for you to help clarifying some of the questions floating around
20:35:44 <sridhar_ram> IMO we don't have a overlap w/ Astara as it is just an neutron backend.. our scope is beyond simple advanced service, into things like vIMS, vEPC, etc
20:35:52 <lifeless> oh yeah, I remember, akanda -> astara
20:35:55 <ttx> jeblair: it's more tailored to telco needs than telco-specific I think
20:36:16 <mestery> ttx: Well said
20:36:25 <russellb> sure.
20:36:27 <dhellmann> sridhar_ram : you're going to have to remember that most of us have no idea what the acronyms in this space mean. I, at least, don't know what you just said about "vIMS..."
20:36:39 <ttx> others could use it. But they would have to enter that weird mindset first :)
20:36:45 <sdague> annegent_: sure, I guess, I think that if we think moving 1 bit causes collaboration between teams, we over estimate our influence :)
20:36:50 <flaper87> dhellmann: that makes it 2 of us
20:36:55 <annegent_> sdague: heh too true
20:36:57 <lifeless> sdague: +1
20:36:58 <sridhar_ram> IMO tacker has the tents of a Template base lifecycle orchestrator.. this has benefits beyond telco but our initial focus is definitely telco operators
20:36:59 <russellb> imagine VPNaaS, FWaaS, LBaaS ... this is a more generic solution to that, for networking service of your choice
20:36:59 * flaper87 barely knows what an IP address is
20:37:22 <dougwig> ttx: i'm not sure NFV is that weird a mindset once you're virtualizing your network. it's just the next step.
20:37:24 <russellb> create Nova instances that do *stuff* to packets
20:37:33 <lifeless> flaper87: on the internet, noone knows if you are an ip address
20:37:46 <ttx> sdague: in particular tacker could be turned into something more like service-VMs as a service, and I see being official (and under TC oversight) as a way to encourage that
20:37:46 <markmcclain> russellb: you just described Astara
20:37:54 <flaper87> lifeless: lol
20:37:55 <mestery> dougwig : ++
20:38:00 <russellb> markmcclain: no i didn't, astara doesn't provide an API
20:38:11 <sridhar_ram> dhellmann: I'm w/ you :) these a complex "applications" that include 7 - 8 VMs that needs to be deployed, monitored, scale, etc
20:38:19 <russellb> and the overlap argument is weak when you argued that it wasn't an issue to get astara accepted in the first place
20:38:19 <mestery> markmcclain: I'm personally fine with having overlap in this space, as it's an outer ring type of thing
20:38:20 <dhellmann> russellb : astara uses neutron's api
20:38:28 <russellb> dhellmann: public API
20:38:32 <mestery> E.g. Octavia does some of this too
20:38:37 <mestery> russellb: ++
20:38:39 <lifeless> dougwig: its not even the next step - its just much more generic than e.g. wccp
20:38:43 <dhellmann> russellb : yes, it responds to things that happen when you call neutron's api
20:38:53 <russellb> right, this is a new API on top of neutron and nova
20:39:03 <sdague> ttx: maybe, again, I think you overestimate TC influence on such things :) Honestly, I'm on the fence. I see there are some strong opposes and that tends to give me pause.
20:39:05 <russellb> to orchestrate neutron and nova resources to create new networking things
20:39:22 <lifeless> sdague: FWIW I'm not opposing, I'm still trying to really grok what we're being asked
20:39:23 <dougwig> mestery: indeed it does. NFV is not a space where we'd want to pick just a single horse, imo.
20:39:35 <lifeless> my biggest concern is that this is being defined by a not-openstack-group
20:39:46 <jaypipes> russellb: I'm very supportive of efforts to standardize and make granular the REST API services that applications like Tacker would use in its application logic. Those low-level REST APIs are, to me, part of OpenStack. I don't see a purpose-built application that calls OpenStack APIs "part of OpenStack" though. If that is the condition that furthers the mission of OpenStack, then we will inevitably see an influx of
20:39:46 <jaypipes> OSS/BSS systems from telcos be proposed into OpeNStack. I can guarantee that.
20:39:53 <russellb> argh, flight attendent making me shut down
20:40:01 <jaypipes> heh :)
20:40:02 <mestery> russellb: Nooooooo!
20:40:06 <annegent_> :)
20:40:13 <russellb> jaypipes: i'd love to have a more general debate about where we draw that line
20:40:15 <sridhar_ram> russellb: stay on, please
20:40:20 <sridhar_ram> :)
20:40:22 <lifeless> russellb: what sort of repressive regime are you flying on!
20:40:26 <russellb> delta!
20:40:29 <anteaya> sridhar_ram: he risks being removed from the plane
20:40:31 <annegent_> let the flight attendant do their job! :)
20:40:32 <anteaya> been there
20:40:33 * flaper87 knew it was delta
20:40:41 <russellb> bye
20:40:49 <lifeless> ciao
20:40:52 <sridhar_ram> annegent_: I'm trying to having him kicked ;-)
20:41:09 <annegent_> sridhar_ram: :)
20:41:09 <anteaya> sridhar_ram: he is advocating for your patch
20:41:16 <thingee> jaypipes: +1
20:41:20 <anteaya> so that is an odd choice you make
20:41:22 <lifeless> sridhar_ram: so tell me about the governance
20:41:30 <jeblair> anteaya: that's why he wants him off the plane so he can stay in the meeting
20:41:47 <ttx> sridhar_ram: could you describe in your own words how being part of OpenStack (vs. just being hosted under openstack infra) would benefit Tacker ?
20:42:02 <dhellmann> ttx, sridhar_ram : also benefit OpenStack
20:42:04 <sridhar_ram> another way to look at this ... if an NFV operator need to do "NFV" on OpenStack today he need to go through a DIY across nova, heat, etc.. just makes it easy to do NFV on OpenStack
20:42:16 <jaypipes> dhellmann: vEPC == virtual evolved packet core. vIMS == virtual internet media services (or something like that...
20:42:26 <annegent_> oh thank you jaypipes
20:42:26 <ttx> It appears that the main tension here is that this is a business application consuming OpenStack, so it's not OpenStack
20:42:32 <mestery> jaypipes: You've been doing your homework my friend
20:42:36 <dhellmann> jaypipes : maybe switching to words is pointless, I still don't know what any of that is :-)
20:42:40 <lifeless> sridhar_ram: well they don't - they can use e.g. astara (not astara-neutron, thats only a subset, astara itself is rather more)
20:42:44 <jaypipes> dhellmann: :)
20:42:45 <sridhar_ram> IMO this is biggest blocker in having someone consume OpenStack for NFV
20:42:51 <ttx> jaypipes.com, reverse acronym proxy
20:42:55 <dtroyer> ttx +++
20:43:05 <sridhar_ram> lifeless: Astara is just a neutron backend.. that doesn't cut it for NFV operators..
20:43:15 <sridhar_ram> NFV / VNF != Neutron..
20:43:21 <mestery> lifeless: I don't see why we'd force them to do that, I think having competition at this layer of the stack is fine
20:43:22 <lifeless> sridhar_ram: Perhaps markmcclain can comment more, but that doesn't match my understanding of Astara
20:43:23 <thingee> dhellmann: not sure how you've gone all this time without your VEPC's and your vIM's.
20:43:23 <sridhar_ram> their world is bigger ...
20:43:24 <annegent_> the biggest blocker is complexity I believe... and this is certainly complexity
20:43:24 <mestery> Again, see Octavia
20:43:38 <dhellmann> thingee : I'm a luddite.
20:43:50 <markmcclain> sridhar_ram: not true... Astara implements a backend for neutron, but is actually a pluggable orchestrator of network services
20:43:51 <devananda> we have some OpenStack applications already that orchestrate calls to other OpenStack APIs to create complex application-specific resources from them -- Heat, in the general sense. Trove and Magnum and Sahara, in the specific sense.
20:43:51 <lifeless> mestery: I'm probably fine with it too, but I want clarity on the discussion, and claiming there isn't overlap when markmcclain is claiming there is means we don't have clarity
20:44:02 <mestery> I also fail to see why we'd not let Tacker in but we let Magnum in
20:44:04 <mestery> But maybe that's just me
20:44:20 <dhellmann> devananda : as pointed out earlier, those feel more general purpose
20:44:21 <devananda> I'm missing the way that Tacker is different from all those projects that run on top of the IaaS layer
20:44:24 <lifeless> mestery: (again, I'm not positioning this to say -1, but to actually know what I'm voting on)
20:44:32 <mestery> lifeless: Good man :)
20:44:54 <sridhar_ram> We are missing a standards based Template based orchestrator in NFV operators..
20:44:57 <ttx> So I understand why Jay opposes it -- business-specific glue code that lets an industry leverage OpenStack should not be considered part of OpenStack.
20:44:58 <lifeless> so I'd really like to have a discussion where markmcclain and sridhar_ram are both singing the same hymns
20:45:02 <devananda> dhellmann: how is tacker less general purpose?
20:45:17 <ttx> Not sure I understand why markmcclain opposes it, except overlap with Astara
20:45:26 <mestery> lifeless: Why? Again, I think competition at this layer is ok
20:45:27 <sridhar_ram> we can't have them have them go through Nova extra_spec, neutron-sfc API, Heat APIs...etc
20:45:28 <flaper87> ttx: ++
20:45:32 <lifeless> because - the thing I'm *actually* worried about with tacker is that it won't be controlled by the openstack community
20:45:35 <dhellmann> devananda : the assertion was made that only telco operators would have any real interest in it? I'm still trying to understand if that's true.
20:45:35 <lifeless> mestery: ^
20:45:36 <mestery> I don't see why we should mint winners and losers at this level of the stack
20:45:42 <sridhar_ram> this is what some operators are doing it ... doing it by themselves..
20:45:43 <lifeless> mestery: not trying to pick winers or losers
20:45:44 <mestery> lifeless: Now *that* is a valid concern
20:45:59 <markmcclain> ttx: so my opposition to the current vote is lack of real integration
20:46:04 <mestery> lifeless: We are picking winners and losers when use Astara as a reason to not include tacker
20:46:05 <ttx> I'm sympathetic to Jay's argument fwiw. That is why I'm hesitating
20:46:05 <lifeless> mestery: happy to have competition. Don't want something that a different governance body is dictating outside of of purview
20:46:09 <sdague> ok, so this takes TOSCA templates and does openstack apis to make things happen. Does Heat do TOSCA ? I thought it did?
20:46:10 <ttx> markmcclain: could it be fixed ?
20:46:13 <mestery> lifeless: If we let them in, we get to boot them out
20:46:17 <lifeless> mestery: but I haven't used Astara's position as a reason for that
20:46:18 <mestery> ttx: It *is* being fixed
20:46:21 <markmcclain> ttx: yes and stated I'd vote yes
20:46:32 <mestery> sridhar_ram: See ttx's question there
20:46:34 <markmcclain> mestery: the comments by sridhar_ram says it's in process
20:46:35 <anteaya> mestery: who have we booted out?
20:46:38 <ttx> markmcclain: so your vote is more of a "no, not yet"
20:46:39 <mestery> Right
20:46:40 <sridhar_ram> sdague: yes, we are indeed using tosca-parser and heat-translator in Tacker
20:46:41 <mestery> IT is being fixed
20:46:42 <sdague> I'm in the lifeless camp, I kind of still don't fully undestand
20:46:44 <markmcclain> ttx: correct
20:46:48 <ttx> ok, got it
20:46:53 <anteaya> mestery: that argument holds no water with me, since we don't do that
20:47:01 <markmcclain> ttx: the overlap concern is a follow up question we should tackle
20:47:07 <jeblair> sdague, lifeless: count me in too
20:47:09 <lifeless> mestery: here's the scenario I'm worried about. tacker is functionally == astara, but different because group A and group B haven't actually talked, rather than any technical reason
20:47:11 <mestery> I don't even ...
20:47:21 <devananda> dhellmann: I don't see how "only group X is interested" is a valid reason to keep something out of openstack, if that group of people contribute to and maintain the project(s)
20:47:24 <markmcclain> ttx: specifically how can we encourage convergence
20:47:34 <lifeless> mestery: and tacker isn't talking to astara because its being driven by OPNFV teams
20:47:39 <sridhar_ram> ttx: markmcclain: we are indeed going to do SFC using neutron-sfc.. period
20:47:46 <mestery> lifeless: We're picking winners again
20:47:49 <dhellmann> devananda : I'm not sure I'm arguing for or against that position, just trying to state things clearly.
20:47:53 <mestery> Personally, I don't want to do that at this layer of the stack
20:47:57 <jaypipes> annegent_, dhellmann: vIMS == virtual IP-based Multimedia Services. I was close enough. Can never remember all the acronyms :(
20:48:01 <jeblair> anteaya: we haven't, but we absolutely can.
20:48:04 <devananda> dhellmann: I see, thanks.
20:48:10 <ttx> OK, we need more votes then. Missing jeblair, mordred lifeless dhellmann dtroyer sdague
20:48:25 <lifeless> mestery: no; I'd vote +1 in a heartbeat if the external governance aspect was clearer to me, and all my questions are trying to get to the bottom of that
20:48:49 <anteaya> jeblair: sure we can, but as an arguement in decision making, it is an anti-arguement as far as I am concerned
20:48:53 <lifeless> mestery: and - if the reason for competition is the governance aspects, then yes I'd vote -1 *because of that, not that its competition*
20:48:59 <devananda> if the project is not / does not want to be part of openstack governance, that's a clear blocker IMO.
20:48:59 <dtroyer> I'm still trying to understand why we want application layers in OpenStack… is an ERM coming next for Enterprise-readiness?
20:49:01 <jeblair> anteaya: that's a fair point, just wanted to be clear :)
20:49:10 <anteaya> jeblair: yup, fair enough
20:49:19 <dhellmann> sridhar_ram : I see that most of the folks contributing to this are from intel and brocade. I don't have an easy way to tell whether they're contributing to other projects like neutron or heat. Do you know if they are?
20:49:42 <dhellmann> mestery : we do have an obligation to evaluate gratuitous overlap, so please let us at least ask the question without getting bent out of shape.
20:50:01 <sdague> especially when something else is adding a forward REST API
20:50:07 <jaypipes> dtroyer: yup that is precisely what I'm afraid of.
20:50:07 <mestery> dhellmann: We did the same thing when astara was proposed and were ignored
20:50:11 <mestery> So you can see how I might be a little ticked here
20:50:16 <ttx> so three arguments against -- Jay's "code consuming OpenStack is not OpenStack", mark "moar integration", and lifeless "would it really be under our governance"
20:50:17 <sridhar_ram> dhellmann: if you look at the patchsets we now have wider contributions coming from ALU/Nokia, 99cloud, NEC, etc
20:50:22 <mestery> dhellmann: Me, russellb and armax all had those questions then
20:50:38 <dhellmann> sridhar_ram : sure, I'm looking at the overall picture
20:50:39 <devananda> dhellmann: overlap between projects in the big tent is specifically not a reason to block projects ...
20:50:51 <ttx> devananda: +1
20:51:08 <dhellmann> devananda : "Where it makes sense, the project cooperates with existing projects rather than gratuitously competing or reinventing the wheel"
20:51:18 <devananda> sdague: and the TC is also not supposed to pick winners based on who has the first REST API
20:51:22 <ttx> devananda: also agree that the governance question is pretty critical though. If OpenNFV wants to call the shots in tacker, that should stay out
20:51:25 <jaypipes> ttx: "*purpose-built* applications that glue together lots of OpenStack services are not OpenStack" <-- that is my opinion. there's a big difference.
20:51:31 <devananda> ttx: completely agree on that
20:51:48 <devananda> it sounds like there are a lot of very important unanswered questions here, though
20:51:55 <devananda> and we're all debating whether to ask them or not
20:51:55 <mestery> jaypipes: I continue to believe your argument is the only one displayed so far giving me pause on my +1
20:52:02 <mestery> So thanks for that
20:52:02 <mestery> It's a valid concern
20:52:10 <sridhar_ram> I absolutely don't see this as a competition to neutron's advanced services is .. which where Astara is operating IMO
20:52:23 <jaypipes> again, I'm not trying to be a spoilsport. Just saying my peace/piece.
20:52:32 <dtroyer> honestly, I don't care about overlap, especially in the upper layers.  It keeps groups on their toes
20:52:49 <dtroyer> but how high up the app stack does OpenStack go?
20:52:56 <ttx> sridhar_ram: I think that's a weak argument against Tacker. The two strong arguments against inclusion imho are Jay's and devananda's
20:52:58 <dhellmann> I'm less concerned with overlap because teams think they can do better than I am refusal to collaborate at all.
20:53:28 <dhellmann> Hence my question about whether the contributors to Tacker are participating in other projects or otherwise being involved in the community.
20:53:29 <dtroyer> dhellmann: competition in theory addresses that one way or another
20:53:34 * russellb back ....
20:53:46 <ttx> i.e. the consumer question, and the ownership question
20:53:56 <anteaya> russellb: congratulations on safe takeoff
20:53:59 <sridhar_ram> ttx: sure.. what I see is many operators are stringing together is exact same solution over and over again, there is an interest to do it one in OpenSource and in OpenStack...
20:54:14 <russellb> jaypipes: i think i probably agree with you at some level.  i'd like to see what we could come up with for defining some upper bound on what would be openstack ...
20:54:15 <jaypipes> russellb: we have renamed OpenStack to Delta GoGo Internet. you're welcome.
20:54:21 <russellb> neat
20:54:30 <dtroyer> sridhar_ram: we're not questioning the validity of the use cases, but whether it belongs here
20:54:49 <russellb> jaypipes: sounds like i may argue it a little higher, but i think there's value in a more general statement on the matter
20:54:56 * sridhar_ram catching up on devananda's position
20:55:05 <ttx> sridhar_ram: could you explain how OpenStack and Tacker would be in a better situation if we accept Tacker in rather than just keep it under OpenStack infra ?
20:55:09 <devananda> dhellmann: IMO, that boils down to governance. competition within a single governance framework (ie, openstack) is fine, as long as it's based in collaboration and cooperation
20:55:37 <jaypipes> russellb: yes, that's the eternal question we need to answer I guess. I've been defining it in terms of what sets off my intuition around whether the project pulls OpenStack too much in the direction of one particular industry or business segment.
20:55:50 <ttx> I think we should continue that discussion on the review. I'll summarize the discussion and what I see as the remaining key concerns
20:55:58 <jaypipes> russellb: but it's certainly a grey area to be sure.
20:56:00 <sridhar_ram> ttx: I know many folks are sitting in the sidelines in either pulling this in and contributing resource because it still has that "stackforge" label
20:56:03 <russellb> jaypipes: agree
20:56:03 <jaypipes> valid points on all sides.
20:56:08 <thingee> sridhar_ram: from devananda  "if the project is not / does not want to be part of openstackgovernance, that's a clear blocker IMO."
20:56:11 <ttx> Still leaning towards yes, but depending on how those two concerns are clarified I may just switch to no
20:56:19 <dhellmann> devananda : sure. I'm not getting much in the way of useful info about this team's cooperation track record
20:56:26 <russellb> what's the tl;dr on remaining 2 concerns?
20:56:42 <dougwig> sridhar_ram: needing governance to get investment has never been a good argument, IMO.
20:56:47 <thingee> russellb: jay's point and following governance
20:56:53 <russellb> ack
20:57:00 * jaypipes would also like to be up front and say that Mirantis has apparently joined some Open Source MANO initiative. This has nothing to do with my opinion and vote, here, I would like to piont out.
20:57:02 <devananda> jaypipes: will this pull all of openstack in some direction, or merely add the ability to service a particular segment of users?
20:57:18 <russellb> jaypipes: red hat may be joining the same thing, or some other thing, i can't keep track
20:57:22 <russellb> there's a lot happening in this area
20:57:23 <markmcclain> dougwig: it does have a significant impact regardless of how it should be
20:57:25 <ttx> sridhar_ram: would you say that an accepted-in-OpenStack Tacker takes design orders more from OpenNFV or more from the OpenStack TC ?
20:57:31 <sridhar_ram> ttx: devananda: we absolutely want to be under governance.. we just waited until now to get our project in decent shape, with more core reviewers, docs, functional tests, stc
20:57:42 <mestery> 2 minutes left
20:57:44 <anteaya> jaypipes russellb thanks for being forthcoming
20:57:46 <mestery> This has been elightnening
20:57:56 <jaypipes> devananda: good question. I'm still working that answer out in my head. unfortunately, like I said, it's falling to my intuition. :(
20:58:01 <ttx> sridhar_ram: (no answer needed now)
20:58:02 <sridhar_ram> ttx: we will be bound by TC, our inputs always comes from Operators
20:58:07 <devananda> sridhar_ram: and the corrolary - is / will your development team be involved with other openstack projects directly (as contributors), or merely consuming them?
20:58:09 <ttx> We'll continue that on the review
20:58:15 <sridhar_ram> OPNFV is just one way of getting requirements
20:58:15 <devananda> jaypipes: fair 'nuf
20:58:19 <mestery> I think we need to figure out where we're drawing hte line better, because with the Big Tent, I'm concerned we should ahve let Tacker in as it stands.
20:58:23 <thingee> What is missing on the governance side with tacker?
20:58:25 <jaypipes> #link https://www.mirantis.com/blog/open-source-mano-osm-to-work-on-nfv-orchestration/
20:58:28 <ttx> sridhar_ram: sorry it takes a long time to decide, but this is definitely an edge case
20:58:33 <jaypipes> ^^ details on aforementioned thing.
20:58:41 <ttx> we have to carefully consider it
20:59:05 <ttx> So... let's continue on the review and this will be back next week
20:59:06 <sridhar_ram> devananda: yes, our developers are already contributing to heat-translator and then integrating things into Tcker
20:59:13 <russellb> jaypipes: i trust you to be wearing your upstream hat, but appreciate the openness :)
20:59:16 <ttx> #topic Open discussion
20:59:19 <dhellmann> sridhar_ram : good to hear
20:59:24 <ttx> I posted the design summit split proposal to the ML Monday, the feedback has been mostly positive so far
20:59:26 <flaper87> russellb: jaypipes ++
20:59:29 <jaypipes> sridhar_ram: I don't have any doubts to Tacker's (and your personal) commitment to the "OpenStack Way" and the 4 Opens.
20:59:37 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/087161.html
20:59:43 <ttx> We should definitely have a session in Austin to discuss the details
20:59:43 <flaper87> ttx: ++
20:59:44 <sridhar_ram> jaypipes: thanks :)
20:59:55 <russellb> ttx: thanks for your work on that
20:59:59 <ttx> I know management at some contributing companies will initially not like it, since they kinda liked abusing their devs all week for other duties, but the double-duty was what made the design summits less productive
21:00:11 <ttx> So you might need to relay and explain internally why the proposal is a good thing for OpenStack overall
21:00:11 <mestery> nice work ttx
21:00:12 <jaypipes> sridhar_ram: you are unfortunately caught between two existential combatants in my mind ;)
21:00:16 <thingee> http://lists.openstack.org/pipermail/openstack-dev/2016-February/thread.html#87161
21:00:22 <thingee> design summit split ^
21:00:25 <annegent_> oo existential combatants
21:00:25 <ttx> Anything else, anyone ?
21:00:32 <russellb> jaypipes: ha
21:00:37 <devananda> jaypipes: lol
21:00:45 <sridhar_ram> jaypipes: :)
21:00:52 <russellb> ttx: fwiw management here seemed to like it quite a bit
21:00:52 <annegent_> ttx: do you envision for cross project teams any difficulty getting space? Do you envision space limits?
21:01:00 <flaper87> russellb: ++
21:01:03 <ttx> russellb: great!
21:01:13 <russellb> i sent it to some folks immediately, got positive reaction
21:01:28 <annegent_> ttx: or fungi or jeblair might know, when you run the ATC badge invites is it from the projects.yaml list?
21:01:30 <ttx> annegent_: I haven't looked into logistics yet
21:01:42 <fungi> annegent_: yes
21:01:45 <ttx> annegent_: yes it is from the yaml
21:01:47 <jaypipes> ttx: mixed reviews internally here, as to be expected.
21:01:59 <ttx> jaypipes: cool, do your magic :)
21:02:00 <russellb> jaypipes: i do really like the idea of taking the opportunity to make a scope statement.  after letting the big tent ride for a while, seems like a nice next step
21:02:08 <jaypipes> ttx: work in progress :)
21:02:11 <russellb> jaypipes: i don't expect that to get resolved quickly though
21:02:18 <ttx> ok, time to close this
21:02:22 <jaypipes> russellb: ++
21:02:24 <annegent_> I'm also hesitant about the Aug/Mar timing but that's my American mom-isms jumping in.
21:02:27 <ttx> Thanks everyone, good discussions all over
21:02:34 <ttx> #endmeeting