Open Stack

Hi Kris,

Busy week! It was good seeing you in Vancouver - even if it was just in
passing on the escalator ;)

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

+100


> Would it be accurate to say that most of your end users want almost
> nothing to do with the network?
>

Yes.


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

Again, yes.


> We have also found that by giving the users a floating ip address that can
> be moved between vm's (but still constrained within a "network" zone) we
> can solve almost all of our users asks.  Typically, the internal need for a
> floating ip is when a compute resource needs to talk to another protected
> internal or external resource. Where it is painful (read: slow) to have the
> acl's on that protected resource updated. The external need is from our
> hosting customers who have a domain name (or many) tied to an IP address
> and changing IP's/DNS is particularly painful.
>

Our use of floating IPs has been described as "overloaded" in other
discussions, and I think that's accurate. Our users use floating IPs both
as a way to move a common IP from one compute resource to another and as a
way to attach to a publicly accessible network for direct access.


> Since the vast majority of our end users don't care about any of the
> technical network stuff, we spend a large amount of time/effort in
> abstracting
> or hiding the technical stuff from the users view. Which has lead to a
> number of patches that we carry on both nova and neutron (and are available
> on our public github).
>

This is the primary reason we continue to use nova-network. I'm only
mentioning that to describe our implemented solution and not an attempt
start a Neutron v nova-network debate. We're not opposed to Neutron.


> At the same time we also have a *very* small subset of (internal) users
> who are at the exact opposite end of the scale.  They care very much about
> the network details, possibly all the way down to that they want to boot a
> vm to a specific HV, with a specific IP address on a specific network
> segment.  The difference however, is that these users are completely aware
> of the topology of the network and know which HV's map to which network
> segments and are essentially trying to make a very specific ask for
> scheduling.
>

We see the same thing. We will set up separate, smaller cloud environments
where the focus is on the network and not compute. To date, these clouds
have been lab environments. I'm not sure what we would do if we had users
who wanted "advanced" network features in our compute-focused clouds.

Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150522/6d9f5d25/attachment.html>