Open Stack

Hi Kris,

Apologies in advance for questions that are probably really dumb - but 
there are several points here that I don't understand.

On 17/06/15 03:44, Kris G. Lindgren wrote:
> We are doing pretty much the same thing - but in a slightly different way.
>   We extended the nova scheduler to help choose networks (IE. don't put
> vm's on a network/host that doesn't have any available IP address).

Why would a particular network/host not have any available IP address?

> Then,
> we add into the host-aggregate that each HV is attached to a network
> metadata item which maps to the names of the neutron networks that host
> supports.  This basically creates the mapping of which host supports what
> networks, so we can correctly filter hosts out during scheduling. We do
> allow people to choose a network if they wish and we do have the neutron
> end-point exposed. However, by default if they do not supply a boot
> command with a network, we will filter the networks down and choose one
> for them.  That way they never hit [1].  This also works well for us,
> because the default UI that we provide our end-users is not horizon.

Why do you define multiple networks - as opposed to just one - and why 
would one of your users want to choose a particular one of those?

(Do you mean multiple as in public-1, public-2, ...; or multiple as in 
public, service, ...?)

> We currently only support one network per HV via this configuration, but
> we would like to be able to expose a network "type" or "group" via neutron
> in the future.
>
> I believe what you described below is also another way of phrasing the ask
> that we had in [2].  That you want to define multiple "top level" networks
> in neutron: 'public' and 'service'.  That is made up by multiple desperate

desperate? :-)  I assume you probably meant "separate" here.

> L2 networks: 'public-1', 'public2,' ect which are independently
> constrained to a specific set of hosts/switches/datacenter.

If I'm understanding correctly, this is one of those places where I get 
confused about the difference between Neutron-as-an-API and 
Neutron-as-a-software-implementation.  I guess what you mean here is 
that your deployment hardware is really providing those L2 segments 
directly, and hence you aren't using Neutron's software-based simulation 
of L2 segments.  Is that right?

> We have talked about working around this under our configuration one of
> two ways.  First, is to use availability zones to provide the separation
> between: 'public' and 'service', or in our case: 'prod', 'pki','internal',
> ect, ect.

Why are availability zones involved here?  Assuming you had 'prod', 
'pki','internal' etc. networks set up and represented as such in 
Neutron, why wouldn't you just say which of those networks each instance 
should connect to, when creating each instance?

Regards,
	Neil