Open Stack

> But v[E]CPE just isn't cloud to me. And trying to morph Nova or other 
> OpenStack services that were designed to run as services in a datacenter 
> just isn't something I feel the OpenStack community needs to be focusing 
> on. Run Nova (or Kubernetes, or Mesos, or any other cloud management 
> platform) in the datacenter. Run a custom software application on the 
> set-top boxes that can communicate with datacenter cloud services. Let's 
> please not commandeer one of them to fit a model it was never built for.

Funny point of view. Let's look at the mission of OpenStack:

"to produce the ubiquitous Open Source Cloud Computing platform that enables
building interoperable public and private clouds regardless of size, by being
simple to implement and massively scalable while serving the cloud users'
needs."

It mentioned that "regardless of size", and you also mentioned "cloud to me:
lots of hardware consolidation".

May we call an edge site which include 10 hardware as a cloud? If 10 is ok, how
about 5 or 3?

>From OpenStack mission, it should be able to run "regardless of size", but from 
your definition, what's the hardware number is the thresshold for OpenStack, especially
Nova to run, and so that it could be called a cloud?

I proposed to introduce plugin mechnism in Nova/Cinder API layer, just like Neutron
what has been done, so that Nova/Cinder can also run in samll size scenario.

The plugin mechanism can also be used for Tricircle project. During the Tricircle
big-tent project application[1], TCs's worried that Nova API-Gateway/Cinder API-Gateway
will reimplement some Nova/Cinder API. If Nova/Cinder can provide the plugin mechnism
in its API layer like what Neutron did, then innovation can be introduce to reach the OpenStack
 mission "regardless of size". 

Just as Jay implied(that's my imaging, forgive me if it's wrong :) ), one implementation
to fit all size is impossible.

[1] Tricircle big-tent project application https://review.openstack.org/#/c/338796/

Best Regards
Chaoyi Huang (joehuang)

________________________________________
From: Jay Pipes [jaypipes at gmail.com]
Sent: 25 August 2016 8:37
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [all][massively distributed][architecture] Coordination between actions/WGs

On 08/24/2016 04:26 AM, Peter Willis wrote:
> Colleagues,
>
> I'd like to confirm that scalability and multi-site operations are key
> to BT's NFV use cases e.g. vCPE, vCDN, vEPC, vIMS, MEC, IoT, where we
> will have compute highly distributed around the network (from thousands
> to millions of sites). BT would therefore support a Massively
> Distributed WG and/or work on scalability and multi-site operations in
> the Architecture WG.

Love all the TLAs.

I've asked this before to numerous Telco product managers and engineers,
but I've yet to get a solid answer from any of them, so I'll repeat the
question here...

How is vCPE a *cloud* use case?

 From what I understand, the v[E]CPE use case is essentially that Telcos
want to have the set-top boxen/routers that are running cable television
apps (i.e. AT&T U-verse or Verizon FiOS-like things for US-based
customers) and home networking systems (broadband connectivity to a
local central office or point of presence, etc) be able run on virtual
machines to make deployment and management of new applications easier.
Since all those home routers and set-top boxen are essentially just
Linux boxes, the infrastructure seems to be there to make this a
cost-savings reality for Telcos. [1]

The problem is that that isn't remotely a cloud use case. Or at least,
it doesn't describe what I think of as cloud.

Cloud to me means:

* Lots of hardware consolidated in datacenters for efficiency and
security/management
* Software-as-a-Service interface, meaning the service is driven by
users/tenants (i.e. no IT helpdesk to call to provision something) and
provided over the Internet to a dumb device or browser
* (HTTP) API-driven access to launch compute, storage and network
resources from large pools of those resources

Furthermore, applications written for the cloud (i.e. cloud-native apps)
are built from the ground up to assume and tolerate failure, to be as
close to shared-nothing as possible, to not need to be aware of where
they are running or what particular server they are running on and to
rely on well-defined APIs between (micro-)services.

v[E]CPE describes a purpose-built Telco application that doesn't meet
any of the above definitions of what "cloud" is all about.

vCPE also doesn't look like a cloud-native application either: A single
customer's vCPE software application is not capable of running on more
than one machine at a time (since obviously it's running on the
customer's set-top box or router).

Look, I'm all about designing Nova and other cloud services to function
well in distributed environments where multiple datacenters are running
a single OpenStack deployment spread over many regions.

But v[E]CPE just isn't cloud to me. And trying to morph Nova or other
OpenStack services that were designed to run as services in a datacenter
just isn't something I feel the OpenStack community needs to be focusing
on. Run Nova (or Kubernetes, or Mesos, or any other cloud management
platform) in the datacenter. Run a custom software application on the
set-top boxes that can communicate with datacenter cloud services. Let's
please not commandeer one of them to fit a model it was never built for.

My two cents,
-jay

[1] I say cost-savings because instead of shipping the customer a new
piece of hardware when they purchase a new service (or sending a
lineman), instead the telco now simply sends a command to the customer's
router or set-top box to launch a VM that provides that service. One
could say that the Telcos could just as easily ship a monolithic
software application that would run on the set-top box and allow
features to be toggled on and off, and I'm pretty sure many telco
software applications are already like this, but deploying and managing
monolithic applications is more complicated and expensive than shipping
a VM image that contains a custom-built service that the customer can
use at will.

p.s. I also don't think it's a good idea to run nova-compute on a fitbit
watch.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev