Open Stack

On 15 September 2015 at 16:08, Monty Taylor <mordred at inaugust.com> wrote:

> On 09/15/2015 06:30 PM, Armando M. wrote:
>
>>
>>
>> On 15 September 2015 at 08:04, Monty Taylor <mordred at inaugust.com
>> <mailto:mordred at inaugust.com>> wrote:
>>
>>     Hey all!
>>
>>     If any of you have ever gotten drunk with me, you'll know I hate
>>     floating IPs more than I hate being stabbed in the face with a very
>>     angry fish.
>>
>>     However, that doesn't really matter. What should matter is "what is
>>     the most sane thing we can do for our users"
>>
>>     As you might have seen in the glance thread, I have a bunch of
>>     OpenStack public cloud accounts. Since I wrote that email this
>>     morning, I've added more - so we're up to 13.
>>
>>     auro
>>     citycloud
>>     datacentred
>>     dreamhost
>>     elastx
>>     entercloudsuite
>>     hp
>>     ovh
>>     rackspace
>>     runabove
>>     ultimum
>>     unitedstack
>>     vexxhost
>>
>>     Of those public clouds, 5 of them require you to use a floating IP
>>     to get an outbound address, the others directly attach you to the
>>     public network. Most of those 8 allow you to create a private
>>     network, to boot vms on the private network, and ALSO to create a
>>     router with a gateway and put floating IPs on your private ip'd
>>     machines if you choose.
>>
>>     Which brings me to the suggestion I'd like to make.
>>
>>     Instead of having our default in devstack and our default when we
>>     talk about things be "you boot a VM and you put a floating IP on it"
>>     - which solves one of the two usage models - how about:
>>
>>     - Cloud has a shared: True, external:routable: True neutron network.
>>     I don't care what it's called  ext-net, public, whatever. the
>>     "shared" part is the key, that's the part that lets someone boot a
>>     vm on it directly.
>>
>>     - Each person can then make a private network, router, gateway, etc.
>>     and get floating-ips from the same public network if they prefer
>>     that model.
>>
>>     Are there any good reasons to not push to get all of the public
>>     networks marked as "shared"?
>>
>>
>> The reason is simple: not every cloud deployment is the same: private is
>> different from public and even within the same cloud model, the network
>> topology may vary greatly.
>>
>
> Yes. Many things may be different.
>
> Perhaps Neutron fails in the sense that it provides you with too much
>> choice, and perhaps we have to standardize on the type of networking
>> profile expected by a user of OpenStack public clouds before making
>> changes that would fragment this landscape even further.
>>
>> If you are advocating for more flexibility without limiting the existing
>> one, we're only making the problem worse.
>>
>
> I am not. I am arguing for a different arbitrary 'default' deployment.
> Right now the verbiage around things is "floating IPs is the 'right' way to
> get access to public networks"
>
> I'm not arguing for code changes, or more options, or new features.
>
> I'm saying that there a set of public clouds that provide a default
> experience out of the box that is pleasing with neutron today, and we
> should have the "I don't know what I want tell me what to do" option behave
> like those clouds.
>
> Yes. You can do other things.
> Yes. You can get fancy.
> Yes. You can express all of the things.
>
> Those are things I LOVE about neutron and one of the reasons I think that
> the arguments around neutron and nova-net are insane.
>
> I'm just saying that "I want a computer on the externally facing network
> from this cloud" is almost never well served by floating-ips unless you
> know what you're doing, so rather than leading people down the road towards
> that as the default behavior, since it's the HARDER thing to deal with -
> let's lead them to the behavior which makes the simple thing simple and
> then clearly open the door to them to increasingly complex and powerful
> things over time.


I can get behind this statement, but all I am trying to say is that Neutron
gives you the toolkit. How, as a deployer you use it, it's up to you. A
deployer can today implement a shared publicly facing network on which VM's
can connect to without problems. Now the issue may come from a user point
of view: does the user may need to specify the network? Or create the
topology ahead of time? It's my understanding that this is what this thread
is about. If not, then I clearly need a crash course in English :)


>
>
>>     OH - well, one thing - that's that once there are two networks in an
>>     account you have to specify which one. This is really painful in
>>     nova clent. Say, for instance, you have a public network called
>>     "public" and a private network called "private" ...
>>
>>     You can't just say "nova boot --network=public" - nope, you need to
>>     say "nova boot --nics net-id=$uuid_of_my_public_network"
>>
>>     So I'd suggest 2 more things;
>>
>>     a) an update to python-novaclient to allow a named network to be
>>     passed to satisfy the "you have more than one network" - the nics
>>     argument is still useful for more complex things
>>
>
That's the one:

https://bugs.launchpad.net/python-novaclient/+bug/1496180


>
>>     b) ability to say "vms in my cloud should default to being booted on
>>     the public network" or "vms in my cloud should default to being
>>     booted on a network owned by the user"
>>
>
I think this this is very do-able with the caveat that we gotta figure out
how this turns out to be like in the various deployment models that are
feasible with the toolkit that Neutron provides the deployer with. There
may be multiple public networks, multiple per-tenant networks etc.

As Doug initially pointed out the get-me-a-network [1] aims at simplifying
this workflow. We may need to refine it further based on your input, but
this is something that can be iterated on once we have the building block
in place, and furthermore once we have people actually working on it...bear
with us ;)

That's the other:

[1] https://blueprints.launchpad.net/neutron/+spec/get-me-a-network


>
>>     Thoughts?
>>
>>
>> As I implied earlier, I am not sure how healthy this choice is. As a
>> user of multiple clouds I may end up having a different user experience
>> based on which cloud I am using...I thought you were partially
>> complaining about lack of consistency?
>>
>
> I am a user of multiple clouds. I am complaining about the current lack of
> consistency.
>
> More than that though, I'm complaining that we lead people to select a
> floating-ip model when having them flip the boolean value of "shared=True"
> on their ext-net would make the end-user experience WAY nicer.


It's funny you mention that because today Neutron already has a concept of
shared networks. I can make a public network (router:external) shared. If
no logical tenant-owned network were to be available, then you'd boot
straight off the external network, so your use is 90% already there.


>
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150915/321c90db/attachment.html>