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