[openstack-dev] [all] [tc] "No Open Core" in 2016

Fox, Kevin M Kevin.Fox at pnnl.gov
Fri Feb 19 01:08:44 UTC 2016

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?

From: Jeremy Stanley [fungi at 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-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list