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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev