<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 29 August 2016 at 03:48, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On 08/27/2016 11:16 AM, HU, BIN wrote:</span><span class=""><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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,<br>
</blockquote>
<br></span>
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.<br></blockquote><br></div><div class="gmail_quote">This conversation started above, but in a war of analogies became this:<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

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.</blockquote><div><br></div><div>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.<br><br>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.<br><br>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.<br></div><div><br></div><div>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.)<br><br>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).<br><br></div><div>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.<br></div><div><br>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.<br><br>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.<br><br>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.<br>-- <br></div><div>Ian.<br></div></div></div></div>