Open Stack

On 29 August 2016 at 03:48, Jay Pipes <jaypipes at gmail.com> wrote:

> On 08/27/2016 11:16 AM, HU, BIN wrote:
>
>> So telco use cases is not only the innovation built on top of OpenStack.
>> Instead, telco use cases, e.g. Gluon (NFV networking), vCPE Cloud, Mobile
>> Cloud, Mobile Edge Cloud, brings the needed requirement for innovation in
>> OpenStack itself. If OpenStack don't address those basic requirements,
>>
>
> That's the thing, Bin, those are *not* "basic" requirements. The Telco
> vCPE and Mobile "Edge cloud" (hint: not a cloud) use cases are asking for
> fundamental architectural and design changes to the foundational components
> of OpenStack. Instead of Nova being designed to manage a bunch of hardware
> in a relatively close location (i.e. a datacenter or multiple datacenters),
> vCPE is asking for Nova to transform itself into a micro-agent that can be
> run on an Apple Watch and do things in resource-constrained environments
> that it was never built to do.
>

This conversation started above, but in a war of analogies became this:


> And, honestly, I have no idea what Gluon is trying to do. Ian sent me some
> information a while ago on it. I read it. I still have no idea what Gluon
> is trying to accomplish other than essentially bypassing Neutron entirely.
> That's not "innovation". That's subterfuge.


Gluon, as written, does allow you to bypass Neutron, but as I'm sure you
understand, I did have more useful features on my mind than 'subterfuge'.
Let me lay this out in the clear again, since I've had this conversation
with you and others and I'm not getting my point across.  And in keeping
with the discussion I'll start with an analogy.

When we started out, Nova was the compute component for OpenStack.  I'd
like to remind you of the problems we had with the docker driver, because
docker containers are like, but also unlike, virtual machines.  They're
compute containers, they support networking, but their storage requirements
are weird; they tend to use technologies unlike conventional disk images,
they're not exactly capable of using block devices without help, and so
on.  You can change Nova to support that, or you can say 'these are
sufficiently different that we should have a separate API'.  I see we have
Zun now, so someone's trying that approach.  They're 'bypassing' Nova.

Here, we're talking about different compute components that have
similarities and differences to virtual machines.  If they're similar
enough, then building into Nova is logical - it will require some change to
the APIs (let's forget the internal code for a moment) but not drastic
ones; ones that are backward compatible.  If they're different enough you
sit something new alongside Nova.

Neutron is the networking component for OpenStack the same way that Nova is
compute.  It brings together the sorts of thing you would want to run cloud
applications on a public cloud, and as it happens these concepts also work
reasonably nicely for many other cloud use cases.  But - today - it is not
'all networking everywhere', it's 'networking with a specific focus on L2
domains' - because this solves the majority of its users' problems.  (We
can quibble about whether a 'network' in Neutron must be L2, because it's
not exactly documented as such, but I would like to point out the plugin
that most people use today to implement networks is called 'ML2' and the
only way to attach a port to anything is to attach it to a network with
location-independent subnets.  Suffice it to say that the consumer of the
API can treat it like an L2 network.)

There comes a question, then.  If it is to be the only networking project
in OpenStack, for it to be 'all networking everywhere', then we need to
address the problem that its current API does not suit every form of
networking in existence.  We need to do this without affecting every single
person who uses OpenStack as it is and doesn't want or need every new bit
of functionality.  For that we have extensions within Neutron, but they're
still constrained to operate within Neutron's existing API structure.  The
most complex ones tend to work on the principle of 'networks work as you
expect until the extension steps in, then they become a bit weird and
special'.  This isn't the way to write a system with widely understood and
easy-to-use APIs.  Really you're just tolerating the history of Neutron
because you don't have a choice.  It also makes something which turns a bit
monolithic and complex in practice (e.g. forwarding elements being
programmed by multiple bits of independent code).

Some of the APIs we were experimenting with were things that already
existed as Neutron extensions, such as MPLS/BGP overlays.  Some that we'd
like to try in the future include things like point-to-point connectivity,
or comprehensively routed networks.  But as much as anything the point is
that we know that networking changes over time and people have new ideas of
how to use what exists, so we're trying to make sure that they can do that.

I was trying for a different approach - that we could write small,
indpendent, focussed networking APIs for specific purposes that had no
relation to what Neutron was doing.  The answer I was trying for was to
make it possible to write new stuff, with new APIs with no history - that
stuff might be good or bad, and would live or die by its own merits, but at
least it could be tried - while affecting the existing codebase in the most
minimal way possible.  And while also being able to use Neutron on some of
my VM ports, because I wanted to complement it, not replace, it.  It's very
good at what it does.

Again, we can do this in other ways.  We can change Neutron to be more
general purpose - but that is likely to break some of its fundamental
assumptions, and will no doubt make its code more complex, which isn't in
the best interests of its current users and biggest audience.  We're
looking at this as well, to see what might be possible.

I'm actually not set on which we do, but as an experiment we tried a
different approach.  I think it's reasonable to experiment in order to
discover what might work, and I don't believe that every experiment has to
be a success.  In this instance, though, your argument above is 'it sounds
wrong' and not 'it is wrong', but as you say based on incomplete
information.  I'd be interested to hear more of your thoughts.
-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160829/3a6caae5/attachment.html>