Open Stack

Couple more dumb comments here - sorry that I'm processing this thread 
backwards!

On 16/06/15 15:20, Jay Pipes wrote:
> Adding -dev because of the reference to the Neutron "Get me a network
> spec". Also adding [nova] and [neutron] subject markers.
>
> Comments inline, Kris.
>
> On 05/22/2015 09:28 PM, Kris G. Lindgren wrote:
>> During the Openstack summit this week I got to talk to a number of other
>> operators of large Openstack deployments about how they do networking.
>>   I was happy, surprised even, to find that a number of us are using a
>> similar type of networking strategy.  That we have similar challenges
>> around networking and are solving it in our own but very similar way.
>>   It is always nice to see that other people are doing the same things
>> as you or see the same issues as you are and that "you are not crazy".
>> So in that vein, I wanted to reach out to the rest of the Ops Community
>> and ask one pretty simple question.
>>
>> Would it be accurate to say that most of your end users want almost
>> nothing to do with the network?
>
> That was my experience at AT&T, yes. The vast majority of end users
> could not care less about networking, as long as the connectivity was
> reliable, performed well, and they could connect to the Internet (and
> have others connect from the Internet to their VMs) when needed.
>
>> In my experience what the majority of them (both internal and external)
>> want is to consume from Openstack a compute resource, a property of
>> which is it that resource has an IP address.  They, at most, care about
>> which "network" they are on.  Where a "network" is usually an arbitrary
>> definition around a set of real networks, that are constrained to a
>> location, in which the company has attached some sort of policy.  For
>> example, I want to be in the production network vs's the xyz lab
>> network, vs's the backup network, vs's the corp network.  I would say
>> for Godaddy, 99% of our use cases would be defined as: I want a compute
>> resource in the production network zone, or I want a compute resource in
>> this other network zone.

Kris - this looks like the answer to my question why you define multiple 
networks.  If that's right, no need to answer that question there.

>>  The end user only cares that the IP the vm
>> receives works in that zone, outside of that they don't care any other
>> property of that IP.  They do not care what subnet it is in, what vlan
>> it is on, what switch it is attached to, what router its attached to, or
>> how data flows in/out of that network.  It just needs to work.

Agreed.  I'm not a deployer, but my team is in contact with many 
deployers who say similar things.

Regards,
	Neil