20:01:10 <ttx> #startmeeting tc
20:01:10 <openstack> 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 <russellb> hi
20:01:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:13 <thingee> o/
20:01:14 <openstack> The meeting name has been set to 'tc'
20:01:18 <ttx> Hi everyone!
20:01:20 <mordred> o/
20:01:24 <ttx> Here is our agenda for today:
20:01:24 <eil397> o/
20:01:29 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:39 <ttx> #topic Applying Tacker for Big Tent
20:01:43 <ttx> #link https://review.openstack.org/276417
20:01:51 <ttx> Quick background
20:01:55 <ttx> As I understand it (russellb please correct me if I got it wrong)
20:02:00 <ttx> Tacker is a NFV component designed to fit in the ETSI architecture model
20:02:06 <ttx> OpenStack is used as the Virtualized Infrastructure Manager in the model
20:02:16 <ttx> And Tacker provides the glue between NFV and OpenStack by implementing the "VNF Manager" and "Orchestrator" components of the ETSI framework
20:02:20 <ttx> #link https://www.opnfv.org/software/technical-overview
20:02:29 <ttx> So I suppose it's not meant to be enduser-facing APIs
20:02:39 <ttx> While it's not very advanced, they already have a variety of contributing organizations
20:02:40 <dhellmann> is this a special case for what heat does? or is it using heat?
20:02:47 <russellb> roughly ... I thought this was the VNF manager
20:02:53 <russellb> it's using heat
20:02:57 <mestery> russellb: I thought it was that plus something else?
20:03:07 <russellb> well ... it's also got some custom SFC stuff ...
20:03:12 <mestery> It's the VNF manager AND the orchestrator
20:03:12 <ttx> russellb: btw: https://imgflip.com/i/yvatt
20:03:19 <mestery> russellb: OF course it does
20:03:24 <dtroyer> o/
20:03:38 <russellb> it uses Heat to create VMs that are used to implement networking services
20:03:51 <ttx> They have been around for a while now and have been using the ML and IRC meetings for open collaboration
20:03:51 <thingee> ttx: ++
20:03:55 <russellb> it *also* includes an API for doing SFC, but it calls directly into OpenDaylight to do so
20:04:04 <russellb> it really needs to be reworked to integrate properly with Neutron
20:04:09 <russellb> but I think they have good intent to do so
20:04:29 <russellb> (yes this is an acronym overload space.....)
20:04:31 <mestery> russellb: I'd think so. Do they work with ONOS too with that SFC API?
20:04:34 <ttx> Looks like they still need to adjust some tags on the proposal
20:04:41 <russellb> not positive, i think it's been ODL focused so far
20:04:42 * dhellmann wonders what language mestery is speaking
20:04:44 <ttx> questions / comments ?
20:04:46 <annegentle_> heh I was still looking up esti
20:04:59 <russellb> ETSI == standards body
20:05:06 <flaper87> 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 <ttx> flaper87: I wouldn't be surprised if they could not assert anything at this stage
20:05:49 <mestery> I posted my comments on the SFC API mess
20:05:57 <annegentle_> is tacker already in the neutron stadium?
20:06:00 <ttx> 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 <dhellmann> oops
20:06:09 <mestery> annegentle_: It was never in the neutron stadium
20:06:10 * annegentle_ tries to keep up
20:06:18 <flaper87> ttx: they are changing the release model based on the latest comment
20:06:19 <dhellmann> given our recent open core discussion, and the general nature of the networking space, how much of this is actually open?
20:06:25 <ttx> flaper87: ah, nice
20:06:31 <sdague> as this is mostly network oriented I'd be highly currious on russellb, mestery, and markmcclain's feelings here
20:06:47 <flaper87> and the standard-deprecation one would be nice to have
20:06:48 <mestery> sdague: My main concern is on yet another SFC API
20:06:53 <ttx> dhellmann: I think it's pretty neutral. It just exposes OpenStack resources in a wat NFV likes to have them
20:06:54 <mestery> Otherwise, I have no concerns
20:06:58 <russellb> tacker is not a part of neutron, in fact it bypasses neutron
20:06:58 <ttx> way*
20:07:00 <flaper87> but it depends on how solid they think their API is
20:07:03 <mestery> Well, I mean other htan it ties directly to ODL
20:07:07 <lifeless> ttx: o/
20:07:10 <mestery> tacker has NEVER been a part of neutron
20:07:10 <russellb> it overlaps with part of neutron in the API space
20:07:16 <russellb> but they've said they want to integrate with neutron
20:07:18 <mestery> Even when it was NOT an NFV orchestrator
20:07:39 <russellb> 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 <jaypipes> 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 <markmcclain> my only observation is we've tried to discuss working with them in prior cycles
20:08:00 <mestery> jaypipes: Seems reasonable to me at first glance
20:08:01 <dhellmann> russellb : "bypasses neutron" in what way?
20:08:07 <russellb> jaypipes: but OPNFV doesn't produce code, in theory
20:08:17 <jaypipes> russellb: they do, apparently. :)
20:08:21 <russellb> dhellmann: implementing SFC requires coordination with what Neutron does
20:08:30 <russellb> to do things in a way that is compatible with all Neutron backends
20:08:33 <markmcclain> and the functionality between astara and tacker do overlap is many places
20:08:44 <russellb> this sort of ignores that and calls directly into an SDN controller
20:08:53 <mestery> Right
20:09:02 <dhellmann> russellb : so is it incompatible with neutron? or supplemental?
20:09:11 <russellb> depends on what backend you use
20:09:15 * ttx thought he understood it but now is confused
20:09:26 <russellb> it's messy.
20:09:32 <mestery> russellb: It is
20:09:39 <mestery> Because it talks directly to ODL
20:09:41 <mestery> Which sets up networkign with neutron, right?
20:09:41 <annegentle_> so we're sort of supporting both reference architectures and changes to neutron by enabling tacker in the ecosystem?
20:09:52 <mestery> annegentle_: There are no neutron changes proposed
20:09:53 <dhellmann> 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 <mestery> dhellmann: Good summary
20:10:02 <russellb> dhellmann: yes
20:10:11 <russellb> though the networks are neutron networks
20:10:14 <dtroyer> that doesn't sound too friendly to the overall could
20:10:17 <flaper87> holy moly
20:10:18 <dtroyer> cloud
20:10:19 <ttx> russellb: but that is what NFV is about, right
20:10:27 <russellb> ttx: which part
20:10:28 <mestery> ttx: NFV is about bypassing neutron?
20:10:31 <ttx> using vms to do networking
20:10:32 <mestery> I may quote you on that ttx
20:10:36 <russellb> using vms to do networking, yes
20:10:39 <flaper87> mestery: lol
20:10:42 <russellb> from a high level, this is all sane
20:10:47 <dhellmann> ttx: that's not the part that concerns me, the bypassing bit is
20:10:48 <sdague> service vms right?
20:10:50 <russellb> it needs to be integrated better
20:11:01 <russellb> (if we care to include that in criteria)
20:11:01 <dtroyer> the 'depends on which backend' part concerns me
20:11:03 <mestery> russellb: Yes, because right now it's bypassing neutron and using ODL directly
20:11:15 <mestery> russellb: Isn't it? Or is it no longer doing that?
20:11:17 <sdague> doing service vms was a huge part of nfv
20:11:18 <russellb> it is yes
20:11:24 <russellb> service vms *is* NFV :)
20:11:28 <mestery> OK, I knew at one point it was
20:11:28 <flaper87> russellb: you mentioned you've seen the intent from the team to integrate better with neutron, right?
20:11:29 <sdague> :)
20:11:31 <mordred> 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 <russellb> flaper87: yes
20:11:39 <flaper87> Should this be put on-hold and wait until that happens ?
20:11:39 <dhellmann> how does this relate to any of  our networking projects other than neutron?
20:11:56 <jaypipes> do we not have a tacker representative here?
20:11:57 <russellb> flaper87: we aren't really holding other projects to integration bars like that....
20:11:58 <mestery> flaper87: ++
20:12:05 <mordred> 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 <russellb> not that i disagree with the idea, just saying
20:12:09 <markmcclain> dhellmann: it shares similar functionality as Astara
20:12:14 <sridhar_ram> jaypipes: yes, listening in...
20:12:18 <ttx> mordred: yeah, that's where I am too
20:12:21 <russellb> i don't think overlap with astara is really relevant
20:12:22 <dhellmann> markmcclain : does astara have an API now?
20:12:30 <russellb> given that astara itself overlapped with existing stuff significantly, as well
20:12:31 <markmcclain> plugin API yes
20:12:39 <markmcclain> public facing REST API no
20:12:41 <jaypipes> sridhar_ram: do you have any comments or answers to the above lines of questioning and commentary?
20:12:42 <dhellmann> markmcclain : ok
20:12:42 <mordred> 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 <ttx> mordred: I think they help with the "ubiquitous" part of the mission by making openstack consumable by NFV folks
20:12:58 <mordred> ttx: I agree
20:13:03 <dhellmann> mordred : I thought tacker had a rest api?
20:13:12 <ttx> even if the way they consumz it makes little sense to us
20:13:14 <flaper87> that's what they claim in the patch
20:13:19 <sdague> russellb / mestery - how does it completely bypass neutron? How are actually compute VMs connected in this environment?
20:13:25 <thingee> dhellmann: it does
20:13:28 <lifeless> dhellmann: rest API ~= end user API I presume
20:13:32 <mordred> dhellmann: I thought russel said that it wasn't supposed to be for end-users of the cloud
20:13:34 <thingee> dhellmann: note in the comments when I asked about their rest api
20:13:36 <sridhar_ram> 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 <russellb> omg i can't keep up
20:13:42 <mestery> sdague: It's talking to ODL to wire the networking up I believe, russellb correct me if I'm wrong here
20:13:46 <thingee> mordred: that maybe true, but they still have a rest api
20:13:49 <flaper87> russellb: me neither
20:13:56 <dhellmann> russellb : it's all the acronyms
20:13:58 <mestery> sridhar_ram: Does this use ODL directly to wire networking up for the VMs?
20:14:01 <sdague> mestery: right, but you still need to coordinate with nova somehow
20:14:03 <mordred> dhellmann: +100
20:14:06 <ttx> thingee: not really a enduser-oriented one though
20:14:12 <mestery> 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 <russellb> it's unrelated to actual VIF plugging
20:14:16 <thingee> ttx: correct, still a rest api though
20:14:21 <markmcclain> 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 <flaper87> 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 <mordred> flaper87: ++
20:14:37 <mestery> flaper87: Just get more bandwidth
20:14:37 * mestery ducks
20:14:42 <ttx> voice is to russellb so that he can empty his buffer
20:14:49 <mordred> markmcclain: that is a statement that concerns me
20:14:53 <russellb> my overflowed and emptied
20:14:54 <flaper87> mestery: LOOOOL
20:15:02 <sridhar_ram> 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 <flaper87> Looks like we have sridhar_ram here and he can elaborate on some questions
20:15:30 <sridhar_ram> mestery: in fact neutron-sfc team members like cathy, louisef are planning to contribute the tacker part of the integration
20:15:35 <flaper87> Can we start by asking 1 at a time?
20:15:37 <flaper87> pretty please?
20:15:39 <mestery> sridhar_ram: cool
20:16:17 <sridhar_ram> 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 <russellb> 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 <odyssey4me> heh, and now there's no conversation :p
20:16:27 <dhellmann> sridhar_ram : where do the images managed by tacker come from?
20:16:33 <ttx> odyssey4me: I blame flaper87
20:16:37 <sridhar_ram> dhellmann: glance
20:16:54 <flaper87> russellb: ++ sounds fair to me
20:16:59 <dhellmann> 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 <russellb> I *think* I have a decent idea of where the concerns/questions are, and hopefully I can try to address them
20:17:34 <russellb> or at least express them on the review to give a chance for a clear answer
20:17:41 <ttx> OK, maybe we could all post our concerns in one line really fast
20:17:50 <ttx> if we have some
20:17:55 <russellb> sure, and give me an action to follow up on the review
20:17:59 <sridhar_ram> 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 <dhellmann> 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 <ttx> markmcclain: I hear you're concerned with lack of cooperation and gratuitous duplication
20:18:53 <mestery> dhellmann: You're asking are their open source images to use, right? That's a good question!
20:18:59 <ttx> and there is some concern around how it works around neutron, but I fear we enter implementation space
20:19:24 <ttx> dhellmann: arguably a gateway service is not useful on its own
20:19:26 <russellb> yep, some of that may be interesting to explore in comments, though it may not affect the actual vote
20:19:33 <dhellmann> 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 <ttx> dhellmann: like EC2API
20:19:49 <russellb> it's worse than just images
20:19:51 <annegentle_> dhellmann: my question as well
20:19:51 <thingee> dhellmann: +1 also from a testing perspective, please.
20:19:55 <russellb> even the infrastructure that this depends on is WIP
20:20:03 <russellb> OVS itself doesn't even have the functionality this depends on merged yet
20:20:03 <dhellmann> ttx: EC2API can be used by pointing it at OpenStack
20:20:10 <rockyg> thingee ++
20:20:55 <sridhar_ram> 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 <dhellmann> 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 <mestery> sridhar_ram: Excellent, that's good to know (regarding OpenWRT).
20:21:46 <ttx> dhellmann: i see your point
20:21:51 <russellb> dhellmann: not quite, it's all open source stuff
20:21:59 <russellb> but there's a ton of WIP here
20:21:59 <mestery> OpenWRT is open source last time I checked
20:22:01 <fungi> openwrt is a pretty excellent network operating system in fact (now if only openbsd could be properly virtualized)
20:22:07 <dhellmann> russellb : ok, I said "not clear" -- I'm not familiar with the space
20:22:10 <jeblair> using openwrt for this is kind of a cool idea
20:22:13 <dtroyer> mestery: it still is ;)
20:22:16 <russellb> dhellmann: yep, just answering :)
20:22:35 <clarkb> mestery: it depends on the imgae iirc
20:22:42 <clarkb> some come with driver blobs
20:22:51 <clarkb> but you can do it completely open source
20:22:58 <fungi> which for a virtual appliance should hopefully be entirely unnecessary
20:23:02 <clarkb> fungi: yup
20:23:04 <mestery> clarkb: Isn't that the case for many Linux distros? (But we're taking a sideways ride ...)
20:23:13 <dtroyer> a project like this must build their own images to be useful…
20:23:14 <sridhar_ram> clarkb: recent openwrt images works nicely with tacker.. we are auto uploading the image as part of tacker devstack install
20:23:39 <clarkb> 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 <jaypipes> "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 <clarkb> depends on how you built it where you got it from
20:23:55 <mestery> sridhar_ram: Out of curiosity, what types of VNFs does OpenWRT provide?
20:24:04 <ttx> 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 <dhellmann> 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 <jaypipes> mestery: it doesn't.
20:24:19 <jeblair> dhellmann: ++
20:24:29 <mestery> jaypipes: That's what I was figuring :)
20:24:33 <jaypipes> mestery: it's just the base OS image to build VNFs from.
20:24:46 <dhellmann> ttx: ++
20:24:53 <sridhar_ram> 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 <ttx> also ETOOMANYACRONYMS
20:25:03 <anteaya> ttx ++
20:25:17 <jaypipes> ttx: welcome to telco :)
20:25:22 <ttx> so digging in is not easy
20:25:34 <mestery> jaypipes: Say what? So they use OpenWRT for only routing then by default? I'm confused.
20:25:59 <thingee> 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 <dtroyer> OpenWRT makes a pretty decent micro-Linux base for a lot of things…not just routers
20:26:50 <ttx> 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 <jaypipes> 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 <russellb> but to make that useful, it has to actually instruct the underlying network implemenation to send packets through it
20:27:38 <russellb> and it seems that's not actually merged at all
20:27:39 <jaypipes> thingee: just don't use the acronym OSS. OSS means something different in telco-land :)
20:27:49 <jaypipes> thingee: Operational Support Systems
20:27:53 <russellb> and the one that's furthest along is specific to one SDN controller, and bypasses neutron
20:27:54 <ttx> jaypipes: what doesn't
20:27:58 <jaypipes> heh, indeed
20:28:00 * flaper87 back... he hopes
20:28:11 <mestery> russellb: Then why are we adding this to openstack?
20:28:11 <thingee> jaypipes: fair point!
20:28:17 <ttx> russellb: could you quickly expand on the "OPNFV doesn't do code" assertion ?
20:28:19 <mestery> If that's the case, we should wait
20:28:27 <russellb> ttx: OPNFV is a test and integration project
20:28:35 <ttx> russellb: I thought they were producing something that used OpenStack and needed Tacker to interface
20:28:39 <russellb> they may write code, but their intent is to do all coding in upstreams
20:28:48 <annegentle_> so do they need tacker as their upstream?
20:28:56 <russellb> they would never own code within OPNFV
20:29:03 <russellb> that's the idea.
20:29:03 <jaypipes> 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 <ttx> Ah. So they would rather have the openstack-touching piece in OpenStack
20:29:07 <russellb> yes.
20:29:20 <annegentle_> still, it's a ref arch
20:29:26 <russellb> jaypipes: OPNFV doesn't see it that way.  they'd like to add whatever is needed openstack itself.
20:29:26 <annegentle_> (right?)
20:29:27 <lifeless> thats kinda weird
20:29:44 <jaypipes> russellb: do we take direction from OPNFV now? :)
20:29:49 <mestery> lol
20:29:52 <russellb> no....
20:30:08 <jaypipes> russellb: that came out wrong, sorry...
20:30:10 <russellb> 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 <russellb> and if we see it as "not integrated well enough", that's good feedback
20:30:31 <annegentle_> ok
20:30:33 <russellb> in fact, i have provided that feedback, and it seems to be taken
20:30:33 <ttx> OK, I think we have primed the pump now. I suggest we move on to next topic
20:30:43 <jaypipes> russellb: I'm trying to point out that NFV != OpenStack and Tacker is NFV more than OpenStack, IMNSHO.
20:30:43 <lifeless> ok, thats cool. are they participating in design summit sessions?
20:30:52 <ttx> and use the review to talk between now and next meeting
20:30:57 <russellb> sounds good
20:31:01 <mestery> ++
20:31:16 <ttx> plenty of un in next topic too!
20:31:20 <ttx> +f*
20:31:23 <ttx> #topic Adds the Poppy CDN project to the Governance Repository
20:31:31 <ttx> #link https://review.openstack.org/273756
20:31:37 <ttx> So, round 2 of discussions around Poppy
20:31:44 <ttx> The main objection raised so far is around the nature of the service vs. the OpenStack mission
20:31:55 <ttx> 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 <ttx> Poppy is definitely compatible with OpenStack and part of the OpenStack "ecosystem". It's even developed in the OpenStack Way.
20:32:20 <ttx> 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 <ttx> OpenStack is precisely about open source infrastructure building blocks you can use to provide services yourself.
20:32:43 <mordred> 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 <dhellmann> it also helps support hybrid and federated cloud solutions, because of the API abstraction
20:32:50 <ttx> Not so much about working around missing components by brokering to non-OpenStack commercial services.
20:32:57 <mordred> which has specifically been a problem for Infra in the past as a consumer of OpenStack clouds
20:32:57 <ttx> 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 <ttx> mordred: so CDN is special ?
20:33:23 <lifeless> I don't understand the contention here TBH
20:33:27 <mordred> yes, I think so
20:33:56 <annegentle_> 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 <mordred> 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 <sdague> mordred: so you would also argue this is defcore?
20:34:00 <ttx> 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 <jeblair> mordred: why is it the cloud's responsibility to provide cdn?
20:34:12 <sdague> because if it's not defcore, it doesn't solve your problem
20:34:43 <mordred> ttx: we are directly provising competitive software that builds a thing like amazon, gce or azure
20:34:46 <lifeless> ttx: but you're setting up a strawman in your post
20:34:53 <mordred> ttx: so I think it would be specifically weird in that specific case
20:34:58 <mordred> ttx: but in this specific case
20:34:59 <dhellmann> ttx: those are all things that compete with openstack. CDNs don't do that.
20:35:03 <lifeless> 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 <annegentle_> 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 <annegentle_> So I think that CDN provides something end users will want.
20:35:23 <jeblair> 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 <mordred> 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 <mestery> jeblair: Well said, ++
20:35:55 <annegentle_> mordred: agree, and standards make our offering seem more holistic and user-centered
20:36:06 <thingee> annegentle_, lifeless since you are for this, how do you see the project being tested without a commercial entity?
20:36:18 <thingee> mordred: ^
20:36:23 <mordred> it is my understanding that the project has functional tests already
20:36:35 <thingee> opencdn is an idea at this point
20:36:38 <dhellmann> we have lots of examples of third-party CI already, too
20:36:39 <thingee> it's not a ref implementation
20:36:56 <thingee> dhellmann: there's nothing wrong with third party cis. that's not the concern I have
20:36:59 <sdague> 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 <annegentle_> thingee: I'd like to encourage the team to think about an open implementation next, but not block
20:37:07 <thingee> the fact that all you have is third party cis is the concern
20:37:12 <annegentle_> sdague: so skilled people won't run their own CDNs?
20:37:21 <lifeless> thingee: I'd want to see an open backend for testing; e.g. global swift cluster
20:37:27 <mordred> I guess to me this is not open core becuase a CDN is not a thing that someone installs locally
20:37:28 <sdague> annegentle_: they won't with poppy, because it doesn't allow that
20:37:29 <ttx> 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 <thingee> annegentle_: I'd argue being accepted in is a good motivator to make sure that happens
20:37:37 <sdague> because it only does commercial ones
20:37:41 <annegentle_> yeah thingee
20:37:47 <thingee> there's no rush to get this in
20:37:51 <lifeless> ttx: yes, I would
20:37:58 <dhellmann> ttx: yes, I would want it to have a backend to talk to that hypothetical service
20:38:00 <annegentle_> sdague: we can reject until they have an open one, or accept with a trust level that "they are OpenStack"
20:38:08 <mordred> 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 <annegentle_> mordred: where do you lean?
20:38:12 <anteaya> I don't think that allowing them to continue development but not be mentioned in governance is blocking them
20:38:15 <lifeless> ttx: because - workload portability, consider swift in-house and rackspace's CDN externally.
20:38:21 <jeblair> mordred: where you install it isn't the issue -- whether you can install it is
20:38:23 <mordred> I have absolutely no problem with this joining the big tent
20:38:34 <mordred> and I do not believe this is open core
20:38:41 <mordred> I respect that other people disagree with me
20:38:50 <annegentle_> I don't see this as open core either
20:38:54 <ttx> lifeless: I hear you
20:38:58 <annegentle_> and also am fine with disagreement :)
20:38:58 <flaper87> mordred: I don't, tbh!
20:39:02 <dhellmann> 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 <mordred> I believe that I can install poppy and I do not have to also install proprietary software to make it work
20:39:13 <flaper87> mordred: I mean, I don't disagree :P
20:39:14 <lifeless> ttx: not all openstack public clouds run swift; ceph is a thing
20:39:18 <thingee> 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 <dhellmann> thingee : then we'll highlight that in some way so potential users understand it
20:39:39 <mordred> thingee: becuase I think that not having cdn integration available is worse
20:39:47 <ttx> 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 <lifeless> thingee: turn it around; what do we need the project to do to not be a testing burden.
20:40:03 <lifeless> thingee: thats actionable advice we can give
20:40:29 <mordred> 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 <flaper87> 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 <ttx> 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 <annegentle_> thingee: why because of timing does one team get penalized? We're the ones that opened up the big tent.
20:40:46 <jeblair> 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 <flaper87> I understand the concern of testing and I think it's important
20:40:53 <sdague> 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 <annegentle_> We also need to be good stewards of the end users who need better services.
20:40:59 <sdague> jeblair: agreed
20:41:01 <thingee> annegentle_: because, we've evolved and matured.
20:41:03 <mordred> 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 <flaper87> but I don't believe the answer is: "come back with an open source backend to run your tests on"
20:41:08 <thingee> we expect quality
20:41:10 <lifeless> sdague: uhm, I wasn't saying that. Let me thing.
20:41:12 <lifeless> think
20:41:15 <annegentle_> sdague: not the point
20:41:22 <anteaya> I disagree that continuing development and not being mentioned in governance equates to penalty
20:41:28 <jeblair> mordred: you may have had an experience in infra that i did not have
20:41:55 <mordred> 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 <dtroyer> mordred: that is a deployment choice, not a limitation of OpenStack itself
20:42:20 <fungi> 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 <mordred> 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 <thingee> lifeless: not sure how anyone missed my repeating of an actionable item of a good reference implementation
20:42:32 <sdague> mordred: because swift can not be exposed without a CDN?
20:42:36 <lifeless> sdague: is trove defcore?
20:42:43 <annegentle_> 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 <clarkb> mordred: that was rax, I think hpcloud did mostly work via public urls
20:42:53 <clarkb> mordred: but its gone now so doesn't matter
20:42:55 <mordred> clarkb: k
20:43:02 <clarkb> sdague: no, it is just how people deploy it
20:43:13 <mordred> so - honestly - I do not believe we're going ot argue each other into agreeing with each other
20:43:15 <clarkb> which in itself should maybe be a defcore test
20:43:17 <jeblair> 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 <ttx> 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 <fungi> 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 <annegentle_> right I think that a vote is what works here
20:43:25 <anteaya> 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 <annegentle_> ok
20:43:35 <mordred> 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 <clarkb> fungi: +1
20:43:39 <mordred> I break one way
20:43:41 <jeblair> mordred: i feel like the swift example is flawed, because that's an implementation detail that should not have leaked into the public api
20:43:42 <mordred> other break the other way
20:44:06 <lifeless> sdague: so, trove is not in defcore AFAICT, but people find it useful and valuable, or so I'm told
20:44:10 <jeblair> mordred: (if cloud-provider wants a cdn in front of swift, just put one there and don't tell the customer)
20:44:24 <mordred> jeblair: sure
20:44:30 <lifeless> sdague: I don't see why suggesting that this can have the same properties implies it must be in defcore
20:44:39 <notmyname> for the record, the rax cloud is the exception, not the common case. they're the only swift deployer I know of who disables direct access to publicly readable data.
20:44:44 <mordred> ttx: yes
20:44:53 <ttx> OK, I'd like to talk about the Cassandra dependency quickly, and the fact that it kind of depends on the Oracle JDK
20:44:53 <mordred> ttx: what you said is more how I look at this
20:45:08 <ttx> is that an issue or not ?
20:45:09 <sdague> notmyname: ok, which means they are the only ones that need poppy, because of other decisions they made?
20:45:25 <annegentle_> the Cassandra dependency appears to be for local dev testing
20:45:30 <amitgandhinz> fwiw, poppy plans to add the ability to pass authorization headers to allow for non public readable containers
20:45:36 <dhellmann> ttx: can you elaborate? I think I missed the stuff about cassandra
20:45:52 <flaper87> dhellmann: the only supported backend is Cassandra, AFAIU
20:45:55 <lifeless> https://github.com/openstack/poppy/blob/master/setup.py makes me sad
20:46:04 <lifeless> very very sad
20:46:05 <annegentle_> but I could be wrong, https://github.com/openstack/poppy#getting-started was what I was looking at
20:46:13 <dhellmann> flaper87 : cassandra isn't a cdn? I don't understand.
20:46:13 <amitgandhinz> we currently have the cassandra driver which is production ready.  we can build another db driver if necessary since that is pluggable
20:46:14 <ttx> dhellmann: Poppy has a dependency on Cassandra. Cassandra's authors ask you to install Oracle JDK and don't support OpenJDK
20:46:30 <fungi> that makes it effectively non-free
20:46:36 <mordred> cassandra seems excessively heavy for local testing
20:46:37 <ttx> fungi: right
20:46:41 <amitgandhinz> the cassandra driver is just to store the cdn settings, so that they can then be provisioned to any other cdn provider with the master copy held in poppy
20:46:42 <dhellmann> yeah, that's more of a concern than the open core aspect
20:46:42 <flaper87> dhellmann: sorry, database backend to store metadata or whatever they save there
20:46:53 <amitgandhinz> flaper87: +1
20:46:54 <flaper87> and I believe that's more a concern than the previous topic
20:46:55 <dhellmann> amitgandhinz : why aren't you using mysql?
20:46:55 <lifeless> there are two drivers; mockdb and cassandra
20:47:04 <lifeless> it doesn't look like cassandra is for local testing at all...
20:47:13 <fungi> and i'm guessing mockdb is only for testing, given its name
20:47:18 <ttx> dhellmann: you mean "why aren't you using oslo.db"
20:47:25 <flaper87> amitgandhinz: ^
20:47:25 <dhellmann> ttx: yes, well
20:47:27 <amitgandhinz> dhellmann: it was mostly for the distributed usecase we were going for which cassandra helped us meet
20:47:31 <mordred> awesome. so - for that, I think we have two things where this does not behave much like an openstack project- the cassandra driver, and the very strange setup.py
20:47:56 <flaper87> mordred: the setup.py is easy (TM) to refactor, I think
20:48:11 <annegentle_> flaper87: easy button (tm) :)
20:48:11 <flaper87> the casandra driver might require more work
20:48:12 <mordred> flaper87: I do not htink it's easy to refactor
20:48:16 <lifeless> The (tm) will certainly apply there
20:48:37 <ttx> I for one would prefer if there were options beyond cassandra
20:48:39 <lifeless> mordred: it is, its just cat $(find requirements) | grep -v -- - > requirements.txt
20:48:45 <fungi> it is interesting that poppy has extended pbr to support requirements directories, without workign with pbr upstream to actually implement that
20:48:46 <flaper87> mordred: Did I mention I had no idea what I was talking about?
20:49:06 <ttx> but I don't really want to ask them to work on that if we plan to reject them on the "no open source backend" reason
20:49:08 <flaper87> mordred: jokes apart, what I menat is that it might require less time than adding a new driver
20:49:11 <dhellmann> fungi : at one point pbr did support multiple requirements files, didn't it? or did we just talk about that?
20:49:22 <mordred> it's more the thing fungi mentions
20:49:58 <mordred> this is a divergent view on pbr things - and the database backend is strange - especially for something the purpose of which is "store configuration settings" - neither of those 'feel' openstack-like to me
20:50:02 <lifeless> fungi: dhellmann: it was proposed, and rejected
20:50:05 <fungi> dhellmann: it supports/supported interpreter-specific requirements sets, but i don't recall a general requirements file aggregation feature
20:50:14 <dhellmann> lifeless : ah
20:50:49 <dhellmann> yeah, so without getting into the specifics (use "extras"), the setup thing can be changed relatively easily but the db driver will take more work
20:50:52 <annegentle_> I think we can summarize for amitgandhinz
20:50:56 <dhellmann> amitgandhinz: do you have plans for other db drivers?
20:50:59 <ttx> mordred: I'm fine delaying them to get better alignment, but I would rather settle the "open core or not" question first
20:51:04 <lifeless> we're converging on upstream's practices, and the use of directories was pretty much opposite - not to mention that the interactions between the existing, broken, -pyN stuff and directories would have been very hard to track
20:51:14 <ttx> mordred: otherwise we ask them to change things only to reject them in the end
20:51:21 <mordred> ttx: I agree
20:51:21 <flaper87> ttx: how can we settle on the open core question and stil ldelay them? IRC vote ?
20:51:29 <flaper87> ttx: that said, I agree
20:51:43 <lifeless> ttx: so you're saying this is open core because there is no openstack CDN implementation ?
20:51:53 <amitgandhinz> dhellmann: we have it on the roadmap to do a mysql driver, but no one has asked for it yet so hasnt been a big priority
20:51:54 <ttx> flaper87: yeah, something like that. There is clearly no consensus on that issue
20:52:06 <fungi> or simply no viable and supported free/libre cdn software
20:52:15 <dhellmann> amitgandhinz : think you're going to be told that will be a requirement, any minute now
20:52:17 <lifeless> fungi: other than swift ;)
20:52:20 <amitgandhinz> lol
20:52:23 <fungi> wouldn't have to be "openstack" cdn software
20:52:25 <flaper87> ttx: I'd prefer delaying the vote until next week and give people more time to go through their ideas and what was discussed here.
20:52:27 <ttx> lifeless: I'm not saying anything. I'm torn on this one
20:52:37 <flaper87> That said, I think IRC vote is fine for the open core question
20:52:40 <lifeless> TBH the cassandra thing doesn't bother me. I know it bothers other folk :)
20:52:43 <amitgandhinz> so im okay being given a list of action items, but want to make sure there is a well defined list and we settle the open core issue
20:52:48 <fungi> lifeless: swift as a cdn? i'd be interested to see that model
20:53:26 <amitgandhinz> the rest is just code that the team can handle ;-)
20:53:33 <lifeless> fungi: global swift clusters have been a thing for a couple years now
20:53:40 <ttx> amitgandhinz: yes, we need to come to a decision on the larger issue first
20:53:45 <mordred> lifeless: that's an excellent point
20:53:53 <lifeless> fungi: obviously notmyname can say much more than I
20:54:03 <fungi> i suppose cdn doesn't have to mean "caching web proxy"
20:54:18 <fungi> so point taken
20:54:29 <ttx> Maybe Poppy could interface with a set of Swift things
20:54:33 <notmyname> lifeless: you speak truth (but IMO global swift != CDN)
20:54:35 <lifeless> fungi: generally cdn's don't mean that anymore TBH - pre-loading of content is very common, as is edge processing
20:54:58 <lifeless> notmyname: ok, would like to deep dive another time
20:55:02 <jeblair> notmyname: aren't folks doing processing in swift now?
20:55:12 <flaper87> so, what's the plan? Vote now or next week? The meeting is about to end and there still seem to be some points being made
20:55:32 <flaper87> I'd rather defer to next week and do a "vote only" topic
20:55:38 <ttx> OK, I propose we continue that discussion and vote at the next meeting.
20:55:42 <mordred> flaper87: it seems a week of flames I mean messages to a mailing list would be useful for folks
20:55:57 <flaper87> mordred: wasn't that last week ?
20:56:03 * flaper87 stfu
20:56:10 <mordred> flaper87: isn't that every week?
20:56:12 <ttx> #info we need to settle the open core issue first, and then come up with a list of things to change before acceptance
20:56:16 <flaper87> mordred: touche
20:56:24 <ttx> which brings us to next topic
20:56:25 <amitgandhinz> fwiw i appreciate the positive useful conversations that have happened on this topic (without it becoming too much of a flame war) ;-)
20:56:26 <notmyname> jeblair: yes, with ecosystem integration things plugged into swift
20:56:34 <ttx> #topic Open discussion
20:56:37 <annegentle_> amitgandhinz: good, yes.
20:56:39 <ttx> I'll be away snowboarding next week, so I won't be around to chair the meeting if we are holding it
20:56:48 <ttx> There is the Ops midcycle in Europe too, which is likely to draw some attention away
20:56:54 <ttx> We can skip, or else I'll need a volunteer for chairing
20:56:56 * mordred will be at ops midcycle
20:57:01 <anteaya> ttx: happy snowboarding
20:57:09 <flaper87> I will be traveling next Tuesday (SURPRISE)
20:57:18 <flaper87> so, perhaps we skip?
20:57:18 <ttx> Feels like the IRC vote next meeting will need most people to be around
20:57:19 <mordred> actually, /me will be on train travelling away from ops midcycle
20:57:29 <mordred> yah - this is an important vote I think
20:57:42 <lifeless> +1 on skippiung next week
20:57:42 <jeblair> perhaps we should do the vote in gerrit? :)
20:57:47 <rockyg> ++
20:57:48 <annegentle_> yeah skip I guess. I can run it if needed though.
20:57:51 * russellb will be around
20:58:01 * dhellmann expects to be around
20:58:08 * edleafe will be around, not that that matters much :)
20:58:18 <ttx> jeblair: yeah, we just need some way to formulate it
20:58:18 <anteaya> edleafe: it matters to me
20:58:21 <mestery> I'll be here to FWIW
20:58:26 <edleafe> anteaya: awwwwww
20:58:29 <anteaya> :)
20:58:51 <flaper87> jeblair: ttx if we can do it on gerrit in some way, then I'd me more than happy to use gerrit
20:58:52 <markmcclain> I'll be around too
20:59:02 <ttx> ok, I propose we skip next week, and find a way to vote in Gerrit (resolution or wat)
20:59:08 <jaypipes> ++
20:59:34 <ttx> that way we don't stall the discussion for two weeks
20:59:53 <flaper87> If someone can chair next week and there's quorum, we shouldn't skip it (just like the one I chaired). But the vote should happen in gerrit, though
20:59:55 <annegentle_> I always learn at these meetings, hence witholding my vote
21:00:00 <ttx> I'll find a way to formulate that. Maybe a comment in the yaml file
21:00:28 <flaper87> A place holder in the project's file?
21:00:33 <ttx> #action ttx to propose some vote on the Poppy / opencore or not issue in Gerrit, separate from formal project team addition
21:00:37 <flaper87> like: "They will come, sit and wait"
21:00:46 <flaper87> not sure if I'm making any sense
21:00:48 <ttx> flaper87: yeah, something like that
21:00:52 <jeblair> wfm
21:00:52 <ttx> ok, time is up
21:01:03 <thingee> fungi: I know, no break!
21:01:14 <thingee> whoops
21:01:16 <ttx> Sorry it takes time to process those applications, because those are edge cases and we need to think more about them
21:01:17 <fungi> heh
21:01:41 <ttx> #endmeeting