Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Carl Baldwin]

On Tue, Sep 15, 2015 at 3:09 PM, Fox, Kevin M  wrote:
> DNS is preferable, since humans don't remember ip's very well. IPv6 is much 
> harder to remember then v4 too.
>
> DNS has its own issues, mostly, its usually not very quick to get a DNS entry 
> updated.  At our site (and I'm sure, others), I'm afraid to say in some cases 
> it takes as long as 24 hours to get updates to happen. Even if that was 
> fixed, caching can bite you too.

We also have work going on now to automate the addition and update of
DNS entries as VMs come and go [1].  Please have a look and provide
feedback.

[1] https://review.openstack.org/#/q/topic:bp/external-dns-resolution,n,z

Carl

__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Fox, Kevin M]

I am not a neutron developer, but an operator and a writer of cloud apps.

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.

But either way I don't think we can ignore the complexity. There are three 
different ways to resolve it:

* Simple use case, no naas at all. The "simplest" solution, some app developers 
and some users suffer that actually need naas. users/app developers have to add 
it on top themselves.
* always naas. Ops (and perhaps users) have to deal with the extra complexity 
if they feel they don't need it. but its simpler in that you can always rely on 
it being there.
* 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.

Again, my personal opinion. Feel free to differ.

Thanks,
Kevin



From: Mathieu Gagné [mga...@internap.com]
Sent: Tuesday, September 15, 2015 3:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' 
network model

On 2015-09-15 2:00 PM, Fox, Kevin M wrote:
> We run several clouds where there are multiple external networks. the "just 
> run it in on THE public network" doesn't work. :/
>
> I also strongly recommend to users to put vms on a private network and use 
> floating ip's/load balancers. For many reasons. Such as, if you don't, the ip 
> that gets assigned to the vm helps it become a pet. you can't replace the vm 
> and get the same IP. Floating IP's and load balancers can help prevent pets. 
> It also prevents security issues with DNS and IP's. Also, for every floating 
> ip/lb I have, I usually have 3x or more the number of instances that are on 
> the private network. Sure its easy to put everything on the public network, 
> but it provides much better security if you only put what you must on the 
> public network. Consider the internet. would you want to expose every device 
> in your house directly on the internet? No. you put them in a private network 
> and poke holes just for the stuff that does. we should be encouraging good 
> security practices. If we encourage bad ones, then it will bite us later when 
> OpenStack gets a reputation for being associated with compromises.
>

Sorry but I feel this kind of reply explains why people are still using
nova-network over Neutron. People want simplicity and they are denied it
at every corner because (I feel) Neutron thinks it knows better.

The original statement by Monty Taylor is clear to me:

I wish to boot an instance that is on a public network and reachable
without madness.

As of today, you can't unless you implement a deployer/provider specific
solution (to scale said network). Just take a look at what actual public
cloud providers are doing:

- Rackspace has a "magic" public network
- GoDaddy has custom code in their nova-scheduler (AFAIK)
- iWeb (which I work for) has custom code in front of nova-api.

We are all writing our own custom code to implement what (we feel)
Neutron should be providing right off the bat.

By reading the openstack-dev [1], openstack-operators [2] lists, Neutron
specs [3] and the Large Deployment Team meeting notes [4], you will see
that what is suggested here (a scalable public shared network) is an
objective we wish but are struggling hard to achieve.

People keep asking for simplicity and Neutron looks to not be able to
offer it due to philosophical conflicts between Neutron developers and
actual public users/operators. We can't force our users to adhere to ONE
networking philosophy: use NAT, floating IPs, firewall, routers, etc.
They just don't buy it. Period. (see monty's list of public providers
attaching VMs to public network)

If we can accept and agree that not everyone wishes to adhere to the
"full stack of networking good practices" (TBH, I don't know how to call
this thing), it will be a good start. Otherwise I feel we won't be able
to achieve anything.

What Monty is explaining and suggesting is something we (my team) have
been struggling with for *years* and just didn't have bandwidth (we are
operators, not developers) or public charisma to change.

I'm glad Monty brought up this subject so we can officially address it.


[1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/070028.html
[2

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Mathieu Gagné]

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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Doug Wiegley]

> On Sep 15, 2015, at 4:11 PM, Mathieu Gagné  wrote:
> 
>> On 2015-09-15 2:00 PM, Fox, Kevin M wrote:
>> We run several clouds where there are multiple external networks. the "just 
>> run it in on THE public network" doesn't work. :/
>> 
>> I also strongly recommend to users to put vms on a private network and use 
>> floating ip's/load balancers. For many reasons. Such as, if you don't, the 
>> ip that gets assigned to the vm helps it become a pet. you can't replace the 
>> vm and get the same IP. Floating IP's and load balancers can help prevent 
>> pets. It also prevents security issues with DNS and IP's. Also, for every 
>> floating ip/lb I have, I usually have 3x or more the number of instances 
>> that are on the private network. Sure its easy to put everything on the 
>> public network, but it provides much better security if you only put what 
>> you must on the public network. Consider the internet. would you want to 
>> expose every device in your house directly on the internet? No. you put them 
>> in a private network and poke holes just for the stuff that does. we should 
>> be encouraging good security practices. If we encourage bad ones, then it 
>> will bite us later when OpenStack gets a reputation for being associated 
>> with compromises.
> 
> Sorry but I feel this kind of reply explains why people are still using
> nova-network over Neutron. People want simplicity and they are denied it
> at every corner because (I feel) Neutron thinks it knows better.

Please stop painting such generalizations.  Go to the third or fourth email in 
this thread and you will find a spec, worked on by neutron and nova, that 
addresses exactly this use case.

It is a valid use case, and neutron does care about it. It has wrinkles. That 
has not stopped work on it for the common cases.

Thanks,
Doug 


> 
> The original statement by Monty Taylor is clear to me:
> 
> I wish to boot an instance that is on a public network and reachable
> without madness.
> 
> As of today, you can't unless you implement a deployer/provider specific
> solution (to scale said network). Just take a look at what actual public
> cloud providers are doing:
> 
> - Rackspace has a "magic" public network
> - GoDaddy has custom code in their nova-scheduler (AFAIK)
> - iWeb (which I work for) has custom code in front of nova-api.
> 
> We are all writing our own custom code to implement what (we feel)
> Neutron should be providing right off the bat.
> 
> By reading the openstack-dev [1], openstack-operators [2] lists, Neutron
> specs [3] and the Large Deployment Team meeting notes [4], you will see
> that what is suggested here (a scalable public shared network) is an
> objective we wish but are struggling hard to achieve.
> 
> People keep asking for simplicity and Neutron looks to not be able to
> offer it due to philosophical conflicts between Neutron developers and
> actual public users/operators. We can't force our users to adhere to ONE
> networking philosophy: use NAT, floating IPs, firewall, routers, etc.
> They just don't buy it. Period. (see monty's list of public providers
> attaching VMs to public network)
> 
> If we can accept and agree that not everyone wishes to adhere to the
> "full stack of networking good practices" (TBH, I don't know how to call
> this thing), it will be a good start. Otherwise I feel we won't be able
> to achieve anything.
> 
> What Monty is explaining and suggesting is something we (my team) have
> been struggling with for *years* and just didn't have bandwidth (we are
> operators, not developers) or public charisma to change.
> 
> I'm glad Monty brought up this subject so we can officially address it.
> 
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/070028.html
> [2]
> http://lists.openstack.org/pipermail/openstack-operators/2015-August/007857.html
> [3]
> http://specs.openstack.org/openstack/neutron-specs/specs/liberty/get-me-a-network.html
> [4]
> http://lists.openstack.org/pipermail/openstack-operators/2015-June/007427.html
> 
> -- 
> 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

__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Jeremy Stanley]

On 2015-09-15 18:00:03 + (+), Fox, Kevin M wrote:
> We run several clouds where there are multiple external networks.
> the "just run it in on THE public network" doesn't work. :/

Is this for a public servive provider? If so, do you expect your
users to have some premonition which tells them the particular
public network they should be choosing?

> I also strongly recommend to users to put vms on a private network
> and use floating ip's/load balancers. For many reasons. Such as,
> if you don't, the ip that gets assigned to the vm helps it become
> a pet.

I like pets just fine. Often I want pet servers not cattle servers.
Why should you (the service provider) make this choice for me?

> you can't replace the vm and get the same IP.

No? Well, you can `nova rebuild` in at least some environments, but
regardless it's not that hard to change a couple of DNS records when
replacing a server (virtual or physical).

> Floating IP's and load balancers can help prevent pets.

They can help prevent lots of things, some good, some bad. I'd
rather address translation were the exception, not the rule. NAT has
created a broken Internet.

> It also prevents security issues with DNS and IP's.

This is the first I've heard about DNS and IP addresses being
insecure. Please elaborate, and also explain your alternative
Internet which relies on neither of these.

> Also, for every floating ip/lb I have, I usually have 3x or more
> the number of instances that are on the private network.

Out of some misguided assumption that NAT is a security panacea from
the sound of it.

> Sure its easy to put everything on the public network, but it
> provides much better security if you only put what you must on the
> public network.

I highly recommend a revolutionary new technology called "packet
filtering."

> Consider the internet. would you want to expose every device in
> your house directly on the internet? No.

On the contrary, I actually would (depending on what you mean by
"expose", but I assume from context you mean assign individual
global addresses directly to the network interfaces of each). With
IPv6 I do and would with v4 as well if my local provider routed me
more than a /32 assignment.

> you put them in a private network and poke holes just for the
> stuff that does.

No, I put them in a globally-routed network (the terms "private" and
"public" are misleading in the context of these sorts of
discussions) and poke holes just for the stuff that people need to
reach from outside that network.

> we should be encouraging good security practices. If we encourage
> bad ones, then it will bite us later when OpenStack gets a
> reputation for being associated with compromises.

Here we agree, we just disagree on what those security practices
are. Address translation is no substitute for good packet filtering,
and allowing people to ignorantly assume so does them a great
disservice. We should be educating them on how to properly protect
their systems while at the same time showing them how much better
the Internet works without the distasteful workarounds brought about
by unnecessary layers of address-translating indirection.

And before this turns into a defense-in-depth debate, adding NAT to
your filtering doesn't really increase security it just increases
complexity.

> I do consider making things as simple as possible very important.
> but that is, make them as simple as possible, but no simpler.
> There's danger here of making things too simple.

Complexity is the enemy of security, so I find your reasoning
internally inconsistent. Proponents of NAT are suffering from some
manner of mass-induced Stockholm Syndrome. It's a hack to deal with
our oversubscription of the IPv4 address space and in some cases
solve address conflicts between multiple networks. Its unfortunate
ubiquity has confused lots of people into thinking it's there for
better reasons than it actually is.
-- 
Jeremy Stanley

__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Monty Taylor]

On 09/15/2015 06:30 PM, Armando M. wrote:



On 15 September 2015 at 08:04, Monty Taylor > 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.


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

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"

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 

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Fox, Kevin M]

Yup. And Designate works very well. :)

But DNSaaS is not always an option to "the powers that be" floating ip's 
are a much easier sell.

Also Designate does have a restriction of wanting to manage a whole domain 
itself. When you have existing infrastructure you want your vms to merge into, 
its a problem.

Thanks,
Kevin

From: Assaf Muller [amul...@redhat.com]
Sent: Tuesday, September 15, 2015 2:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' 
network model



On Tue, Sep 15, 2015 at 5:09 PM, Fox, Kevin M 
<kevin@pnnl.gov<mailto:kevin@pnnl.gov>> wrote:
Unfortunately, I haven't had enough chance to play with ipv6 yet.

I still think ipv6 with floating ip's probably makes sense though.

In ipv4, the floating ip's solve one particular problem:

End Users want to be able to consume a service provided by a VM. They have two 
options:
1. contact the ip directly
2. use DNS.

DNS is preferable, since humans don't remember ip's very well. IPv6 is much 
harder to remember then v4 too.

DNS has its own issues, mostly, its usually not very quick to get a DNS entry 
updated.  At our site (and I'm sure, others), I'm afraid to say in some cases 
it takes as long as 24 hours to get updates to happen. Even if that was fixed, 
caching can bite you too.

I'm curious if you tried out Designate / DNSaaS.


So, when you register a DNS record, the ip that its pointing at, kind of 
becomes a set of state. If it can't be separated from a VM its a bad thing. You 
can move it from VM to VM and your VM is not a pet. But, if your IP is 
allocated to the VM specifically, as non Floating IP's are, you run into 
problems if your VM dies and you have to replace it. If your unlucky, it dies, 
and someone else gets allocated the fixed ip, and now someone else's server is 
sitting on your DNS entry! So you are very unlikely to want to give up your VM, 
turning it into a pet.

I'd expect v6 usage to have the same issues.

The floating ip is great in that its an abstraction of a contactable address, 
separate from any VM it may currently be bound to.

You allocate a floating ip. You can then register it with DNS, and another 
tenant can not get accidentally assigned it. You can move it from vm to vm 
until your done with it. You can Unregister it from DNS, and then it is safe to 
return to others to use.

To me, the NAT aspect of it is a secondary thing. Its primary importance is in 
enabling things to be more cattleish and helping with dns security.

Thanks,
Kevin







From: Clark Boylan [cboy...@sapwetik.org<mailto:cboy...@sapwetik.org>]
Sent: Tuesday, September 15, 2015 1:06 PM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' 
network model

On Tue, Sep 15, 2015, at 11:00 AM, Fox, Kevin M wrote:
> We run several clouds where there are multiple external networks. the
> "just run it in on THE public network" doesn't work. :/
Maybe this would be better expressed as "just run it on an existing
public network" then?
>
> I also strongly recommend to users to put vms on a private network and
> use floating ip's/load balancers. For many reasons. Such as, if you
> don't, the ip that gets assigned to the vm helps it become a pet. you
> can't replace the vm and get the same IP. Floating IP's and load
> balancers can help prevent pets. It also prevents security issues with
> DNS and IP's. Also, for every floating ip/lb I have, I usually have 3x or
> more the number of instances that are on the private network. Sure its
> easy to put everything on the public network, but it provides much better
> security if you only put what you must on the public network. Consider
> the internet. would you want to expose every device in your house
> directly on the internet? No. you put them in a private network and poke
> holes just for the stuff that does. we should be encouraging good
> security practices. If we encourage bad ones, then it will bite us later
> when OpenStack gets a reputation for being associated with compromises.
There are a few issues with this. Neutron IPv6 does not support floating
IPs. So now you have to use two completely different concepts for
networking on a single dual stacked VM. IPv4 goes on a private network
and you attach a floating IP. IPv6 is publicly routable. If security and
DNS and not making pets were really the driving force behind floating
IPs we would see IPv6 support them too. These aren't the reasons
floating IPs exist, they exist because we are running out of IPv4
addresses and NAT is everyones preferred solution to that problem. But
that doesn't make it a good default for a cloud; use them if you are
affected by an IP sh

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Armando M.]

On 15 September 2015 at 16:01, Monty Taylor  wrote:

> On 09/15/2015 06:16 PM, Armando M. wrote:
>
>>
>>
>> On 15 September 2015 at 08:27, Mike Spreitzer > > wrote:
>>
>> Monty Taylor >
>> wrote on 09/15/2015 11:04:07 AM:
>>
>> > 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
>>
>> I am not using the latest, but rather Juno.  I find that in many
>> places the Neutron CLI insists on a UUID when a name could be used.
>> Three cheers for any campaign to fix that.
>>
>>
>> The client is not particularly tied to a specific version of the server,
>> so we don't have a Juno version, or a Kilo version, etc. (even though
>> they are aligned, see [1] for more details).
>>
>> Having said that, you could use names in place of uuids pretty much
>> anywhere. If your experience says otherwise, please consider filing a
>> bug against the client [2] and we'll get it fixed.
>>
>
> May just be a help-text bug in novaclient then:
>
>   --nic
> 

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Monty Taylor]

On 09/15/2015 06:16 PM, Armando M. wrote:



On 15 September 2015 at 08:27, Mike Spreitzer > wrote:

Monty Taylor >
wrote on 09/15/2015 11:04:07 AM:

> 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

I am not using the latest, but rather Juno.  I find that in many
places the Neutron CLI insists on a UUID when a name could be used.
Three cheers for any campaign to fix that.


The client is not particularly tied to a specific version of the server,
so we don't have a Juno version, or a Kilo version, etc. (even though
they are aligned, see [1] for more details).

Having said that, you could use names in place of uuids pretty much
anywhere. If your experience says otherwise, please consider filing a
bug against the client [2] and we'll get it fixed.


May just be a help-text bug in novaclient then:

  --nic 

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Monty Taylor]

On 09/15/2015 08:28 PM, Matt Riedemann wrote:



On 9/15/2015 10:27 AM, Mike Spreitzer wrote:

Monty Taylor  wrote on 09/15/2015 11:04:07 AM:

 > 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

I am not using the latest, but rather Juno.  I find that in many places
the Neutron CLI insists on a UUID when a name could be used.  Three
cheers for any campaign to fix that.


It's my understanding that network names in neutron, like security
groups, are not unique, that's why you have to specify a UUID.


Yah.

EXCEPT - we already error when the user does not specify the network 
specifically enough, so there is nothing stopping us from trying the 
obvious thing and the moving on. Such as:


nova boot

ERROR: There are more than one network, please specify one

nova boot --network public

\o/

OR

nova boot

ERROR: There are more than one network, please specify one

nova boot --network public

ERROR: There are more than one network named 'public', please specify one

nova boot --network ecc967b6-5c01-11e5-b218-4c348816caa1

\o/

These are successive attempts at a simple operation that should be 
simple, and as the situation becomes increasingly complex, so does the 
necessity of the user's response.


__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Fox, Kevin M]

Let me rephrase that to be more explicit. Certain organizations, for various 
reasons, require people in the process chain to actually make dns changes... No 
amount of automation can easily address that issue. Hopefully that can change 
in time. But stuff as simple as letting users launch vm's can be a hard enough 
enough sell, without requiring automated access to change dns.

That being said, thats a cool patch. I wish I could use it. :) Hopefully some 
day.

Thanks,
Kevin

From: Carl Baldwin [c...@ecbaldwin.net]
Sent: Tuesday, September 15, 2015 3:52 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' 
network model

On Tue, Sep 15, 2015 at 3:09 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:
> DNS is preferable, since humans don't remember ip's very well. IPv6 is much 
> harder to remember then v4 too.
>
> DNS has its own issues, mostly, its usually not very quick to get a DNS entry 
> updated.  At our site (and I'm sure, others), I'm afraid to say in some cases 
> it takes as long as 24 hours to get updates to happen. Even if that was 
> fixed, caching can bite you too.

We also have work going on now to automate the addition and update of
DNS entries as VMs come and go [1].  Please have a look and provide
feedback.

[1] https://review.openstack.org/#/q/topic:bp/external-dns-resolution,n,z

Carl

__
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

__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Armando M.]

On 15 September 2015 at 16:08, Monty Taylor  wrote:

> On 09/15/2015 06:30 PM, Armando M. wrote:
>
>>
>>
>> On 15 September 2015 at 08:04, Monty Taylor > > 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 

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Fox, Kevin M]

+1

From: Monty Taylor [mord...@inaugust.com]
Sent: Tuesday, September 15, 2015 4:33 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' 
network model

On 09/15/2015 08:28 PM, Matt Riedemann wrote:
>
>
> On 9/15/2015 10:27 AM, Mike Spreitzer wrote:
>> Monty Taylor <mord...@inaugust.com> wrote on 09/15/2015 11:04:07 AM:
>>
>>  > 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
>>
>> I am not using the latest, but rather Juno.  I find that in many places
>> the Neutron CLI insists on a UUID when a name could be used.  Three
>> cheers for any campaign to fix that.
>
> It's my understanding that network names in neutron, like security
> groups, are not unique, that's why you have to specify a UUID.

Yah.

EXCEPT - we already error when the user does not specify the network
specifically enough, so there is nothing stopping us from trying the
obvious thing and the moving on. Such as:

nova boot

ERROR: There are more than one network, please specify one

nova boot --network public

\o/

OR

nova boot

ERROR: There are more than one network, please specify one

nova boot --network public

ERROR: There are more than one network named 'public', please specify one

nova boot --network ecc967b6-5c01-11e5-b218-4c348816caa1

\o/

These are successive attempts at a simple operation that should be
simple, and as the situation becomes increasingly complex, so does the
necessity of the user's response.

__
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

__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Armando M.]

On 15 September 2015 at 14:04, Mike Spreitzer  wrote:

> "Armando M."  wrote on 09/15/2015 03:50:24 PM:
>
> > On 15 September 2015 at 10:02, Doug Hellmann 
> wrote:
> > Excerpts from Armando M.'s message of 2015-09-15 09:30:35 -0700:
> ...
> > As with the Glance image upload API discussion, this is an example
> > of an extremely common use case that is either complex for the end
> > user or for which they have to know something about the deployment
> > in order to do it at all. The usability of an OpenStack cloud running
> > neutron would be enhanced greatly if there was a simple, clear, way
> > for the user to get a new VM with a public IP on any cloud without
> > multiple steps on their part.
>
> <>
>
> ...
> >
> > So this boils down to: in light of the possible ways of providing VM
> > connectivity, how can we make a choice on the user's behalf? Can we
> > assume that he/she always want a publicly facing VM connected to
> > Internet? The answer is 'no'.
>
> While it may be true that in some deployments there is no good way for the
> code to choose, I think that is not the end of the story here.  The
> motivation to do this is that in *some* deployments there *is* a good way
> for the code to figure out what to do.


Agreed, I wasn't dismissing this entirely. I was simply saying that if we
don't put constraints in place it's difficult to come up with a good
'default' answer.


>
>
> Regards,
> Mike
>
> __
> 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
>
>
__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Armando M.]

On 15 September 2015 at 15:11, Mathieu Gagné  wrote:

> On 2015-09-15 2:00 PM, Fox, Kevin M wrote:
> > We run several clouds where there are multiple external networks. the
> "just run it in on THE public network" doesn't work. :/
> >
> > I also strongly recommend to users to put vms on a private network and
> use floating ip's/load balancers. For many reasons. Such as, if you don't,
> the ip that gets assigned to the vm helps it become a pet. you can't
> replace the vm and get the same IP. Floating IP's and load balancers can
> help prevent pets. It also prevents security issues with DNS and IP's.
> Also, for every floating ip/lb I have, I usually have 3x or more the number
> of instances that are on the private network. Sure its easy to put
> everything on the public network, but it provides much better security if
> you only put what you must on the public network. Consider the internet.
> would you want to expose every device in your house directly on the
> internet? No. you put them in a private network and poke holes just for the
> stuff that does. we should be encouraging good security practices. If we
> encourage bad ones, then it will bite us later when OpenStack gets a
> reputation for being associated with compromises.
> >
>
> Sorry but I feel this kind of reply explains why people are still using
> nova-network over Neutron. People want simplicity and they are denied it
> at every corner because (I feel) Neutron thinks it knows better.
>

I am sorry, but how can you associate a person's opinion to a project,
which is a collectivity? Surely everyone is entitled to his/her opinion,
but I don't honestly believe these are fair statements to make.


> The original statement by Monty Taylor is clear to me:
>
> I wish to boot an instance that is on a public network and reachable
> without madness.
>
> As of today, you can't unless you implement a deployer/provider specific
> solution (to scale said network). Just take a look at what actual public
> cloud providers are doing:
>
> - Rackspace has a "magic" public network
> - GoDaddy has custom code in their nova-scheduler (AFAIK)
> - iWeb (which I work for) has custom code in front of nova-api.
>
> We are all writing our own custom code to implement what (we feel)
> Neutron should be providing right off the bat.
>

What is that you think Neutron should be providing right off the bat? I
personally have never seen you publicly report usability issues that
developers could go and look into. Let's escalate these so that the Neutron
team can be aware.


>
> By reading the openstack-dev [1], openstack-operators [2] lists, Neutron
> specs [3] and the Large Deployment Team meeting notes [4], you will see
> that what is suggested here (a scalable public shared network) is an
> objective we wish but are struggling hard to achieve.
>

There are many ways to skin this cat IMO, and scalable public shared
network can really have multiple meanings, I appreciate the pointers
nonetheless.


>
> People keep asking for simplicity and Neutron looks to not be able to
> offer it due to philosophical conflicts between Neutron developers and
> actual public users/operators. We can't force our users to adhere to ONE
> networking philosophy: use NAT, floating IPs, firewall, routers, etc.
> They just don't buy it. Period. (see monty's list of public providers
> attaching VMs to public network)
>

Public providers networking needs are not the only needs that Neutron tries
to gather. There's a balance to be struck, and I appreciate that the
balance may need to be adjusted, but being so dismissive is being myopic of
the entire industry landscape.


>
> If we can accept and agree that not everyone wishes to adhere to the
> "full stack of networking good practices" (TBH, I don't know how to call
> this thing), it will be a good start. Otherwise I feel we won't be able
> to achieve anything.
>
> What Monty is explaining and suggesting is something we (my team) have
> been struggling with for *years* and just didn't have bandwidth (we are
> operators, not developers) or public charisma to change.
>
> I'm glad Monty brought up this subject so we can officially address it.
>
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-July/070028.html
> [2]
>
> http://lists.openstack.org/pipermail/openstack-operators/2015-August/007857.html
> [3]
>
> http://specs.openstack.org/openstack/neutron-specs/specs/liberty/get-me-a-network.html
> [4]
>
> http://lists.openstack.org/pipermail/openstack-operators/2015-June/007427.html
>
> --
> 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
>
__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Doug Wiegley]

Hi all,

If I can attempt to summarize this thread:

“We want simple networks with VMs”

Ok, in progress, start here:

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


“It should work with multiple networks”

Same spec, click above.

“It should work with just ‘nova boot’”

Yup, you guessed it, starting point is the same spec, click above.

“It should still work in the face of N-tiered ambiguity.”

Umm, how, exactly? I think if you have a super complicated setup, your boot 
might be a bit harder, too. Please look at the cases that are covered before 
getting upset, and then provide feedback on the spec.

“Networks should be accessible by name.”

Yup, if they don’t, it’s a bug. The client a few cycles ago was particularly 
bad at this. If you find more cases, please file a bug.

“Neutron doesn’t get it and never will.”

I’m not sure how all ‘yes’ above keeps translating to this old saw, but is 
there any tiny chance we can stop living in the past and instead focus on the 
use cases that we want to solve?

Thanks,
doug



> On Sep 15, 2015, at 5:44 PM, Armando M.  wrote:
> 
> 
> 
> On 15 September 2015 at 15:11, Mathieu Gagné  > wrote:
> On 2015-09-15 2:00 PM, Fox, Kevin M wrote:
> > We run several clouds where there are multiple external networks. the "just 
> > run it in on THE public network" doesn't work. :/
> >
> > I also strongly recommend to users to put vms on a private network and use 
> > floating ip's/load balancers. For many reasons. Such as, if you don't, the 
> > ip that gets assigned to the vm helps it become a pet. you can't replace 
> > the vm and get the same IP. Floating IP's and load balancers can help 
> > prevent pets. It also prevents security issues with DNS and IP's. Also, for 
> > every floating ip/lb I have, I usually have 3x or more the number of 
> > instances that are on the private network. Sure its easy to put everything 
> > on the public network, but it provides much better security if you only put 
> > what you must on the public network. Consider the internet. would you want 
> > to expose every device in your house directly on the internet? No. you put 
> > them in a private network and poke holes just for the stuff that does. we 
> > should be encouraging good security practices. If we encourage bad ones, 
> > then it will bite us later when OpenStack gets a reputation for being 
> > associated with compromises.
> >
> 
> Sorry but I feel this kind of reply explains why people are still using
> nova-network over Neutron. People want simplicity and they are denied it
> at every corner because (I feel) Neutron thinks it knows better.
> 
> I am sorry, but how can you associate a person's opinion to a project, which 
> is a collectivity? Surely everyone is entitled to his/her opinion, but I 
> don't honestly believe these are fair statements to make.
> 
> 
> The original statement by Monty Taylor is clear to me:
> 
> I wish to boot an instance that is on a public network and reachable
> without madness.
> 
> As of today, you can't unless you implement a deployer/provider specific
> solution (to scale said network). Just take a look at what actual public
> cloud providers are doing:
> 
> - Rackspace has a "magic" public network
> - GoDaddy has custom code in their nova-scheduler (AFAIK)
> - iWeb (which I work for) has custom code in front of nova-api.
> 
> We are all writing our own custom code to implement what (we feel)
> Neutron should be providing right off the bat.
> 
> What is that you think Neutron should be providing right off the bat? I 
> personally have never seen you publicly report usability issues that 
> developers could go and look into. Let's escalate these so that the Neutron 
> team can be aware.
>  
> 
> By reading the openstack-dev [1], openstack-operators [2] lists, Neutron
> specs [3] and the Large Deployment Team meeting notes [4], you will see
> that what is suggested here (a scalable public shared network) is an
> objective we wish but are struggling hard to achieve.
> 
> There are many ways to skin this cat IMO, and scalable public shared network 
> can really have multiple meanings, I appreciate the pointers nonetheless.
>  
> 
> People keep asking for simplicity and Neutron looks to not be able to
> offer it due to philosophical conflicts between Neutron developers and
> actual public users/operators. We can't force our users to adhere to ONE
> networking philosophy: use NAT, floating IPs, firewall, routers, etc.
> They just don't buy it. Period. (see monty's list of public providers
> attaching VMs to public network)
> 
> Public providers networking needs are not the only needs that Neutron tries 
> to gather. There's a balance to be struck, and I appreciate that the balance 
> may need to be adjusted, but being so dismissive is being myopic of the 
> entire industry landscape.
>  
> 
> If we can 

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Mathieu Gagné]

On 2015-09-15 7:44 PM, Armando M. wrote:
> 
> 
> On 15 September 2015 at 15:11, Mathieu Gagné  > wrote:
> 
> On 2015-09-15 2:00 PM, Fox, Kevin M wrote:
> > We run several clouds where there are multiple external networks. the 
> "just run it in on THE public network" doesn't work. :/
> >
> > I also strongly recommend to users to put vms on a private network and 
> use floating ip's/load balancers. For many reasons. Such as, if you don't, 
> the ip that gets assigned to the vm helps it become a pet. you can't replace 
> the vm and get the same IP. Floating IP's and load balancers can help prevent 
> pets. It also prevents security issues with DNS and IP's. Also, for every 
> floating ip/lb I have, I usually have 3x or more the number of instances that 
> are on the private network. Sure its easy to put everything on the public 
> network, but it provides much better security if you only put what you must 
> on the public network. Consider the internet. would you want to expose every 
> device in your house directly on the internet? No. you put them in a private 
> network and poke holes just for the stuff that does. we should be encouraging 
> good security practices. If we encourage bad ones, then it will bite us later 
> when OpenStack gets a reputation for being associated with compromises.
> >
> 
> Sorry but I feel this kind of reply explains why people are still using
> nova-network over Neutron. People want simplicity and they are denied it
> at every corner because (I feel) Neutron thinks it knows better.
> 
> 
> I am sorry, but how can you associate a person's opinion to a project,
> which is a collectivity? Surely everyone is entitled to his/her opinion,
> but I don't honestly believe these are fair statements to make.

You are right, this is not fair. I apologize for that.


> The original statement by Monty Taylor is clear to me:
> 
> I wish to boot an instance that is on a public network and reachable
> without madness.
> 
> As of today, you can't unless you implement a deployer/provider specific
> solution (to scale said network). Just take a look at what actual public
> cloud providers are doing:
> 
> - Rackspace has a "magic" public network
> - GoDaddy has custom code in their nova-scheduler (AFAIK)
> - iWeb (which I work for) has custom code in front of nova-api.
> 
> We are all writing our own custom code to implement what (we feel)
> Neutron should be providing right off the bat.
> 
> 
> What is that you think Neutron should be providing right off the bat? I
> personally have never seen you publicly report usability issues that
> developers could go and look into. Let's escalate these so that the
> Neutron team can be aware.

Please understand that I'm an operator and don't have the luxury to
contribute as much as I did before. I however participate to OpenStack
Ops meetup and this is the kind of things we discuss. You can read the
use cases below to understand what I'm referring to. I don't feel the
need to add yet another version of it since there are already multiple
ones identifying my needs.

People (such as Monty) are already voicing my concerns and I didn't feel
the need to voice mine too.


> By reading the openstack-dev [1], openstack-operators [2] lists, Neutron
> specs [3] and the Large Deployment Team meeting notes [4], you will see
> that what is suggested here (a scalable public shared network) is an
> objective we wish but are struggling hard to achieve.
> 
> 
> There are many ways to skin this cat IMO, and scalable public shared
> network can really have multiple meanings, I appreciate the pointers
> nonetheless.
>  
> 
> 
> People keep asking for simplicity and Neutron looks to not be able to
> offer it due to philosophical conflicts between Neutron developers and
> actual public users/operators. We can't force our users to adhere to ONE
> networking philosophy: use NAT, floating IPs, firewall, routers, etc.
> They just don't buy it. Period. (see monty's list of public providers
> attaching VMs to public network)
> 
> 
> Public providers networking needs are not the only needs that Neutron
> tries to gather. There's a balance to be struck, and I appreciate that
> the balance may need to be adjusted, but being so dismissive is being
> myopic of the entire industry landscape.

We (my employer) also maintain private clouds and I'm fully aware of the
different between those needs. Therefore I don't think it's fair to say
that my opinion in nearsighted. Nonetheless, I would like this balance
to be adjusted and that's what I'm asking for and glad to see.


> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-July/070028.html
> [2]
> 
> http://lists.openstack.org/pipermail/openstack-operators/2015-August/007857.html
> [3]
> 
> 

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Doug Wiegley]

Sorry, didn’t mean that to come down as a triple pile-on, with me doing it 
twice. My bad, I’m sorry.

Thanks,
doug


> On Sep 15, 2015, at 6:11 PM, Mathieu Gagné  wrote:
> 
> On 2015-09-15 8:06 PM, Doug Wiegley wrote:
>> 
>> “Neutron doesn’t get it and never will.”
>> 
>> I’m not sure how all ‘yes’ above keeps translating to this old saw, but
>> is there any tiny chance we can stop living in the past and instead
>> focus on the use cases that we want to solve?
>> 
> 
> I apologized for my unfair statement where I very wrongly associated a
> person's opinion to a whole project. I would like to move on. Thanks
> 
> -- 
> 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


__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Monty Taylor]

On 09/16/2015 02:06 AM, Doug Wiegley wrote:

Hi all,

If I can attempt to summarize this thread:

“We want simple networks with VMs”

Ok, in progress, start here:

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


\o/


“It should work with multiple networks”

Same spec, click above.


\o/


“It should work with just ‘nova boot’”

Yup, you guessed it, starting point is the same spec, click above.


\o/


“It should still work in the face of N-tiered ambiguity.”

Umm, how, exactly? I think if you have a super complicated setup, your
boot might be a bit harder, too. Please look at the cases that are
covered before getting upset, and then provide feedback on the spec.


Yeah. For the record, I have never thought the simple case should handle 
anything but the simple case.



“Networks should be accessible by name.”

Yup, if they don’t, it’s a bug. The client a few cycles ago was
particularly bad at this. If you find more cases, please file a bug.

“Neutron doesn’t get it and never will.”

I’m not sure how all ‘yes’ above keeps translating to this old saw, but
is there any tiny chance we can stop living in the past and instead
focus on the use cases that we want to solve?


Also for the record, I find neutron very pleasant to work with. The 
clouds who have chosen to mark their "public" network as "shared" are 
the most pleasant- but even the ones who have not chosen to do that are 
still pretty darned good.


The clouds without neutron at all are the worst to work with.




On Sep 15, 2015, at 5:44 PM, Armando M. > wrote:



On 15 September 2015 at 15:11, Mathieu Gagné > wrote:

On 2015-09-15 2:00 PM, Fox, Kevin M wrote:
> We run several clouds where there are multiple external networks. the "just 
run it in on THE public network" doesn't work. :/
>
> I also strongly recommend to users to put vms on a private network and 
use floating ip's/load balancers. For many reasons. Such as, if you don't, the ip 
that gets assigned to the vm helps it become a pet. you can't replace the vm and 
get the same IP. Floating IP's and load balancers can help prevent pets. It also 
prevents security issues with DNS and IP's. Also, for every floating ip/lb I have, 
I usually have 3x or more the number of instances that are on the private network. 
Sure its easy to put everything on the public network, but it provides much better 
security if you only put what you must on the public network. Consider the 
internet. would you want to expose every device in your house directly on the 
internet? No. you put them in a private network and poke holes just for the stuff 
that does. we should be encouraging good security practices. If we encourage bad 
ones, then it will bite us later when OpenStack gets a reputation for being 
associated with compromises.
>

Sorry but I feel this kind of reply explains why people are still
using
nova-network over Neutron. People want simplicity and they are
denied it
at every corner because (I feel) Neutron thinks it knows better.


I am sorry, but how can you associate a person's opinion to a project,
which is a collectivity? Surely everyone is entitled to his/her
opinion, but I don't honestly believe these are fair statements to make.


The original statement by Monty Taylor is clear to me:

I wish to boot an instance that is on a public network and reachable
without madness.

As of today, you can't unless you implement a deployer/provider
specific
solution (to scale said network). Just take a look at what actual
public
cloud providers are doing:

- Rackspace has a "magic" public network
- GoDaddy has custom code in their nova-scheduler (AFAIK)
- iWeb (which I work for) has custom code in front of nova-api.

We are all writing our own custom code to implement what (we feel)
Neutron should be providing right off the bat.


What is that you think Neutron should be providing right off the bat?
I personally have never seen you publicly report usability issues that
developers could go and look into. Let's escalate these so that the
Neutron team can be aware.


By reading the openstack-dev [1], openstack-operators [2] lists,
Neutron
specs [3] and the Large Deployment Team meeting notes [4], you
will see
that what is suggested here (a scalable public shared network) is an
objective we wish but are struggling hard to achieve.


There are many ways to skin this cat IMO, and scalable public shared
network can really have multiple meanings, I appreciate the pointers
nonetheless.


People keep asking for simplicity and Neutron looks to not be able to
offer it due to philosophical conflicts between Neutron developers and
actual public users/operators. We can't force our users to adhere
to ONE
networking philosophy: use NAT, floating IPs, firewall, routers, etc.
They 

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Matt Kassawara]

Monty,

The architectural changes to the installation guide for Liberty [1] support
booting VMs on both the public/external/provider and
private/project/self-service networks.

Also, we should consider including similar "hybrid" scenarios in the
networking guide [2] so deployers don't have to choose between these
architectures.

[1] https://review.openstack.org/#/c/221560/
[2] http://docs.openstack.org/networking-guide/deploy.html

Matt

On Tue, Sep 15, 2015 at 9:04 AM, Monty Taylor  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"?
>
> 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
>
> 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"
>
> Thoughts?
>
> Monty
>
> __
> 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
>
__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Mathieu Gagné]

On 2015-09-15 6:49 PM, Doug Wiegley wrote:
> 
> 
>> On Sep 15, 2015, at 4:11 PM, Mathieu Gagné  wrote:
>>
>>> On 2015-09-15 2:00 PM, Fox, Kevin M wrote:
>>> We run several clouds where there are multiple external networks. the "just 
>>> run it in on THE public network" doesn't work. :/
>>>
>>> I also strongly recommend to users to put vms on a private network and use 
>>> floating ip's/load balancers. For many reasons. Such as, if you don't, the 
>>> ip that gets assigned to the vm helps it become a pet. you can't replace 
>>> the vm and get the same IP. Floating IP's and load balancers can help 
>>> prevent pets. It also prevents security issues with DNS and IP's. Also, for 
>>> every floating ip/lb I have, I usually have 3x or more the number of 
>>> instances that are on the private network. Sure its easy to put everything 
>>> on the public network, but it provides much better security if you only put 
>>> what you must on the public network. Consider the internet. would you want 
>>> to expose every device in your house directly on the internet? No. you put 
>>> them in a private network and poke holes just for the stuff that does. we 
>>> should be encouraging good security practices. If we encourage bad ones, 
>>> then it will bite us later when OpenStack gets a reputation for being 
>>> associated with compromises.
>>
>> Sorry but I feel this kind of reply explains why people are still using
>> nova-network over Neutron. People want simplicity and they are denied it
>> at every corner because (I feel) Neutron thinks it knows better.
> 
> Please stop painting such generalizations.  Go to the third or fourth email 
> in this thread and you will find a spec, worked on by neutron and nova, that 
> addresses exactly this use case.
> 
> It is a valid use case, and neutron does care about it. It has wrinkles. That 
> has not stopped work on it for the common cases.
> 

I've read the neutron spec you are referring (which I mentioned in my
email) and I'm glad the subject is discussed. This was not my intention
to diminish the work done by the Neutron team to address those issues. I
wrongly associate a person's opinion to a whole project, this is not
fair, I apologize for that.

Jeremy Stanley replied to Kevin with much better words than mine.

-- 
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Mathieu Gagné]

On 2015-09-15 8:06 PM, Doug Wiegley wrote:
> 
> “Neutron doesn’t get it and never will.”
> 
> I’m not sure how all ‘yes’ above keeps translating to this old saw, but
> is there any tiny chance we can stop living in the past and instead
> focus on the use cases that we want to solve?
> 

I apologized for my unfair statement where I very wrongly associated a
person's opinion to a whole project. I would like to move on. Thanks

-- 
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Mathieu Gagné]

On 2015-09-15 2:00 PM, Fox, Kevin M wrote:
> We run several clouds where there are multiple external networks. the "just 
> run it in on THE public network" doesn't work. :/
> 
> I also strongly recommend to users to put vms on a private network and use 
> floating ip's/load balancers. For many reasons. Such as, if you don't, the ip 
> that gets assigned to the vm helps it become a pet. you can't replace the vm 
> and get the same IP. Floating IP's and load balancers can help prevent pets. 
> It also prevents security issues with DNS and IP's. Also, for every floating 
> ip/lb I have, I usually have 3x or more the number of instances that are on 
> the private network. Sure its easy to put everything on the public network, 
> but it provides much better security if you only put what you must on the 
> public network. Consider the internet. would you want to expose every device 
> in your house directly on the internet? No. you put them in a private network 
> and poke holes just for the stuff that does. we should be encouraging good 
> security practices. If we encourage bad ones, then it will bite us later when 
> OpenStack gets a reputation for being associated with compromises.
> 

Sorry but I feel this kind of reply explains why people are still using
nova-network over Neutron. People want simplicity and they are denied it
at every corner because (I feel) Neutron thinks it knows better.

The original statement by Monty Taylor is clear to me:

I wish to boot an instance that is on a public network and reachable
without madness.

As of today, you can't unless you implement a deployer/provider specific
solution (to scale said network). Just take a look at what actual public
cloud providers are doing:

- Rackspace has a "magic" public network
- GoDaddy has custom code in their nova-scheduler (AFAIK)
- iWeb (which I work for) has custom code in front of nova-api.

We are all writing our own custom code to implement what (we feel)
Neutron should be providing right off the bat.

By reading the openstack-dev [1], openstack-operators [2] lists, Neutron
specs [3] and the Large Deployment Team meeting notes [4], you will see
that what is suggested here (a scalable public shared network) is an
objective we wish but are struggling hard to achieve.

People keep asking for simplicity and Neutron looks to not be able to
offer it due to philosophical conflicts between Neutron developers and
actual public users/operators. We can't force our users to adhere to ONE
networking philosophy: use NAT, floating IPs, firewall, routers, etc.
They just don't buy it. Period. (see monty's list of public providers
attaching VMs to public network)

If we can accept and agree that not everyone wishes to adhere to the
"full stack of networking good practices" (TBH, I don't know how to call
this thing), it will be a good start. Otherwise I feel we won't be able
to achieve anything.

What Monty is explaining and suggesting is something we (my team) have
been struggling with for *years* and just didn't have bandwidth (we are
operators, not developers) or public charisma to change.

I'm glad Monty brought up this subject so we can officially address it.


[1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/070028.html
[2]
http://lists.openstack.org/pipermail/openstack-operators/2015-August/007857.html
[3]
http://specs.openstack.org/openstack/neutron-specs/specs/liberty/get-me-a-network.html
[4]
http://lists.openstack.org/pipermail/openstack-operators/2015-June/007427.html

-- 
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Matt Riedemann]

On 9/15/2015 10:27 AM, Mike Spreitzer wrote:

Monty Taylor  wrote on 09/15/2015 11:04:07 AM:

 > 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

I am not using the latest, but rather Juno.  I find that in many places
the Neutron CLI insists on a UUID when a name could be used.  Three
cheers for any campaign to fix that.


It's my understanding that network names in neutron, like security 
groups, are not unique, that's why you have to specify a UUID.




And, yeah, creating VMs on a shared public network is good too.

Thanks,
mike


__
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



--

Thanks,

Matt Riedemann


__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Doug Hellmann]

Excerpts from Armando M.'s message of 2015-09-15 09:30:35 -0700:
> On 15 September 2015 at 08:04, Monty Taylor  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.
> 
> 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.

As with the Glance image upload API discussion, this is an example
of an extremely common use case that is either complex for the end
user or for which they have to know something about the deployment
in order to do it at all. The usability of an OpenStack cloud running
neutron would be enhanced greatly if there was a simple, clear, way
for the user to get a new VM with a public IP on any cloud without
multiple steps on their part. There are a lot of ways to implement
that "under the hood" (what you call "networking profile" above)
but the users don't care about "under the hood" so we should provide
a way for them to ignore it. That's *not* the same as saying we
should only support one profile. Think about the API from the use
case perspective, and build it so if there are different deployment
configurations available, the right action can be taken based on
the deployment choices made without the user providing any hints.

Doug

> 
> >
> > 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
> >
> > 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"
> >
> > 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?
> 
> >
> > Monty
> >
> > __
> > 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
> >

__
OpenStack Development Mailing List 

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Fox, Kevin M]

Most projects let you specify a name, and only force you to use a uuid IFF 
there is a conflict, leaving it up to the user to decide if they want the ease 
of use of names and being careful to name things, or having to use uuid's and 
not.

Neutron also has the odd wrinkle in that if your a cloud admin, it always gives 
you all the resources back in a listing rather then just the current tenant 
with a flag saying all.

This means if you try to use the "default" security group for example, it may 
work as a user, and then fail as an admin on the same tenant. very annoying. :/

I've had to work around that in heat templates before.

Thanks,
Kevin



From: Matt Riedemann [mrie...@linux.vnet.ibm.com]
Sent: Tuesday, September 15, 2015 11:28 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' 
network model

On 9/15/2015 10:27 AM, Mike Spreitzer wrote:
> Monty Taylor <mord...@inaugust.com> wrote on 09/15/2015 11:04:07 AM:
>
>  > 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
>
> I am not using the latest, but rather Juno.  I find that in many places
> the Neutron CLI insists on a UUID when a name could be used.  Three
> cheers for any campaign to fix that.

It's my understanding that network names in neutron, like security
groups, are not unique, that's why you have to specify a UUID.

>
> And, yeah, creating VMs on a shared public network is good too.
>
> Thanks,
> mike
>
>
> __
> 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
>

--

Thanks,

Matt Riedemann


__
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

__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Doug Wiegley]

Hi all,

One solution to this was a neutron spec that was added for a “get me a network” 
api, championed by Jay Pipes, which would auto-assign a public network on vm 
boot. It looks like it was resource starved in Liberty, though:

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


Thanks,
doug


> On Sep 15, 2015, at 9:27 AM, Mike Spreitzer  wrote:
> 
> Monty Taylor  wrote on 09/15/2015 11:04:07 AM:
> 
> > 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
> 
> I am not using the latest, but rather Juno.  I find that in many places the 
> Neutron CLI insists on a UUID when a name could be used.  Three cheers for 
> any campaign to fix that.
> 
> And, yeah, creating VMs on a shared public network is good too.
> 
> Thanks,
> mike
> __
> 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

__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Mike Spreitzer]

Monty Taylor  wrote on 09/15/2015 11:04:07 AM:

> 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

I am not using the latest, but rather Juno.  I find that in many places 
the Neutron CLI insists on a UUID when a name could be used.  Three cheers 
for any campaign to fix that.

And, yeah, creating VMs on a shared public network is good too.

Thanks,
mike

__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Armando M.]

On 15 September 2015 at 08:04, Monty Taylor  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.

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.


>
> 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
>
> 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"
>
> 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?


>
> Monty
>
> __
> 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
>
__
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

[openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Monty Taylor]

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"?


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


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"


Thoughts?

Monty

__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Fox, Kevin M]

We run several clouds where there are multiple external networks. the "just run 
it in on THE public network" doesn't work. :/

I also strongly recommend to users to put vms on a private network and use 
floating ip's/load balancers. For many reasons. Such as, if you don't, the ip 
that gets assigned to the vm helps it become a pet. you can't replace the vm 
and get the same IP. Floating IP's and load balancers can help prevent pets. It 
also prevents security issues with DNS and IP's. Also, for every floating ip/lb 
I have, I usually have 3x or more the number of instances that are on the 
private network. Sure its easy to put everything on the public network, but it 
provides much better security if you only put what you must on the public 
network. Consider the internet. would you want to expose every device in your 
house directly on the internet? No. you put them in a private network and poke 
holes just for the stuff that does. we should be encouraging good security 
practices. If we encourage bad ones, then it will bite us later when OpenStack 
gets a reputation for being associated with compromises.

I do consider making things as simple as possible very important. but that is, 
make them as simple as possible, but no simpler. There's danger here of making 
things too simple.

Thanks,
Kevin

From: Doug Hellmann [d...@doughellmann.com]
Sent: Tuesday, September 15, 2015 10:02 AM
To: openstack-dev
Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed 
'default' network model

Excerpts from Armando M.'s message of 2015-09-15 09:30:35 -0700:
> On 15 September 2015 at 08:04, Monty Taylor <mord...@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.
>
> 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.

As with the Glance image upload API discussion, this is an example
of an extremely common use case that is either complex for the end
user or for which they have to know something about the deployment
in order to do it at all. The usability of an OpenStack cloud running
neutron would be enhanced greatly if there was a simple, clear, way
for the user to get a new VM with a public IP on any cloud without
multiple steps on their part. There are a lot of ways to implement
that "under the hood" (what you call "ne

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Kyle Mestery]

That's exactly right, and we need to get this merged early in Mitaka. We'll
discuss this in a design summit session in Tokyo in fact to ensure it's
resourced correctly and continues to address the evolving needs in this
space.

On Tue, Sep 15, 2015 at 10:47 AM, Doug Wiegley  wrote:

> Hi all,
>
> One solution to this was a neutron spec that was added for a “get me a
> network” api, championed by Jay Pipes, which would auto-assign a public
> network on vm boot. It looks like it was resource starved in Liberty,
> though:
>
> https://blueprints.launchpad.net/neutron/+spec/get-me-a-network
>
> Thanks,
> doug
>
>
> On Sep 15, 2015, at 9:27 AM, Mike Spreitzer  wrote:
>
> Monty Taylor  wrote on 09/15/2015 11:04:07 AM:
>
> > 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
>
> I am not using the latest, but rather Juno.  I find that in many places
> the Neutron CLI insists on a UUID when a name could be used.  Three cheers
> for any campaign to fix that.
>
> And, yeah, creating VMs on a shared public network is good too.
>
> Thanks,
> mike
> __
> 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
>
>
>
> __
> 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
>
>
__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Armando M.]

On 15 September 2015 at 08:27, Mike Spreitzer  wrote:

> Monty Taylor  wrote on 09/15/2015 11:04:07 AM:
>
> > 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
>
> I am not using the latest, but rather Juno.  I find that in many places
> the Neutron CLI insists on a UUID when a name could be used.  Three cheers
> for any campaign to fix that.


The client is not particularly tied to a specific version of the server, so
we don't have a Juno version, or a Kilo version, etc. (even though they are
aligned, see [1] for more details).

Having said that, you could use names in place of uuids pretty much
anywhere. If your experience says otherwise, please consider filing a bug
against the client [2] and we'll get it fixed.

Thanks,
Armando

[1] https://launchpad.net/python-neutronclient/+series
[2] https://bugs.launchpad.net/python-neutronclient/+filebug


>
>
> And, yeah, creating VMs on a shared public network is good too.
>
> Thanks,
> mike
>
> __
> 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
>
>
__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Armando M.]

On 15 September 2015 at 11:28, Matt Riedemann 
wrote:

>
>
> On 9/15/2015 10:27 AM, Mike Spreitzer wrote:
>
>> Monty Taylor  wrote on 09/15/2015 11:04:07 AM:
>>
>>  > 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
>>
>> I am not using the latest, but rather Juno.  I find that in many places
>> the Neutron CLI insists on a UUID when a name could be used.  Three
>> cheers for any campaign to fix that.
>>
>
> It's my understanding that network names in neutron, like security groups,
> are not unique, that's why you have to specify a UUID.
>

Last time I checked, that's true of any resource in Openstack.


>
>> And, yeah, creating VMs on a shared public network is good too.
>>
>> Thanks,
>> mike
>>
>>
>> __
>> 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
>>
>>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
> __
> 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
>
__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Mohammad Banikazemi]

"Fox, Kevin M" <kevin@pnnl.gov> wrote on 09/15/2015 02:57:10 PM:

> From: "Fox, Kevin M" <kevin@pnnl.gov>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: 09/15/2015 02:59 PM
> Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> 'default' network model
>
> Most projects let you specify a name, and only force you to use a
> uuid IFF there is a conflict, leaving it up to the user to decide if
> they want the ease of use of names and being careful to name things,
> or having to use uuid's and not.

That is how Neutron works as well. If it doesn't in some cases, then those
are bugs that need to be filed and fixed.

mb@ubuntu14:~$ neutron net-create x1
Created a new network:
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| id| 02fd014d-3a84-463f-a158-317411528ff3 |
| mtu   | 0|
| name  | x1   |
| port_security_enabled | True |
| provider:network_type | vxlan|
| provider:physical_network |  |
| provider:segmentation_id  | 1037 |
| router:external   | False|
| shared| False|
| status| ACTIVE   |
| subnets   |  |
| tenant_id | ce56abd5661f4140a5df98927a6f54d8 |
+---+--+
mb@ubuntu14:~$ neutron net-delete x1
Deleted network: x1

mb@ubuntu14:~$ neutron net-create x1
Created a new network:
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| id| db95539c-1c33-4791-a87f-608872ed3e86 |
| mtu   | 0|
| name  | x1   |
| port_security_enabled | True |
| provider:network_type | vxlan|
| provider:physical_network |  |
| provider:segmentation_id  | 1010 |
| router:external   | False|
| shared| False|
| status| ACTIVE   |
| subnets   |  |
| tenant_id | ce56abd5661f4140a5df98927a6f54d8 |
+---+--+
mb@ubuntu14:~$ neutron net-create x1
Created a new network:
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| id| b2b3dd55-0f6f-46e7-aaef-c4a89a5d1ef9 |
| mtu   | 0|
| name  | x1   |
| port_security_enabled | True |
| provider:network_type | vxlan|
| provider:physical_network |  |
| provider:segmentation_id  | 1071 |
| router:external   | False|
| shared| False|
| status| ACTIVE   |
| subnets   |  |
| tenant_id | ce56abd5661f4140a5df98927a6f54d8 |
+---+--+
mb@ubuntu14:~$ neutron net-delete x1
Multiple network matches found for name 'x1', use an ID to be more
specific.
mb@ubuntu14:~$ neutron net-delete db95539c-1c33-4791-a87f-608872ed3e86
Deleted network: db95539c-1c33-4791-a87f-608872ed3e86
mb@ubuntu14:~$ neutron net-delete x1
Deleted network: x1
mb@ubuntu14:~$


Best,

Mohammad



>
> Neutron also has the odd wrinkle in that if your a cloud admin, it
> always gives you all th

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Armando M.]

On 15 September 2015 at 10:02, Doug Hellmann  wrote:

> Excerpts from Armando M.'s message of 2015-09-15 09:30:35 -0700:
> > On 15 September 2015 at 08:04, Monty Taylor 
> 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.
> >
> > 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.
>
> As with the Glance image upload API discussion, this is an example
> of an extremely common use case that is either complex for the end
> user or for which they have to know something about the deployment
> in order to do it at all. The usability of an OpenStack cloud running
> neutron would be enhanced greatly if there was a simple, clear, way
> for the user to get a new VM with a public IP on any cloud without
> multiple steps on their part.


I agree on this last statement wholeheartedly, but we gotta be careful on
how we do it, because there are implications on scalability and security.

Today Neutron provides a few network deployment models [1,2,3,4,5]. You can
mix and match, with the only caveat is that this stuff must be
pre-provisioned.

Now the way I understand Monty's request is that in certain deployments
you'd like automatic provisioning. We can look into that, as we have in
blueprint [6], but we must recognize that hint-less requests can be hard to
achieve because the way the network service is provided can vary from
system to system...a lot.

Defaults are useful, but wrong defaults are worse. A system can make an
educated guess as of the user's intention, in lieu of that an operator can
force the choice for the user, but if that one is hard too, then the only
choice is to defer to the user.

So this boils down to: in light of the possible ways of providing VM
connectivity, how can we make a choice on the user's behalf? Can we assume
that he/she always want a publicly facing VM connected to Internet? The
answer is 'no'.


> There are a lot of ways to implement
> that "under the hood" (what you call "networking profile" above)
> but the users don't care about "under the hood" so we should provide
> a way for them to ignore it. That's *not* the same as saying we
> should only support one profile. Think about the API from the use
> case perspective, and build it so if there are different deployment
> configurations available, the right action can be taken based on
> the deployment choices made without the user providing any hints.
>

[1]
http://docs.openstack.org/havana/install-guide/install/apt/content/section_use-cases-single-flat.html
[2]

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Mohammad Banikazemi]

"Fox, Kevin M" <kevin@pnnl.gov> wrote on 09/15/2015 02:00:03 PM:

> From: "Fox, Kevin M" <kevin@pnnl.gov>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: 09/15/2015 02:02 PM
> Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> 'default' network model
>
> We run several clouds where there are multiple external networks.
> the "just run it in on THE public network" doesn't work. :/
>
> I also strongly recommend to users to put vms on a private network
> and use floating ip's/load balancers.


Just curious to know how many floating IPs you have in each instance of
your OpenStack cloud.

Best,

Mohammad




For many reasons. Such as, if
> you don't, the ip that gets assigned to the vm helps it become a
> pet. you can't replace the vm and get the same IP. Floating IP's and
> load balancers can help prevent pets. It also prevents security
> issues with DNS and IP's. Also, for every floating ip/lb I have, I
> usually have 3x or more the number of instances that are on the
> private network. Sure its easy to put everything on the public
> network, but it provides much better security if you only put what
> you must on the public network. Consider the internet. would you
> want to expose every device in your house directly on the internet?
> No. you put them in a private network and poke holes just for the
> stuff that does. we should be encouraging good security practices.
> If we encourage bad ones, then it will bite us later when OpenStack
> gets a reputation for being associated with compromises.
>
> I do consider making things as simple as possible very important.
> but that is, make them as simple as possible, but no simpler.
> There's danger here of making things too simple.
>
> Thanks,
> Kevin
> ________________
> From: Doug Hellmann [d...@doughellmann.com]
> Sent: Tuesday, September 15, 2015 10:02 AM
> To: openstack-dev
> Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> 'default' network model
>
> Excerpts from Armando M.'s message of 2015-09-15 09:30:35 -0700:
> > On 15 September 2015 at 08:04, Monty Taylor <mord...@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.
> >

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Mohammad Banikazemi]

Thanks Kevin for your answer. My question was different. You mentioned in
your email that you run several clouds. That's why I used the word
"instance" in my question to refer to each of those clouds. So let me put
the question in a different way: in the biggest cloud you run, how many
total floating IPs do you have. Just a ballpark number will be great. 10s,
100s, 1000s, more?

Thanks,

Mohammad

"Fox, Kevin M" <kevin@pnnl.gov> wrote on 09/15/2015 03:43:45 PM:

> From: "Fox, Kevin M" <kevin@pnnl.gov>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: 09/15/2015 03:49 PM
> Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> 'default' network model
>
> I'm not quite sure how to read your question. I think it can be
> taken multiple ways. I'll guess at what you meant though. If I
> interpreted wrong, please ask again.
>
> For the instances that have floating ip's, usually either 1 or 2.
> One of our clouds has basically a public
> network directly on the internet, and a shared private network that
> crosses tenants but is not internet facing. We can place vm's on
> either network easily by just attaching floating ip's. The private
> shared network has more floating ip's assigned then the internet one
usually.
>
> As LBaaS is maturing, we're using it more and more, putting the
> floating ips on the LB instead of the instances, and putting a pool
> of instances behind it. So our instance counts are growing faster
> then our usage of floating IP's.
>
> Thanks,
> Kevin
>
> From: Mohammad Banikazemi [m...@us.ibm.com]
> Sent: Tuesday, September 15, 2015 12:23 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> 'default' network model

> "Fox, Kevin M" <kevin@pnnl.gov> wrote on 09/15/2015 02:00:03 PM:
>
> > From: "Fox, Kevin M" <kevin....@pnnl.gov>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev@lists.openstack.org>
> > Date: 09/15/2015 02:02 PM
> > Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> > 'default' network model
> >
> > We run several clouds where there are multiple external networks.
> > the "just run it in on THE public network" doesn't work. :/
> >
> > I also strongly recommend to users to put vms on a private network
> > and use floating ip's/load balancers.
>
>
> Just curious to know how many floating IPs you have in each instance
> of your OpenStack cloud.
>
> Best,
>
> Mohammad
>
>
>
>
> For many reasons. Such as, if
> > you don't, the ip that gets assigned to the vm helps it become a
> > pet. you can't replace the vm and get the same IP. Floating IP's and
> > load balancers can help prevent pets. It also prevents security
> > issues with DNS and IP's. Also, for every floating ip/lb I have, I
> > usually have 3x or more the number of instances that are on the
> > private network. Sure its easy to put everything on the public
> > network, but it provides much better security if you only put what
> > you must on the public network. Consider the internet. would you
> > want to expose every device in your house directly on the internet?
> > No. you put them in a private network and poke holes just for the
> > stuff that does. we should be encouraging good security practices.
> > If we encourage bad ones, then it will bite us later when OpenStack
> > gets a reputation for being associated with compromises.
> >
> > I do consider making things as simple as possible very important.
> > but that is, make them as simple as possible, but no simpler.
> > There's danger here of making things too simple.
> >
> > Thanks,
> > Kevin
> > 
> > From: Doug Hellmann [d...@doughellmann.com]
> > Sent: Tuesday, September 15, 2015 10:02 AM
> > To: openstack-dev
> > Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> > 'default' network model
> >
> > Excerpts from Armando M.'s message of 2015-09-15 09:30:35 -0700:
> > > On 15 September 2015 at 08:04, Monty Taylor <mord...@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 

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Fox, Kevin M]

I'm not quite sure how to read your question. I think it can be taken multiple 
ways. I'll guess at what you meant though. If I interpreted wrong, please ask 
again.

For the instances that have floating ip's, usually either 1 or 2. One of our 
clouds has basically a public
network directly on the internet, and a shared private network that crosses 
tenants but is not internet facing. We can place vm's on either network easily 
by just attaching floating ip's. The private shared network has more floating 
ip's assigned then the internet one usually.

As LBaaS is maturing, we're using it more and more, putting the floating ips on 
the LB instead of the instances, and putting a pool of instances behind it. So 
our instance counts are growing faster then our usage of floating IP's.

Thanks,
Kevin

From: Mohammad Banikazemi [m...@us.ibm.com]
Sent: Tuesday, September 15, 2015 12:23 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' 
network model


"Fox, Kevin M" <kevin@pnnl.gov> wrote on 09/15/2015 02:00:03 PM:

> From: "Fox, Kevin M" <kevin@pnnl.gov>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: 09/15/2015 02:02 PM
> Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> 'default' network model
>
> We run several clouds where there are multiple external networks.
> the "just run it in on THE public network" doesn't work. :/
>
> I also strongly recommend to users to put vms on a private network
> and use floating ip's/load balancers.


Just curious to know how many floating IPs you have in each instance of your 
OpenStack cloud.

Best,

Mohammad




For many reasons. Such as, if
> you don't, the ip that gets assigned to the vm helps it become a
> pet. you can't replace the vm and get the same IP. Floating IP's and
> load balancers can help prevent pets. It also prevents security
> issues with DNS and IP's. Also, for every floating ip/lb I have, I
> usually have 3x or more the number of instances that are on the
> private network. Sure its easy to put everything on the public
> network, but it provides much better security if you only put what
> you must on the public network. Consider the internet. would you
> want to expose every device in your house directly on the internet?
> No. you put them in a private network and poke holes just for the
> stuff that does. we should be encouraging good security practices.
> If we encourage bad ones, then it will bite us later when OpenStack
> gets a reputation for being associated with compromises.
>
> I do consider making things as simple as possible very important.
> but that is, make them as simple as possible, but no simpler.
> There's danger here of making things too simple.
>
> Thanks,
> Kevin
> ________________
> From: Doug Hellmann [d...@doughellmann.com]
> Sent: Tuesday, September 15, 2015 10:02 AM
> To: openstack-dev
> Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> 'default' network model
>
> Excerpts from Armando M.'s message of 2015-09-15 09:30:35 -0700:
> > On 15 September 2015 at 08:04, Monty Taylor <mord...@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.
> > >
> > > In

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Clark Boylan]

On Tue, Sep 15, 2015, at 11:00 AM, Fox, Kevin M wrote:
> We run several clouds where there are multiple external networks. the
> "just run it in on THE public network" doesn't work. :/
Maybe this would be better expressed as "just run it on an existing
public network" then?
> 
> I also strongly recommend to users to put vms on a private network and
> use floating ip's/load balancers. For many reasons. Such as, if you
> don't, the ip that gets assigned to the vm helps it become a pet. you
> can't replace the vm and get the same IP. Floating IP's and load
> balancers can help prevent pets. It also prevents security issues with
> DNS and IP's. Also, for every floating ip/lb I have, I usually have 3x or
> more the number of instances that are on the private network. Sure its
> easy to put everything on the public network, but it provides much better
> security if you only put what you must on the public network. Consider
> the internet. would you want to expose every device in your house
> directly on the internet? No. you put them in a private network and poke
> holes just for the stuff that does. we should be encouraging good
> security practices. If we encourage bad ones, then it will bite us later
> when OpenStack gets a reputation for being associated with compromises.
There are a few issues with this. Neutron IPv6 does not support floating
IPs. So now you have to use two completely different concepts for
networking on a single dual stacked VM. IPv4 goes on a private network
and you attach a floating IP. IPv6 is publicly routable. If security and
DNS and not making pets were really the driving force behind floating
IPs we would see IPv6 support them too. These aren't the reasons
floating IPs exist, they exist because we are running out of IPv4
addresses and NAT is everyones preferred solution to that problem. But
that doesn't make it a good default for a cloud; use them if you are
affected by an IP shortage.

Nothing prevents you from load balancing against public IPs to address
the DNS and firewall rule concerns (basically don't make pets). This
works great and is how OpenStack's git mirrors work.

It is also easy to firewall public IPs using Neutron via security groups
(and possibly the firewall service? I have never used it and don't
know). All this to say I think it is reasonable to use public shared
networks by default particularly since IPv6 does not have any concept of
a floating IP in Neutron so using them is just odd unless you really
really need them and you aren't actually any less secure.

Not to get too off topic, but I would love it if all the devices in my
home were publicly routable. I can use my firewall to punch holes for
them, NAT is not required. Unfortunately I still have issues with IPv6
at home. Maybe one day this will be a reality :)
> 
> I do consider making things as simple as possible very important. but
> that is, make them as simple as possible, but no simpler. There's danger
> here of making things too simple.
> 
> Thanks,
> Kevin
>

Clark

__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Assaf Muller]

On Tue, Sep 15, 2015 at 5:09 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:

> Unfortunately, I haven't had enough chance to play with ipv6 yet.
>
> I still think ipv6 with floating ip's probably makes sense though.
>
> In ipv4, the floating ip's solve one particular problem:
>
> End Users want to be able to consume a service provided by a VM. They have
> two options:
> 1. contact the ip directly
> 2. use DNS.
>
> DNS is preferable, since humans don't remember ip's very well. IPv6 is
> much harder to remember then v4 too.
>
> DNS has its own issues, mostly, its usually not very quick to get a DNS
> entry updated.  At our site (and I'm sure, others), I'm afraid to say in
> some cases it takes as long as 24 hours to get updates to happen. Even if
> that was fixed, caching can bite you too.
>

I'm curious if you tried out Designate / DNSaaS.


>
> So, when you register a DNS record, the ip that its pointing at, kind of
> becomes a set of state. If it can't be separated from a VM its a bad thing.
> You can move it from VM to VM and your VM is not a pet. But, if your IP is
> allocated to the VM specifically, as non Floating IP's are, you run into
> problems if your VM dies and you have to replace it. If your unlucky, it
> dies, and someone else gets allocated the fixed ip, and now someone else's
> server is sitting on your DNS entry! So you are very unlikely to want to
> give up your VM, turning it into a pet.
>
> I'd expect v6 usage to have the same issues.
>
> The floating ip is great in that its an abstraction of a contactable
> address, separate from any VM it may currently be bound to.
>
> You allocate a floating ip. You can then register it with DNS, and another
> tenant can not get accidentally assigned it. You can move it from vm to vm
> until your done with it. You can Unregister it from DNS, and then it is
> safe to return to others to use.
>
> To me, the NAT aspect of it is a secondary thing. Its primary importance
> is in enabling things to be more cattleish and helping with dns security.
>
> Thanks,
> Kevin
>
>
>
>
>
>
> ________
> From: Clark Boylan [cboy...@sapwetik.org]
> Sent: Tuesday, September 15, 2015 1:06 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> 'default' network model
>
> On Tue, Sep 15, 2015, at 11:00 AM, Fox, Kevin M wrote:
> > We run several clouds where there are multiple external networks. the
> > "just run it in on THE public network" doesn't work. :/
> Maybe this would be better expressed as "just run it on an existing
> public network" then?
> >
> > I also strongly recommend to users to put vms on a private network and
> > use floating ip's/load balancers. For many reasons. Such as, if you
> > don't, the ip that gets assigned to the vm helps it become a pet. you
> > can't replace the vm and get the same IP. Floating IP's and load
> > balancers can help prevent pets. It also prevents security issues with
> > DNS and IP's. Also, for every floating ip/lb I have, I usually have 3x or
> > more the number of instances that are on the private network. Sure its
> > easy to put everything on the public network, but it provides much better
> > security if you only put what you must on the public network. Consider
> > the internet. would you want to expose every device in your house
> > directly on the internet? No. you put them in a private network and poke
> > holes just for the stuff that does. we should be encouraging good
> > security practices. If we encourage bad ones, then it will bite us later
> > when OpenStack gets a reputation for being associated with compromises.
> There are a few issues with this. Neutron IPv6 does not support floating
> IPs. So now you have to use two completely different concepts for
> networking on a single dual stacked VM. IPv4 goes on a private network
> and you attach a floating IP. IPv6 is publicly routable. If security and
> DNS and not making pets were really the driving force behind floating
> IPs we would see IPv6 support them too. These aren't the reasons
> floating IPs exist, they exist because we are running out of IPv4
> addresses and NAT is everyones preferred solution to that problem. But
> that doesn't make it a good default for a cloud; use them if you are
> affected by an IP shortage.
>
> Nothing prevents you from load balancing against public IPs to address
> the DNS and firewall rule concerns (basically don't make pets). This
> works great and is how OpenStack's git mirrors work.
>
> It is also easy to firewall public IPs using Neutron via security groups
> (and possibly the firewall

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Fox, Kevin M]

Ah. Instance of Cloud, not Nova Instance. Gotcha.

The biggest currently has about 100 addresses on the public net and maybe about 
a quoter of those are allocated to instances. the shared private's about 200 
and around a 30 or 40 are used. We have a lot of big vm's on that cloud for HPC 
like workload, so there are only around a hundred fifty instances at present. 
The majority are huge, taking up a whole node. The rest are small, 
infrastructure related and a lot are HA behind load balancers. We're using host 
aggrigates to keep the workloads separate. Of the non Compute VM's, I'd say 
there's somewhere between a 2x relationship between vm's without floating ip's 
and those with.  That number's growing as we make things more HA.

Thanks,
Kevin

From: Mohammad Banikazemi [m...@us.ibm.com]
Sent: Tuesday, September 15, 2015 1:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' 
network model


Thanks Kevin for your answer. My question was different. You mentioned in your 
email that you run several clouds. That's why I used the word "instance" in my 
question to refer to each of those clouds. So let me put the question in a 
different way: in the biggest cloud you run, how many total floating IPs do you 
have. Just a ballpark number will be great. 10s, 100s, 1000s, more?

Thanks,

Mohammad

"Fox, Kevin M" <kevin@pnnl.gov> wrote on 09/15/2015 03:43:45 PM:

> From: "Fox, Kevin M" <kevin@pnnl.gov>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: 09/15/2015 03:49 PM
> Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> 'default' network model
>
> I'm not quite sure how to read your question. I think it can be
> taken multiple ways. I'll guess at what you meant though. If I
> interpreted wrong, please ask again.
>
> For the instances that have floating ip's, usually either 1 or 2.
> One of our clouds has basically a public
> network directly on the internet, and a shared private network that
> crosses tenants but is not internet facing. We can place vm's on
> either network easily by just attaching floating ip's. The private
> shared network has more floating ip's assigned then the internet one usually.
>
> As LBaaS is maturing, we're using it more and more, putting the
> floating ips on the LB instead of the instances, and putting a pool
> of instances behind it. So our instance counts are growing faster
> then our usage of floating IP's.
>
> Thanks,
> Kevin
>
> From: Mohammad Banikazemi [m...@us.ibm.com]
> Sent: Tuesday, September 15, 2015 12:23 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> 'default' network model

> "Fox, Kevin M" <kevin@pnnl.gov> wrote on 09/15/2015 02:00:03 PM:
>
> > From: "Fox, Kevin M" <kevin....@pnnl.gov>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev@lists.openstack.org>
> > Date: 09/15/2015 02:02 PM
> > Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> > 'default' network model
> >
> > We run several clouds where there are multiple external networks.
> > the "just run it in on THE public network" doesn't work. :/
> >
> > I also strongly recommend to users to put vms on a private network
> > and use floating ip's/load balancers.
>
>
> Just curious to know how many floating IPs you have in each instance
> of your OpenStack cloud.
>
> Best,
>
> Mohammad
>
>
>
>
> For many reasons. Such as, if
> > you don't, the ip that gets assigned to the vm helps it become a
> > pet. you can't replace the vm and get the same IP. Floating IP's and
> > load balancers can help prevent pets. It also prevents security
> > issues with DNS and IP's. Also, for every floating ip/lb I have, I
> > usually have 3x or more the number of instances that are on the
> > private network. Sure its easy to put everything on the public
> > network, but it provides much better security if you only put what
> > you must on the public network. Consider the internet. would you
> > want to expose every device in your house directly on the internet?
> > No. you put them in a private network and poke holes just for the
> > stuff that does. we should be encouraging good security practices.
> > If we encourage bad ones, then it will bite us later when OpenStack
> > gets a reputation for being associated with compromises.
> >
> > I do consider 

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Mike Spreitzer]

"Armando M."  wrote on 09/15/2015 03:50:24 PM:

> On 15 September 2015 at 10:02, Doug Hellmann  
wrote:
> Excerpts from Armando M.'s message of 2015-09-15 09:30:35 -0700:
...
> As with the Glance image upload API discussion, this is an example
> of an extremely common use case that is either complex for the end
> user or for which they have to know something about the deployment
> in order to do it at all. The usability of an OpenStack cloud running
> neutron would be enhanced greatly if there was a simple, clear, way
> for the user to get a new VM with a public IP on any cloud without
> multiple steps on their part. 

<>

...
> 
> So this boils down to: in light of the possible ways of providing VM
> connectivity, how can we make a choice on the user's behalf? Can we 
> assume that he/she always want a publicly facing VM connected to 
> Internet? The answer is 'no'.

While it may be true that in some deployments there is no good way for the 
code to choose, I think that is not the end of the story here.  The 
motivation to do this is that in *some* deployments there *is* a good way 
for the code to figure out what to do.

Regards,
Mike

__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Mike Spreitzer]

Clark Boylan  wrote on 09/15/2015 04:06:26 PM:

> > I also strongly recommend to users to put vms on a private network and
> > use floating ip's/load balancers. For many reasons. Such as, if you
> > don't, the ip that gets assigned to the vm helps it become a pet. you
> > can't replace the vm and get the same IP. Floating IP's and load
> > balancers can help prevent pets. It also prevents security issues with
> > DNS and IP's. Also, for every floating ip/lb I have, I usually have 3x 
or
> > more the number of instances that are on the private network. Sure its
> > easy to put everything on the public network, but it provides much 
better
> > security if you only put what you must on the public network. Consider
> > the internet. would you want to expose every device in your house
> > directly on the internet? No. you put them in a private network and 
poke
> > holes just for the stuff that does. we should be encouraging good
> > security practices. If we encourage bad ones, then it will bite us 
later
> > when OpenStack gets a reputation for being associated with 
compromises.
> There are a few issues with this. Neutron IPv6 does not support floating
> IPs. So now you have to use two completely different concepts for
> networking on a single dual stacked VM. IPv4 goes on a private network
> and you attach a floating IP. IPv6 is publicly routable. If security and
> DNS and not making pets were really the driving force behind floating
> IPs we would see IPv6 support them too. These aren't the reasons
> floating IPs exist, they exist because we are running out of IPv4
> addresses and NAT is everyones preferred solution to that problem. But
> that doesn't make it a good default for a cloud; use them if you are
> affected by an IP shortage.
> 
> Nothing prevents you from load balancing against public IPs to address
> the DNS and firewall rule concerns (basically don't make pets). This
> works great and is how OpenStack's git mirrors work.
> 
> It is also easy to firewall public IPs using Neutron via security groups
> (and possibly the firewall service? I have never used it and don't
> know). All this to say I think it is reasonable to use public shared
> networks by default particularly since IPv6 does not have any concept of
> a floating IP in Neutron so using them is just odd unless you really
> really need them and you aren't actually any less secure.

I'm really glad to see the IPv6 front opened.

But I have to say that the analysis of options for securing public 
addresses omits one case that I think is important: using an external (to 
Neutron) "appliance".  In my environment this is more or less required. 
This reinforces the bifurcation of addresses that was mentioned: some VMs 
are private and do not need any service from the external appliance, while 
others have addresses that need the external appliance on the 
public/private path.

In fact, for this reason, I have taken to using two "external" networks 
(from Neutron's point of view) --- one whose addresses are handled by the 
external appliance and one whose addresses are not.  In fact, both ranges 
of address are on the same VLAN.  This is FYI, some people have wondered 
why these thins might be done.

> Not to get too off topic, but I would love it if all the devices in my
> home were publicly routable. I can use my firewall to punch holes for
> them, NAT is not required. Unfortunately I still have issues with IPv6
> at home. Maybe one day this will be a reality :)

Frankly, given the propensity for bugs to be discovered, I am glad that 
nothing in my home is accessible from the outside (aside from the device 
that does firewall, and I worry about that too).  Not that this is really 
germane to what we want to do for internet-accessible 
applications/services.

Regards,
Mike

__
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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Fox, Kevin M]

Unfortunately, I haven't had enough chance to play with ipv6 yet.

I still think ipv6 with floating ip's probably makes sense though.

In ipv4, the floating ip's solve one particular problem:

End Users want to be able to consume a service provided by a VM. They have two 
options:
1. contact the ip directly
2. use DNS.

DNS is preferable, since humans don't remember ip's very well. IPv6 is much 
harder to remember then v4 too.

DNS has its own issues, mostly, its usually not very quick to get a DNS entry 
updated.  At our site (and I'm sure, others), I'm afraid to say in some cases 
it takes as long as 24 hours to get updates to happen. Even if that was fixed, 
caching can bite you too.

So, when you register a DNS record, the ip that its pointing at, kind of 
becomes a set of state. If it can't be separated from a VM its a bad thing. You 
can move it from VM to VM and your VM is not a pet. But, if your IP is 
allocated to the VM specifically, as non Floating IP's are, you run into 
problems if your VM dies and you have to replace it. If your unlucky, it dies, 
and someone else gets allocated the fixed ip, and now someone else's server is 
sitting on your DNS entry! So you are very unlikely to want to give up your VM, 
turning it into a pet.

I'd expect v6 usage to have the same issues.

The floating ip is great in that its an abstraction of a contactable address, 
separate from any VM it may currently be bound to.

You allocate a floating ip. You can then register it with DNS, and another 
tenant can not get accidentally assigned it. You can move it from vm to vm 
until your done with it. You can Unregister it from DNS, and then it is safe to 
return to others to use.

To me, the NAT aspect of it is a secondary thing. Its primary importance is in 
enabling things to be more cattleish and helping with dns security.

Thanks,
Kevin







From: Clark Boylan [cboy...@sapwetik.org]
Sent: Tuesday, September 15, 2015 1:06 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' 
network model

On Tue, Sep 15, 2015, at 11:00 AM, Fox, Kevin M wrote:
> We run several clouds where there are multiple external networks. the
> "just run it in on THE public network" doesn't work. :/
Maybe this would be better expressed as "just run it on an existing
public network" then?
>
> I also strongly recommend to users to put vms on a private network and
> use floating ip's/load balancers. For many reasons. Such as, if you
> don't, the ip that gets assigned to the vm helps it become a pet. you
> can't replace the vm and get the same IP. Floating IP's and load
> balancers can help prevent pets. It also prevents security issues with
> DNS and IP's. Also, for every floating ip/lb I have, I usually have 3x or
> more the number of instances that are on the private network. Sure its
> easy to put everything on the public network, but it provides much better
> security if you only put what you must on the public network. Consider
> the internet. would you want to expose every device in your house
> directly on the internet? No. you put them in a private network and poke
> holes just for the stuff that does. we should be encouraging good
> security practices. If we encourage bad ones, then it will bite us later
> when OpenStack gets a reputation for being associated with compromises.
There are a few issues with this. Neutron IPv6 does not support floating
IPs. So now you have to use two completely different concepts for
networking on a single dual stacked VM. IPv4 goes on a private network
and you attach a floating IP. IPv6 is publicly routable. If security and
DNS and not making pets were really the driving force behind floating
IPs we would see IPv6 support them too. These aren't the reasons
floating IPs exist, they exist because we are running out of IPv4
addresses and NAT is everyones preferred solution to that problem. But
that doesn't make it a good default for a cloud; use them if you are
affected by an IP shortage.

Nothing prevents you from load balancing against public IPs to address
the DNS and firewall rule concerns (basically don't make pets). This
works great and is how OpenStack's git mirrors work.

It is also easy to firewall public IPs using Neutron via security groups
(and possibly the firewall service? I have never used it and don't
know). All this to say I think it is reasonable to use public shared
networks by default particularly since IPv6 does not have any concept of
a floating IP in Neutron so using them is just odd unless you really
really need them and you aren't actually any less secure.

Not to get too off topic, but I would love it if all the devices in my
home were publicly routable. I can use my firewall to punch holes for
them, NAT is not required. Unfortunately I still have issues with IPv6
at home. Maybe one day this will be