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. <arma...@gmail.com
<mailto:arma...@gmail.com>> wrote:
On 15 September 2015 at 15:11, Mathieu Gagné <mga...@internap.com
<mailto:mga...@internap.com>> 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://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
<mailto: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
