20:00:59 #startmeeting tc 20:00:59 * devananda lurks 20:00:59 o/ here 20:01:00 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:02 thanks (sorry, was supposed to be in the air for this, delays) 20:01:04 The meeting name has been set to 'tc' 20:01:12 Hi everyone! I made it back from snowland 20:01:20 ttx: in how many pieces ? 20:01:24 We have a pretty long agenda for today, not sure we'll get to the bottom of it... 20:01:28 flaper87: single piece! 20:01:31 ttx: welcome back! 20:01:34 ttx: good good! 20:01:35 welcome back! 20:01:41 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:42 o/ 20:01:44 No way we make it through the agenda, but lets try! 20:01:49 Safe trip!! 20:01:50 #topic Propose an update to the OpenStack mission statement. 20:02:02 Let's start with this item as it may be helpful for Russell to push it at the board meeting 20:02:04 this is on the board meeting agenda for right after this as well 20:02:04 (or not) 20:02:16 Personally I think that wording still fills the objective we had (adding "interoperability" and "users") 20:02:25 #link https://review.openstack.org/281463 20:02:26 yep 20:02:26 timebox? 20:02:39 I'm good with the wording 20:02:39 I think we can approve it now, has enough votes 20:02:51 lots of +1s, no -1s, yay 20:02:52 ++ 20:02:56 w00h000 20:02:56 it's got 9 +1s so far, and I think everyone that spoke up in the thread has voted here 20:02:56 thanks 20:02:58 unless someone wants to try to convince most of the current +1s 20:03:04 o/ 20:03:05 russellb: thanks for working on that 20:03:05 to switch 20:03:13 i just did the paperwork 20:03:14 ok, approving in 30 seconds 20:03:19 thanks to several others for nice work on the wording 20:03:42 ok, it's in 20:03:49 sweet 20:03:51 hopefully the board will be happy this time 20:03:53 russellb: you can bring it to the board meeting now 20:03:57 thanks 20:03:57 russellb: thanks for taking it across the finish line 20:04:12 o/ 20:04:16 russellb: yes, thanks russellb 20:04:22 np :) 20:04:23 #topic Add project Dragonflow to OpenStack big-tent 20:04:29 #link https://review.openstack.org/277153 20:04:37 It's more of a governance clarification than a project addition, so I'm +1 on this 20:05:05 i hadn't voted on the latest one, added +1 20:05:06 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 right, this was part of neutron, now it stands on it's own, right? 20:05:16 yes 20:05:20 it's a neutron backend 20:05:21 ship it 20:05:22 sdague: yes 20:05:23 is the tl;dr 20:05:43 ok, we have 7 +1s. Objections ? 20:05:51 No objections here 20:05:58 none from me 20:06:01 nope. 20:06:01 importantly we have 7 +1s, including all the network specialists 20:06:06 yep 20:06:08 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 dhellmann: ++ 20:06:21 sure. 20:06:21 dhellmann: agreed 20:06:26 it doesn't apply here, but something that only works if you've bought equipment from someone... 20:06:27 in this case, all the code is dragonflow itself 20:06:31 right 20:06:32 dhellmann: yes, but I don't think dragonflow (or kuryr) are in the grey area 20:06:35 dhellmann: s/neutron spinouts/all projects applying for big tent/ 20:06:46 The open core discussion pops up earlier than I would have thought 20:06:52 approving now 20:06:57 dragonflow and kuryr are not open core 20:07:03 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 #topic Add project Kuryr to OpenStack big-tent 20:07:18 i don't even know what the spin outs are going to be yet 20:07:20 dhellmann: it is. there are a lot of networking-bigphathardware repos. 20:07:21 mestery : right, I don't think so. I'm just pointing out a side-effect of that other discussion 20:07:26 #link https://review.openstack.org/280522 20:07:35 I think this is the same case as Dragonflow 20:07:36 Hard to argue against Kuryr being added here 20:07:37 this one already has 10 +1s too 20:07:38 kuryr is an easy one for me 20:07:38 Right 20:07:39 might even be easier 20:07:40 Easy one 20:07:45 Ship it ttx! 20:07:50 shipping 20:07:52 neeeeeeext 20:08:06 next should likely trigger more discussion 20:08:11 3 agenda items and no bikeshedding. is a virus going around or something? 20:08:15 #topic Vote on whether Poppy is open core or not 20:08:20 #link https://review.openstack.org/278247 20:08:20 dougwig: sssshh 20:08:26 dougwig: saving up energy for other stuff 20:08:30 So... Poppy raised non-technical and technical issues. The latter could be fixed before inclusion. 20:08:42 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 i'm not sure "open core" is the right term, but i still don't think this is openstack 20:08:51 It feels like there are now 3 parties on this one 20:08:55 russellb: ++ 20:09:07 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 russellb: ++ 20:09:22 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 not being open core isn't enough to make it openstack 20:09:42 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 The "why" and "what" parties add up, so NO leads 7-5 at this stage 20:10:09 nice summary 20:10:12 yup 20:10:14 I would also consider myself part of group 3 20:10:25 but we didn't get multi select :) 20:10:29 sdague: heh 20:10:34 2 and 3 20:10:35 sdague: I'm also in group 3 :) 20:10:36 sdague : yeah, no voting twice :-) 20:10:48 I guess that's the result 20:10:49 heh sdague :) 20:11:19 Unless someone wants to make a case to move the lines, feels like No wins. Who didn't vote yet ? 20:11:22 lifeless 20:11:32 hai 20:11:33 One thing I want to make sure is that we don't kick the project out of the openstack organization 20:11:36 I feel like all the words that are going to be said have been. People were pretty expressive in the reviews. 20:11:39 hi! Where do you side ? 20:11:49 I'd like to say that my NO is pretty weak. I could survive a Yes 20:11:56 I'm certainly no *as it stands* 20:11:58 sdague: i agree 20:12:06 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 I think the what aspects can be addressed, if the team chooses 20:12:16 lifeless: on this review we are saying "No even if they fix things" 20:12:17 flaper87: same here 20:12:22 flaper87: yes, agreed 20:12:26 flaper87 : yes, I don't think that's in question 20:12:29 lifeless: i think we're only focusing on the 'soft' aspects right now 20:12:33 so a yes here doesn't mean an immediate addition 20:12:38 flaper87: the project is not in danger of losing access to ci resources 20:12:50 coolio, I just remember reading it and pulled my hair off 20:12:59 lifeless: i am 'no' because of other issues (that poppy can fix) 20:13:15 jeblair, lifeless : ditto 20:13:19 it is worth being clear on that (and i do think the change is clear on that) 20:13:39 So how to proceed? Unless people are changing votes this looks like it won't make it. 20:13:41 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 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 The 7-5 vote here makes it seem like that's the case 20:14:27 I think a natural next extension of that good discussion is "what does purposeful expansion look like?" 20:14:30 mestery: If this is rejected, the other one should be rejected too 20:14:32 ttx: agreed, that just seems like extra work that's not useful 20:14:33 but I don't want to conflate yet 20:14:40 ++ 20:15:02 I guess they could reapply one day if they feel the lines have moved 20:15:19 or if an open source solution is created 20:15:21 but as they stand today, they can be hosted under openstack infra, but should not become an official project 20:15:40 ok, words said, +1 voted 20:15:47 * ttx reads 20:15:57 error server unavailale. 20:15:59 thanks gerrit 20:16:12 lol 20:16:12 lifeless: lol 20:16:21 right, there 20:16:23 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 lifeless: hah 20:16:45 so maybe we should decide to reject them today but consider revisiting next cycle 20:16:50 I think we decide and move on 20:16:51 It feels a lot like Zaqar days but different topic :P 20:17:01 ttx: decide, move on 20:17:18 alright, I'll abandon this review 20:17:19 they can re-apply later if they want 20:17:19 I guess I'd rather have a weak rejection than a weak addition 20:17:24 because there were votes that flip to -1 on the second patch which were +1 on the first 20:17:27 if sands shift 20:17:48 I've been on both sides now and even when Zaqar was rejected, the weak rejection made more sense 20:17:57 We should reapply our -1s on https://review.openstack.org/273756 as well 20:18:02 ++ to possibly re-applying later 20:18:29 flaper87: your -1 seems to be entirely pragmatic - 'we can't test this' 20:18:46 #link https://review.openstack.org/273756 20:18:52 lifeless: I +1'd it 20:18:57 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 lifeless: mmh 20:19:03 flaper87: ah, cool 20:19:08 lifeless: :P 20:19:20 flaper87: oh, nick confusion actully :) 20:19:48 dhellmann: ++ 20:20:31 * russellb boarding plane ... sorry 20:20:40 russellb: take care 20:20:41 ok, next topic? 20:20:44 travel safe russellb! 20:20:46 403063 20:20:48 safely? I dunno. 20:21:08 annegent_: "make sure you land" works too 20:21:11 annegent_: I use travel safe 20:21:19 ttx: ? 20:21:22 flaper87: landing is guaranteed. 20:21:29 dougwig: lol 20:21:37 ha 20:21:43 redacting the answer 20:21:49 dougwig: *stopping* is guaranteed... 20:21:57 I just abandoned the main Poppy review 20:22:00 dougwig: landing is more narrowly defined :) 20:22:19 Alright, next topic 20:22:33 #topic Applying Tacker for Big Tent 20:22:38 #link https://review.openstack.org/276417 20:22:42 Another difficult edge case here... 20:22:50 * russellb delays getting on 20:22:50 I'm leaning towards yes at this stage, for the reasons outlined in my review comment 20:23:13 I'll be honest, that one has me struggling to understand. Is it docs/ref arch? Or code? 20:23:14 it's another IaaS+ like project, focused on some NFV use cases, they have good intentions around integration 20:23:16 seems fine to me 20:23:23 code 20:23:27 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 feel* 20:23:49 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 russellb : if the integration isn't done, is the project mature enough to be official? 20:23:51 do we have a jaypipes? 20:24:04 I think I'm only negative vote... my concern is the lack of proper integration 20:24:07 ttx: that would help, yeah 20:24:15 markmcclain: no; jaypipes was pretty vocal 20:24:32 heh right markmcclain that's why I'd like to hear more from jaypipes 20:24:33 ttx: ah right 20:24:40 annegent_: yes, I am here :) 20:24:50 annegent_: what more would you care for me to expand on? 20:24:53 They have plans for integration which I'm comfortable with 20:25:02 I think jaypipes concerns are more interesting here 20:25:04 E.g. "Is this really OpenStack?" 20:25:15 mestery: plans are great would just like to wait for execution of them 20:25:32 markmcclain: FWIW, we've let other projects with "plans" in 20:25:35 Right 20:25:50 And those plans have been executed, AFAIK. 20:25:58 have they? 20:26:02 I don't see why we should block Tracker on that 20:26:03 flaper87: but those projects already some level of integration 20:26:11 thingee has been doing work on this with some projects 20:26:21 explain to me again how this isn't neutron's advanced services? 20:26:22 flaper87: it's Tacker. 20:26:29 jaypipes: if we rejected anything on "simple to implement" the list would be long :) 20:26:38 annegent_: indeed. 20:26:41 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 ttx: Well said 20:27:05 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 ttx: OK, I will add my purpose-built business application orchestrator to OpenStack then. 20:27:17 jaypipes: also is it NFV MANO that is the distinct issue for you? 20:27:35 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 "@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 just got back on sirry 20:27:46 they do have some integration (uses Heat) 20:27:48 the network side isn't done, but it's not that it doesn't exist 20:27:48 From Sridarh in hte review 20:27:52 Right 20:27:57 russellb: See my ^^^ pasted above 20:28:01 the bit that worries me specifically is 'tacker will use neutron-sfc as the default underlying sfc of choice'... 20:28:06 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 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 like, if its part of openstack, why is that going to be pluggab;e ? 20:28:30 jaypipes: what does MANO mean already ? I'm lost in acronyms again 20:28:31 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 ttx: welcome to telco. management and orchestration. 20:28:48 lifeless : good point, what other options are there? 20:28:58 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 MANO MANagement & Orchestration 20:29:17 lifeless: You could bypass Neutron completely and use some bizzare ODL SFC API 20:29:27 lifeless: That appears to be what they WERE doing with POC code 20:29:28 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 annegent_ : maybe you and I can teach some network vendors words instead of acronyms 20:29:33 and this review shouldn't become the proxy battle 20:29:35 My understanding is they abanonded that 20:29:43 dhellmann: srsly 20:29:50 dhellmann: ++ 20:29:57 several vendors are bypassing openstack and neutron to do this 20:29:59 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 dhellmann: I don't think that's possible 20:30:01 annegent_: that should be vsrsly 20:30:04 at least they're trying to do some unification 20:30:07 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 lifeless: Right, that's why they abanonded that approach 20:30:25 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 russellb: bypass might be perfectly okay to not overload OpenStack though. 20:30:33 mestery: the words from sirdhar leave me feeling unsure that they *have* abandoned it 20:30:38 annegent_: i'd argue bypass makes openstack irrelevant 20:30:46 jaypipes: Your concerns are the ones that make me thinkg to be honest 20:30:50 ttx: in what way? Isn't it only using published APIs 20:30:52 part of our mission is creating useful abstractions 20:31:07 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 sdague: it could use more of Heat, iiuc 20:31:14 jaypipes: i hear you, i look at it more like Magnum, or trove, or murano, or some other orchestration level projcet 20:31:17 ttx: how? 20:31:32 jaypipes: i guess i don't see how this crosses the line but those don't 20:31:34 russellb: Those are good comparisons 20:31:36 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 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 sdague: re: Heat, particularly around VM monitoring and failure recovery 20:32:13 less of openstack might directly consume you if you are not openstack 20:32:15 Heat is working in that domain, they've started an early approach of their own, which we discussed in the review 20:32:16 russellb: magnum, murano, and trove are not purpose-built for one industry. 20:32:16 but not the other way around 20:32:31 how does this compare with akanda btw ? 20:32:37 sdague: what russellb said 20:32:42 lifeless : lots of overlap 20:32:53 jaypipes: this is useful beyond telco IMO 20:33:05 it's a more generally useful network thingy to me 20:33:15 NFV is the driver, but it's not *only* applicable there 20:33:25 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 very applicable to enterprise security 20:33:46 russellb: name one application outside of telco. 20:34:21 Do we have Tracker folks around? 20:34:29 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 flaper87: No, but we have Tacker folks around I bet ;) 20:34:32 flaper87: I'm here... 20:34:38 sridhar_ram: Howdy :) 20:34:46 sdague: it's arguably a pretty weak argument 20:34:48 jaypipes: a more complex firewall that does deep packet inspection 20:34:54 is not a telco specific thing 20:34:58 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 sdague: as I said elesewhere, I'm a bit on the fence on this one, just leaning towards yes 20:35:25 it's definitely "networking services" specific 20:35:26 jaypipes: what makes them telco-specific at that point? 20:35:29 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 and i see that more broad than telco 20:35:40 sridhar_ram: hey, thanks for joining. It'd be useful for you to help clarifying some of the questions floating around 20:35:44 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 oh yeah, I remember, akanda -> astara 20:35:55 jeblair: it's more tailored to telco needs than telco-specific I think 20:36:16 ttx: Well said 20:36:25 sure. 20:36:27 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 others could use it. But they would have to enter that weird mindset first :) 20:36:45 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 dhellmann: that makes it 2 of us 20:36:55 sdague: heh too true 20:36:57 sdague: +1 20:36:58 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 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 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 create Nova instances that do *stuff* to packets 20:37:33 flaper87: on the internet, noone knows if you are an ip address 20:37:46 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 russellb: you just described Astara 20:37:54 lifeless: lol 20:37:55 dougwig : ++ 20:38:00 markmcclain: no i didn't, astara doesn't provide an API 20:38:11 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 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 markmcclain: I'm personally fine with having overlap in this space, as it's an outer ring type of thing 20:38:20 russellb : astara uses neutron's api 20:38:28 dhellmann: public API 20:38:32 E.g. Octavia does some of this too 20:38:37 russellb: ++ 20:38:39 dougwig: its not even the next step - its just much more generic than e.g. wccp 20:38:43 russellb : yes, it responds to things that happen when you call neutron's api 20:38:53 right, this is a new API on top of neutron and nova 20:39:03 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 to orchestrate neutron and nova resources to create new networking things 20:39:22 sdague: FWIW I'm not opposing, I'm still trying to really grok what we're being asked 20:39:23 mestery: indeed it does. NFV is not a space where we'd want to pick just a single horse, imo. 20:39:35 my biggest concern is that this is being defined by a not-openstack-group 20:39:46 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 OSS/BSS systems from telcos be proposed into OpeNStack. I can guarantee that. 20:39:53 argh, flight attendent making me shut down 20:40:01 heh :) 20:40:02 russellb: Nooooooo! 20:40:06 :) 20:40:13 jaypipes: i'd love to have a more general debate about where we draw that line 20:40:15 russellb: stay on, please 20:40:20 :) 20:40:22 russellb: what sort of repressive regime are you flying on! 20:40:26 delta! 20:40:29 sridhar_ram: he risks being removed from the plane 20:40:31 let the flight attendant do their job! :) 20:40:32 been there 20:40:33 * flaper87 knew it was delta 20:40:41 bye 20:40:49 ciao 20:40:52 annegent_: I'm trying to having him kicked ;-) 20:41:09 sridhar_ram: :) 20:41:09 sridhar_ram: he is advocating for your patch 20:41:16 jaypipes: +1 20:41:20 so that is an odd choice you make 20:41:22 sridhar_ram: so tell me about the governance 20:41:30 anteaya: that's why he wants him off the plane so he can stay in the meeting 20:41:47 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 ttx, sridhar_ram : also benefit OpenStack 20:42:04 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 dhellmann: vEPC == virtual evolved packet core. vIMS == virtual internet media services (or something like that... 20:42:26 oh thank you jaypipes 20:42:26 It appears that the main tension here is that this is a business application consuming OpenStack, so it's not OpenStack 20:42:32 jaypipes: You've been doing your homework my friend 20:42:36 jaypipes : maybe switching to words is pointless, I still don't know what any of that is :-) 20:42:40 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 dhellmann: :) 20:42:45 IMO this is biggest blocker in having someone consume OpenStack for NFV 20:42:51 jaypipes.com, reverse acronym proxy 20:42:55 ttx +++ 20:43:05 lifeless: Astara is just a neutron backend.. that doesn't cut it for NFV operators.. 20:43:15 NFV / VNF != Neutron.. 20:43:21 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 sridhar_ram: Perhaps markmcclain can comment more, but that doesn't match my understanding of Astara 20:43:23 dhellmann: not sure how you've gone all this time without your VEPC's and your vIM's. 20:43:23 their world is bigger ... 20:43:24 the biggest blocker is complexity I believe... and this is certainly complexity 20:43:24 Again, see Octavia 20:43:38 thingee : I'm a luddite. 20:43:50 sridhar_ram: not true... Astara implements a backend for neutron, but is actually a pluggable orchestrator of network services 20:43:51 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 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