It might be good to consider the scale that's needed too. For us, some of our clouds are on an internal network and its highly non desirable for an external cdn to be used. But to have the api work internally and scale out to at least the organization, so the same app templates can be used internally and externally. that would be very cool. So backing it by swift or something would be an interesting way to do it. It might not be very hard to implement that way, and would be useful to those that have private only clouds (probably a lot of folks). It wouldn't be a true CDN in the regular sense since it wouldn't be geographic. But, good enough. Would that be possible?
Thanks, Kevin ________________________________________ From: Jeremy Stanley [fu...@yuggoth.org] Sent: Thursday, February 18, 2016 4:52 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] "No Open Core" in 2016 On 2016-02-18 17:20:35 -0600 (-0600), Ian Cordasco wrote: [...] > Presently, I think we need a F/OSS CDN but it isn't going to > happen until the infrastructure for a CDN is something any > OpenStack consumer would want to manage. [...] Probably an unusual use case and stretching the definition of CDN: the Infra team has rolled their own by putting Apache on virtual machines serving content from AFS for the purpose of hosting a variety of content mirrors in each of the myriad OpenStack providers/regions where it runs CI jobs. It may be that the infrastructure for a CDN is in fact something that a lot of multi-region/cross-provider applications would like to manage but that their needs are sufficiently different so as to make a targeted solution for one useless for another. Ignorance on my part I'm sure, but I'd like to see a definition of "content delivery network" that people can agree on before figuring out what Poppy even is. I've browsed its documentation and it doesn't seem to actually define this, so I get the impression that its entire existence is defined and informed solely by other proprietary application designs. -- Jeremy Stanley __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
