Open Stack

Hi Kevin,

On 2015-09-15 8:33 PM, Fox, Kevin M wrote:
> I am not a neutron developer, but an operator and a writer of cloud apps.

So far, I'm only an operator and heavy cloud apps user (if you can call
Vagrant an app). =)


> Yes, it is sort of a philosophical issue, and I have stated my side
> of why I think the extra complexity is worth it. Feel free to
> disagree.

I don't disagree with the general idea of NaaS or SDN. We are looking to
offer this stuff in the future so customers wishing to have more control
over their networks can have it.

I would however like for other solutions (which doesn't require
mandatory NATing, floating IPs, and routers) to be accepted and fully
supported as first class citizen.


> But either way I don't think we can ignore the complexity. There are
> three different ways to resolve it:
> 
> * No naas and naas are both supported. Ops get it easy. they pick
> which one they want, users suffer a little if they work on multiple
> clouds that differ. app developers suffer a lot since they have to
> write either two sets of software or pick the lowest common
> denominator.
> 
> Its an optimization problem. who do you shift the difficulty to?
> 
> My personal opinion again is that I'd rather suffer a little more as
> an Op and always deploy naas, rather then have to deal with the app
> developer pain of not being able to rely on it. The users/ops benefit
> the most if a strong app ecosystem can be developed on top.


So far, I'm aiming for "No naas and naas are both supported.":

- No NaaS: A public shared and routable provider network.
- NaaS: All the goodness of SDN and private networks.

While NaaS is a very nice feature for cloud apps writer, we found that
our type of users actually don't ask for it (yet) and are looking for
simplicity instead.

BTW, let me know if I got my understanding of "No naas" (very?) wrong.


As Monty Taylor said [3], we should be able to "nova boot" or "nova boot
--network public" just fine.

So lets assume I don't have NaaS yet. I only have 1 no-NaaS network
named "public" available to all tenants.

With this public shared network from no-NaaS, you should be able to boot
just fine. Your instance ends up on a public shared network with a
public IP address without NATing/Floating IPs and such. (Note that we
implemented anti-spoofing on those networks)


Now you wish to use NaaS. So you create this network named "private" or
whatever you feel naming it.

You should be fine too with "nova boot --network private" by making sure
the network name doesn't conflict with the public shared network.
Otherwise you can provide the network UUID just like before. I agree
that you loose the ability to "nova boot" without "--network". See below.


The challenge I see here is with both "no-NaaS" and "NaaS". Now you
could end up with 2 or more networks to choose from and "nova boot"
alone will get confused.


My humble suggestions are:

- Create a new client-side config to tell which network name to choose
(OS_NETWORK_NAME?) so you don't have to type it each time.
- Create a tenant specific server-side config (stored somewhere in
Nova?) to tell which network name to choose from by default.

This will restore the coolness of "nova boot" without specifying
"--network".

If you application requires a lot of networks (and complexity), I'm sure
all these "nova boot" is non-sense to you anyway and that you will
provide the actual list of networks to boot on.


Regarding the need and wish of users to keep their public IPs, you can
still use floating IPs in both cases. It's a matter of educating the
users that public IPs on the no-NaaS network aren't preserved on
destruction. I'm planning to use routes instead of NATing for the public
shared network.


So far, what I'm missing to create a truly scalable public shared
network is what is described here [2] and here [3] as you just can't
scale your L2 network infinitely. (same for private NaaS networks but
that's an other story)


Note that I'm fully aware that it creates a lot of challenges on the
Nova side related to scheduling, resizing, live migrations, evacuate,
etc. But I'm confident that those challenges aren't impossible to overcome.


Kevin, let me know if I missed a known use case you might be actively
using. I never fully used the NaaS part of Neutron so I can't tell for
sure. Or maybe I'm just stating obvious stuff and completely missing the
point of this thread. :D


[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074618.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-July/070028.html
[3] https://review.openstack.org/#/c/196812/


-- 
Mathieu