20:01:10 #startmeeting tc 20:01:10 Meeting started Tue Feb 9 20:01:10 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:10 hi 20:01:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:13 o/ 20:01:14 The meeting name has been set to 'tc' 20:01:18 Hi everyone! 20:01:20 o/ 20:01:24 Here is our agenda for today: 20:01:24 o/ 20:01:29 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:39 #topic Applying Tacker for Big Tent 20:01:43 #link https://review.openstack.org/276417 20:01:51 Quick background 20:01:55 As I understand it (russellb please correct me if I got it wrong) 20:02:00 Tacker is a NFV component designed to fit in the ETSI architecture model 20:02:06 OpenStack is used as the Virtualized Infrastructure Manager in the model 20:02:16 And Tacker provides the glue between NFV and OpenStack by implementing the "VNF Manager" and "Orchestrator" components of the ETSI framework 20:02:20 #link https://www.opnfv.org/software/technical-overview 20:02:29 So I suppose it's not meant to be enduser-facing APIs 20:02:39 While it's not very advanced, they already have a variety of contributing organizations 20:02:40 is this a special case for what heat does? or is it using heat? 20:02:47 roughly ... I thought this was the VNF manager 20:02:53 it's using heat 20:02:57 russellb: I thought it was that plus something else? 20:03:07 well ... it's also got some custom SFC stuff ... 20:03:12 It's the VNF manager AND the orchestrator 20:03:12 russellb: btw: https://imgflip.com/i/yvatt 20:03:19 russellb: OF course it does 20:03:24 o/ 20:03:38 it uses Heat to create VMs that are used to implement networking services 20:03:51 They have been around for a while now and have been using the ML and IRC meetings for open collaboration 20:03:51 ttx: ++ 20:03:55 it *also* includes an API for doing SFC, but it calls directly into OpenDaylight to do so 20:04:04 it really needs to be reworked to integrate properly with Neutron 20:04:09 but I think they have good intent to do so 20:04:29 (yes this is an acronym overload space.....) 20:04:31 russellb: I'd think so. Do they work with ONOS too with that SFC API? 20:04:34 Looks like they still need to adjust some tags on the proposal 20:04:41 not positive, i think it's been ODL focused so far 20:04:42 * dhellmann wonders what language mestery is speaking 20:04:44 questions / comments ? 20:04:46 heh I was still looking up esti 20:04:59 ETSI == standards body 20:05:06 I don't have any major objection against this proposal. I dropped 2 nits on the patch and one of them I believe is being worked out as we speak 20:05:29 flaper87: I wouldn't be surprised if they could not assert anything at this stage 20:05:49 I posted my comments on the SFC API mess 20:05:57 is tacker already in the neutron stadium? 20:06:00 flaper87: unless you know something that I don't 20:06:02 * dhellmann given our recent open core discussion, and the general nature of the networking 20:06:06 oops 20:06:09 annegentle_: It was never in the neutron stadium 20:06:10 * annegentle_ tries to keep up 20:06:18 ttx: they are changing the release model based on the latest comment 20:06:19 given our recent open core discussion, and the general nature of the networking space, how much of this is actually open? 20:06:25 flaper87: ah, nice 20:06:31 as this is mostly network oriented I'd be highly currious on russellb, mestery, and markmcclain's feelings here 20:06:47 and the standard-deprecation one would be nice to have 20:06:48 sdague: My main concern is on yet another SFC API 20:06:53 dhellmann: I think it's pretty neutral. It just exposes OpenStack resources in a wat NFV likes to have them 20:06:54 Otherwise, I have no concerns 20:06:58 tacker is not a part of neutron, in fact it bypasses neutron 20:06:58 way* 20:07:00 but it depends on how solid they think their API is 20:07:03 Well, I mean other htan it ties directly to ODL 20:07:07 ttx: o/ 20:07:10 tacker has NEVER been a part of neutron 20:07:10 it overlaps with part of neutron in the API space 20:07:16 but they've said they want to integrate with neutron 20:07:18 Even when it was NOT an NFV orchestrator 20:07:39 really, if folks want a more in depth analysis on this, i'm happy to do so, but would need more time to do a dive and write something up on the review 20:07:44 my main concern (as just noted in my vote) is that Tacker is focused on NFV Orchestration, and so I believe belongs best in the OPNFV ecosystem, not OpenStack itself. 20:07:49 * edleafe wanders in late, once again 20:07:59 my only observation is we've tried to discuss working with them in prior cycles 20:08:00 jaypipes: Seems reasonable to me at first glance 20:08:01 russellb : "bypasses neutron" in what way? 20:08:07 jaypipes: but OPNFV doesn't produce code, in theory 20:08:17 russellb: they do, apparently. :) 20:08:21 dhellmann: implementing SFC requires coordination with what Neutron does 20:08:30 to do things in a way that is compatible with all Neutron backends 20:08:33 and the functionality between astara and tacker do overlap is many places 20:08:44 this sort of ignores that and calls directly into an SDN controller 20:08:53 Right 20:09:02 russellb : so is it incompatible with neutron? or supplemental? 20:09:11 depends on what backend you use 20:09:15 * ttx thought he understood it but now is confused 20:09:26 it's messy. 20:09:32 russellb: It is 20:09:39 Because it talks directly to ODL 20:09:41 Which sets up networkign with neutron, right? 20:09:41 so we're sort of supporting both reference architectures and changes to neutron by enabling tacker in the ecosystem? 20:09:52 annegentle_: There are no neutron changes proposed 20:09:53 so it uses heat to tell nova to make vms to run software to do network things, but then bypasses neutron to actually manage the networks connected to those vms? 20:10:00 dhellmann: Good summary 20:10:02 dhellmann: yes 20:10:11 though the networks are neutron networks 20:10:14 that doesn't sound too friendly to the overall could 20:10:17 holy moly 20:10:18 cloud 20:10:19 russellb: but that is what NFV is about, right 20:10:27 ttx: which part 20:10:28 ttx: NFV is about bypassing neutron? 20:10:31 using vms to do networking 20:10:32 I may quote you on that ttx 20:10:36 using vms to do networking, yes 20:10:39 mestery: lol 20:10:42 from a high level, this is all sane 20:10:47 ttx: that's not the part that concerns me, the bypassing bit is 20:10:48 service vms right? 20:10:50 it needs to be integrated better 20:11:01 (if we care to include that in criteria) 20:11:01 the 'depends on which backend' part concerns me 20:11:03 russellb: Yes, because right now it's bypassing neutron and using ODL directly 20:11:15 russellb: Isn't it? Or is it no longer doing that? 20:11:17 doing service vms was a huge part of nfv 20:11:18 it is yes 20:11:24 service vms *is* NFV :) 20:11:28 OK, I knew at one point it was 20:11:28 russellb: you mentioned you've seen the intent from the team to integrate better with neutron, right? 20:11:29 :) 20:11:31 SO ... I do not believe I need to understand the technical implementation of tacker nor whether it's a good idea or not that it does so 20:11:35 flaper87: yes 20:11:39 Should this be put on-hold and wait until that happens ? 20:11:39 how does this relate to any of our networking projects other than neutron? 20:11:56 do we not have a tacker representative here? 20:11:57 flaper87: we aren't really holding other projects to integration bars like that.... 20:11:58 flaper87: ++ 20:12:05 the only concern that seems relevant is the neutron bypass, but that seems to be roadmap - I do not think it's necessary to make them integrate with neutron 20:12:06 not that i disagree with the idea, just saying 20:12:09 dhellmann: it shares similar functionality as Astara 20:12:14 jaypipes: yes, listening in... 20:12:18 mordred: yeah, that's where I am too 20:12:21 i don't think overlap with astara is really relevant 20:12:22 markmcclain : does astara have an API now? 20:12:30 given that astara itself overlapped with existing stuff significantly, as well 20:12:31 plugin API yes 20:12:39 public facing REST API no 20:12:41 sridhar_ram: do you have any comments or answers to the above lines of questioning and commentary? 20:12:42 markmcclain : ok 20:12:42 as both astara and takcker are deployer-oriented things without end-user APIs - it does not bother me that they have overlap 20:12:53 mordred: I think they help with the "ubiquitous" part of the mission by making openstack consumable by NFV folks 20:12:58 ttx: I agree 20:13:03 mordred : I thought tacker had a rest api? 20:13:12 even if the way they consumz it makes little sense to us 20:13:14 that's what they claim in the patch 20:13:19 russellb / mestery - how does it completely bypass neutron? How are actually compute VMs connected in this environment? 20:13:25 dhellmann: it does 20:13:28 dhellmann: rest API ~= end user API I presume 20:13:32 dhellmann: I thought russel said that it wasn't supposed to be for end-users of the cloud 20:13:34 dhellmann: note in the comments when I asked about their rest api 20:13:36 jaypipes: our preference / plan is to always use neutron-sfc, we will cut-over to use that and deprecate direct calls to ODL once neutron-sfc is stable 20:13:38 omg i can't keep up 20:13:42 sdague: It's talking to ODL to wire the networking up I believe, russellb correct me if I'm wrong here 20:13:46 mordred: that maybe true, but they still have a rest api 20:13:49 russellb: me neither 20:13:56 russellb : it's all the acronyms 20:13:58 sridhar_ram: Does this use ODL directly to wire networking up for the VMs? 20:14:01 mestery: right, but you still need to coordinate with nova somehow 20:14:03 dhellmann: +100 20:14:06 thingee: not really a enduser-oriented one though 20:14:12 sdague: Exactly, that's the part I'm not 100% sure on, sridhar_ram may know 20:14:12 * dhellmann is acronumb 20:14:16 it's unrelated to actual VIF plugging 20:14:16 ttx: correct, still a rest api though 20:14:21 my issue is gratuitous duplication and that we've attempted in the past to reach out and work together where there's overlap and were basically rebuffed saying join us or else 20:14:21 Can we have 1 convo? Like focusing on something ? It feels like we have 4 discussions now and it's networking we're talking about 20:14:26 flaper87: ++ 20:14:37 flaper87: Just get more bandwidth 20:14:37 * mestery ducks 20:14:42 voice is to russellb so that he can empty his buffer 20:14:49 markmcclain: that is a statement that concerns me 20:14:53 my overflowed and emptied 20:14:54 mestery: LOOOOL 20:15:02 mestery: there are couple of tacker-sfc backend planned .. one is for ODL that is further along (it hasn't landed yet). Another backend is planned for neutron-sfc 20:15:26 Looks like we have sridhar_ram here and he can elaborate on some questions 20:15:30 mestery: in fact neutron-sfc team members like cathy, louisef are planning to contribute the tacker part of the integration 20:15:35 Can we start by asking 1 at a time? 20:15:37 pretty please? 20:15:39 sridhar_ram: cool 20:16:17 mestery: the mess is only becoz.. these things evolved in parallel. initially we were not sure if / when neutron-sfc will flourish in the wild :) 20:16:19 i think i'd rather follow up on the review with some in depth comments at this point 20:16:22 * rockyg is grateful for a chance to catch up 20:16:23 heh, and now there's no conversation :p 20:16:27 sridhar_ram : where do the images managed by tacker come from? 20:16:33 odyssey4me: I blame flaper87 20:16:37 dhellmann: glance 20:16:54 russellb: ++ sounds fair to me 20:16:59 sridhar_ram : well, where does glance get them? are they defined as part of tacker? provided by the deployer? vendors? 20:17:03 * flaper87 puts the blame hat on 20:17:28 I *think* I have a decent idea of where the concerns/questions are, and hopefully I can try to address them 20:17:34 or at least express them on the review to give a chance for a clear answer 20:17:41 OK, maybe we could all post our concerns in one line really fast 20:17:50 if we have some 20:17:55 sure, and give me an action to follow up on the review 20:17:59 dhellmann: yes, there are two model.. operators first uploads to glance and tacker nfv templates references them .. and another feature (under works) to automatically upload images into glance as part of template onboard 20:18:14 I would like to understand how much of this is useful on its own, in light of our recent discussion about open core. 20:18:29 markmcclain: I hear you're concerned with lack of cooperation and gratuitous duplication 20:18:53 dhellmann: You're asking are their open source images to use, right? That's a good question! 20:18:59 and there is some concern around how it works around neutron, but I fear we enter implementation space 20:19:24 dhellmann: arguably a gateway service is not useful on its own 20:19:26 yep, some of that may be interesting to explore in comments, though it may not affect the actual vote 20:19:33 sridhar_ram : what I'm worried about is how someone wanting to use this gets a useful image to have tacker manage. Does it come with tacker? Do build instructions come with tacker? Do they have to make it up? Do they have to buy it separately? 20:19:45 dhellmann: like EC2API 20:19:49 it's worse than just images 20:19:51 dhellmann: my question as well 20:19:51 dhellmann: +1 also from a testing perspective, please. 20:19:55 even the infrastructure that this depends on is WIP 20:20:03 OVS itself doesn't even have the functionality this depends on merged yet 20:20:03 ttx: EC2API can be used by pointing it at OpenStack 20:20:10 thingee ++ 20:20:55 dhellmann: we use OpenWRT as a reference VNF... again the hope is tacker will be able to orchestrate any type of vnfs both opensource and 3rd party 20:21:12 ttx: I think this is closer to the way Poppy works, where you need something besides the tacker code to make it useful, and it's not clear that something is freely available or open source 20:21:13 sridhar_ram: Excellent, that's good to know (regarding OpenWRT). 20:21:46 dhellmann: i see your point 20:21:51 dhellmann: not quite, it's all open source stuff 20:21:59 but there's a ton of WIP here 20:21:59 OpenWRT is open source last time I checked 20:22:01 openwrt is a pretty excellent network operating system in fact (now if only openbsd could be properly virtualized) 20:22:07 russellb : ok, I said "not clear" -- I'm not familiar with the space 20:22:10 using openwrt for this is kind of a cool idea 20:22:13 mestery: it still is ;) 20:22:16 dhellmann: yep, just answering :) 20:22:35 mestery: it depends on the imgae iirc 20:22:42 some come with driver blobs 20:22:51 but you can do it completely open source 20:22:58 which for a virtual appliance should hopefully be entirely unnecessary 20:23:02 fungi: yup 20:23:04 clarkb: Isn't that the case for many Linux distros? (But we're taking a sideways ride ...) 20:23:13 a project like this must build their own images to be useful… 20:23:14 clarkb: recent openwrt images works nicely with tacker.. we are auto uploading the image as part of tacker devstack install 20:23:39 mestery: yup not trying to put a value assignment on it either way. Just pointing out that "openwrt" as a whole may not be foss 20:23:41 "physical interface that offers the network connections between instances of NS, VNF, VNFC (based on the VDU information element), PNF and a VL" god help us. 20:23:46 depends on how you built it where you got it from 20:23:55 sridhar_ram: Out of curiosity, what types of VNFs does OpenWRT provide? 20:24:04 OK, so in summary I think we can say that given its rather novel position wrt the openstack ecosystem, Tacker inclusion needs careful consideration, and we'll continue clarifying on the review and at next TC meeting 20:24:09 clarkb : I'm only concerned that there is at least one way that it is open source, not that we block closed source options 20:24:17 mestery: it doesn't. 20:24:19 dhellmann: ++ 20:24:29 jaypipes: That's what I was figuring :) 20:24:33 mestery: it's just the base OS image to build VNFs from. 20:24:46 ttx: ++ 20:24:53 mestery: it is a general purpose virtual router with routing, firewall, etc.. it also has installable pkg mgmt some of which might be from 3rd party.. we don't rely on them 20:24:55 also ETOOMANYACRONYMS 20:25:03 ttx ++ 20:25:17 ttx: welcome to telco :) 20:25:22 so digging in is not easy 20:25:34 jaypipes: Say what? So they use OpenWRT for only routing then by default? I'm confused. 20:25:59 IMO, if the open source alternative doesn't do what the API says it should, then it's not a working OSS alternative in the project. That's a blocker IMO if it's a bunch of work in progress. 20:25:59 OpenWRT makes a pretty decent micro-Linux base for a lot of things…not just routers 20:26:50 I could see it going both ways. in OpenStack as the NFV entry point, or outside OpenStack as something that consumes OpenStack 20:26:55 mestery: OpenWRT is simply a Linux distribution stripped down with a number of useful network control programs in it. A VNF would be a virtual machine launched from an openWRT image that wires together some of those network control programs and facilitates firewalling, load balancing, packet core transfer, etc 20:27:33 but to make that useful, it has to actually instruct the underlying network implemenation to send packets through it 20:27:38 and it seems that's not actually merged at all 20:27:39 thingee: just don't use the acronym OSS. OSS means something different in telco-land :) 20:27:49 thingee: Operational Support Systems 20:27:53 and the one that's furthest along is specific to one SDN controller, and bypasses neutron 20:27:54 jaypipes: what doesn't 20:27:58 heh, indeed 20:28:00 * flaper87 back... he hopes 20:28:11 russellb: Then why are we adding this to openstack? 20:28:11 jaypipes: fair point! 20:28:17 russellb: could you quickly expand on the "OPNFV doesn't do code" assertion ? 20:28:19 If that's the case, we should wait 20:28:27 ttx: OPNFV is a test and integration project 20:28:35 russellb: I thought they were producing something that used OpenStack and needed Tacker to interface 20:28:39 they may write code, but their intent is to do all coding in upstreams 20:28:48 so do they need tacker as their upstream? 20:28:56 they would never own code within OPNFV 20:29:03 that's the idea. 20:29:03 russellb: it's a reference implementation of ETSI NFV architecture on top of ODL and OpenStack. I don't see why Tacker doesn't better belong in OPNFV. 20:29:03 Ah. So they would rather have the openstack-touching piece in OpenStack 20:29:07 yes. 20:29:20 still, it's a ref arch 20:29:26 jaypipes: OPNFV doesn't see it that way. they'd like to add whatever is needed openstack itself. 20:29:26 (right?) 20:29:27 thats kinda weird 20:29:44 russellb: do we take direction from OPNFV now? :) 20:29:49 lol 20:29:52 no.... 20:30:08 russellb: that came out wrong, sorry... 20:30:10 the point is, they want to do this "thing" in OpenStack, and look to the community on the best way to do it. 20:30:23 and if we see it as "not integrated well enough", that's good feedback 20:30:31 ok 20:30:33 in fact, i have provided that feedback, and it seems to be taken 20:30:33 OK, I think we have primed the pump now. I suggest we move on to next topic 20:30:43 russellb: I'm trying to point out that NFV != OpenStack and Tacker is NFV more than OpenStack, IMNSHO. 20:30:43 ok, thats cool. are they participating in design summit sessions? 20:30:52 and use the review to talk between now and next meeting 20:30:57 sounds good 20:31:01 ++ 20:31:16 plenty of un in next topic too! 20:31:20 +f* 20:31:23 #topic Adds the Poppy CDN project to the Governance Repository 20:31:31 #link https://review.openstack.org/273756 20:31:37 So, round 2 of discussions around Poppy 20:31:44 The main objection raised so far is around the nature of the service vs. the OpenStack mission 20:31:55 I would summarize as: should a service which is only proxying to non-OpenStack commercial services be considered part of our "Open Source Cloud Computing platform". 20:32:10 Poppy is definitely compatible with OpenStack and part of the OpenStack "ecosystem". It's even developed in the OpenStack Way. 20:32:20 It also makes sense as part of a public cloud offering, to channel partner services that you don't provide yourself. But... 20:32:31 OpenStack is precisely about open source infrastructure building blocks you can use to provide services yourself. 20:32:43 the alternative is for each cloud ot hav etheir own non-openstack api that a user has to use to use CDN 20:32:48 it also helps support hybrid and federated cloud solutions, because of the API abstraction 20:32:50 Not so much about working around missing components by brokering to non-OpenStack commercial services. 20:32:57 which has specifically been a problem for Infra in the past as a consumer of OpenStack clouds 20:32:57 So I'm leaning towards a NO here. It's totally fine as an OpenStack-compatible project... It's just not what OpenStack is. 20:33:19 mordred: so CDN is special ? 20:33:23 I don't understand the contention here TBH 20:33:27 yes, I think so 20:33:56 I'm leaning towards a YES here, it abstracts out vendors and offers a standard REST API. This could be super useful in say, swift, or other APIs 20:33:58 ttx: I think given the nature of what CDNs are - I would rather have an OpenStack integrated way to integrate my openstack content with them 20:33:59 mordred: so you would also argue this is defcore? 20:34:00 mordred: as I posted on the review... if another project was proposed that only proxied requests to cloud services implemented at Amazon, Azure and GCE, we would certainly not consider that helping with our mission. CDN should not be judged differently ? 20:34:06 mordred: why is it the cloud's responsibility to provide cdn? 20:34:12 because if it's not defcore, it doesn't solve your problem 20:34:43 ttx: we are directly provising competitive software that builds a thing like amazon, gce or azure 20:34:46 ttx: but you're setting up a strawman in your post 20:34:53 ttx: so I think it would be specifically weird in that specific case 20:34:58 ttx: but in this specific case 20:34:59 ttx: those are all things that compete with openstack. CDNs don't do that. 20:35:03 ttx: the fact that there is no open backend *yet* is not the same as saying it will only accept proprietary backends 20:35:03 I also think that people never thought that Certs would be "free" but now we have Let's Encrypt. It's super useful for devs. 20:35:16 So I think that CDN provides something end users will want. 20:35:23 a cdn can be effective without being provided by your cloud vendor -- if one wanted to use a cdn, one could just use it. 20:35:28 I think that having a CDN interface is somethign that pretty much everyone who is deploying swift at public cloud scale has 20:35:39 jeblair: Well said, ++ 20:35:55 mordred: agree, and standards make our offering seem more holistic and user-centered 20:36:06 annegentle_, lifeless since you are for this, how do you see the project being tested without a commercial entity? 20:36:18 mordred: ^ 20:36:23 it is my understanding that the project has functional tests already 20:36:35 opencdn is an idea at this point 20:36:38 we have lots of examples of third-party CI already, too 20:36:39 it's not a ref implementation 20:36:56 dhellmann: there's nothing wrong with third party cis. that's not the concern I have 20:36:59 annegentle_: I think the cert thing is a bad example, certs were always free, and skilled people always ran their own CAs 20:36:59 thingee: I'd like to encourage the team to think about an open implementation next, but not block 20:37:07 the fact that all you have is third party cis is the concern 20:37:12 sdague: so skilled people won't run their own CDNs? 20:37:21 thingee: I'd want to see an open backend for testing; e.g. global swift cluster 20:37:27 I guess to me this is not open core becuase a CDN is not a thing that someone installs locally 20:37:28 annegentle_: they won't with poppy, because it doesn't allow that 20:37:29 mordred, lifeless: if there was an OpenStack project you could deploy to build a CDN using OpenStack clouds at multiple points of presence... would you still consider Poppy desirable ? 20:37:30 annegentle_: I'd argue being accepted in is a good motivator to make sure that happens 20:37:37 because it only does commercial ones 20:37:41 yeah thingee 20:37:47 there's no rush to get this in 20:37:51 ttx: yes, I would 20:37:58 ttx: yes, I would want it to have a backend to talk to that hypothetical service 20:38:00 sdague: we can reject until they have an open one, or accept with a trust level that "they are OpenStack" 20:38:08 a CDN is necessarily by definition a service someone consumes from someone - usually someone with a bunch of datacenters spread across the globe 20:38:09 mordred: where do you lean? 20:38:12 I don't think that allowing them to continue development but not be mentioned in governance is blocking them 20:38:15 ttx: because - workload portability, consider swift in-house and rackspace's CDN externally. 20:38:21 mordred: where you install it isn't the issue -- whether you can install it is 20:38:23 I have absolutely no problem with this joining the big tent 20:38:34 and I do not believe this is open core 20:38:41 I respect that other people disagree with me 20:38:50 I don't see this as open core either 20:38:54 lifeless: I hear you 20:38:58 and also am fine with disagreement :) 20:38:58 mordred: I don't, tbh! 20:39:02 open core would be if you had to get the drivers separately from the service providers, but that's not the case here 20:39:07 I believe that I can install poppy and I do not have to also install proprietary software to make it work 20:39:13 mordred: I mean, I don't disagree :P 20:39:14 ttx: not all openstack public clouds run swift; ceph is a thing 20:39:18 mordred: we have so many openstack projects today that have poor testing. This can't be tested continuously without the issues I raised dthat infra would have to depend on. Why are we adding to that? 20:39:37 thingee : then we'll highlight that in some way so potential users understand it 20:39:39 thingee: becuase I think that not having cdn integration available is worse 20:39:47 mordred: I agree that CDNs have certain properties that make them difficult to replicate, and that Poppy is certainly useful for our end users 20:39:54 thingee: turn it around; what do we need the project to do to not be a testing burden. 20:40:03 thingee: thats actionable advice we can give 20:40:29 I believe that as an end user I have been excluded from using services in the clouds I consume because there was no openstack cdn gateway that those vendors had the choice of using, thus there was no openstack api I could talk to 20:40:32 I feel like the conversation is leading towards forcing the project to have a way to run local tests even though those tests won't even be sufficient/good 20:40:40 mordred: I'm trying to reconcile this with a rule we can apply, and with our recent discussions on what "no Open core" means today 20:40:42 thingee: why because of timing does one team get penalized? We're the ones that opened up the big tent. 20:40:46 mordred: i guess whether this is open-core depends on some pretty precise semantics -- but regardless, this is an open source project that is simply a proxy to a proprietary service -- it doesn't feel very open source to me. 20:40:48 I understand the concern of testing and I think it's important 20:40:53 mordred / lifeless - I think what you are both saying though is not only is poppy openstack, but it's also got to immediately move to defcore, as that is required to give people guaruntees 20:40:55 We also need to be good stewards of the end users who need better services. 20:40:59 jeblair: agreed 20:41:01 annegentle_: because, we've evolved and matured. 20:41:03 ttx: I believe that we have rules to guide us - and that we have human judgement we can apply when the rules themselves are insufficent 20:41:07 but I don't believe the answer is: "come back with an open source backend to run your tests on" 20:41:08 we expect quality 20:41:10 sdague: uhm, I wasn't saying that. Let me thing. 20:41:12 think 20:41:15 sdague: not the point 20:41:22 I disagree that continuing development and not being mentioned in governance equates to penalty 20:41:28 mordred: you may have had an experience in infra that i did not have 20:41:55 jeblair: one of the reasons we could not use hpcloud's swift was that the only way to make a container public in hp was to use the hpcloud specific cdn service 20:42:18 mordred: that is a deployment choice, not a limitation of OpenStack itself 20:42:20 i believe the bad experience around this is that a particular openstack provider makes their swift implementation unusable without also using their non-openstack cdn 20:42:26 jeblair: the hp cloud team did, in fact, open source that code, but as it was not openstack there wasn't really a push for any of the other clouds to collaborate or adopt it 20:42:31 lifeless: not sure how anyone missed my repeating of an actionable item of a good reference implementation 20:42:32 mordred: because swift can not be exposed without a CDN? 20:42:36 sdague: is trove defcore? 20:42:43 anteaya: one Q on third-party testing, is it possible for poppy to be in governance but only have third-party ci for a time? 20:42:47 mordred: that was rax, I think hpcloud did mostly work via public urls 20:42:53 mordred: but its gone now so doesn't matter 20:42:55 clarkb: k 20:43:02 sdague: no, it is just how people deploy it 20:43:13 so - honestly - I do not believe we're going ot argue each other into agreeing with each other 20:43:15 which in itself should maybe be a defcore test 20:43:17 mordred: sure, but we did not want to use a cdn. and if we did want to use a cdn (as a cdn), we are not limited to the one provided by the cloud 20:43:19 mordred: so you would equate CDNs to electricity or the global DNS system, something that exists beyond openstack and that our end users need access to in order to breathe 20:43:21 i understand swift _can_ be used without a cdn, so perhaps what needs to be defcore (if swift is also defcore) is a way to effectively use swift without also having to use a cdn 20:43:23 right I think that a vote is what works here 20:43:25 annegentle_: that is up to the tc, but if the only testing they have is third party I would wonder why they are in governance 20:43:32 ok 20:43:35 it's ajudgement call as to whether or not an open source project that proxies to non-locally-installable local services is open core or not 20:43:37 fungi: +1 20:43:39