On 2015-09-15 7:44 PM, Armando M. 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.

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


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

Reply via email to