[DE227]: [keystone][nova] What is the purpose of the 'nova' network?

[odyssey4me]

It seems that the 'nova' network is only used in the following places:

default["keystone"]["services"]["admin-api"]["network"] = "nova" default["nova"]["services"]["xvpvnc-proxy"]["network"] = "nova" default["nova"]["services"]["novnc-proxy"]["network"] = "nova" default["nova"]["services"]["novnc-server"]["network"] = "nova" default["quantum"]["ovs"]["network"]="nova"

Everything else that's internal is on the "management" network, whereas end-user facing services are on the "public" network.

I see that the ["keystone"]["services"]["admin-api"]["network"] also doesn't match the ["ha"]["available_services"]["keystone-admin-api"]["vip_network"]. Is this a bug in the keystone cookbook or in the openstack-ha cookbook?

Why would the keystone admin-api and the vnc services share a network? Is the "nova" network just legacy?

My thinking is that the references to the "nova" network should be changed to the "management" network and the "nova" network references should be removed entirely.

[DavidWittman]

I'm curious about this as well. I'll ask around.

[odyssey4me]

Personally I think that the naming of the networks is a little confusing. In our deployment we've come down to the following:

1. 'management' network - the network to be used as the primary interface for all hosts... this is primarily an out of band network for SSH, etc and should have as little as possible automation affecting it so that if something gets broken, this network interface can be used to recover.
2. 'api' network - the network where all openstack api's run on and communicate through. this is essentially a combination of the current 'nova' and 'public' networks. Ideally this network should be on something high speed as glance pulls images on this network.
3. 'gre' network - this is the interface where the gre tunnels go through in the quantum world. Perhaps a different name would apply for a generic scenario, but essentially this is the network where all instances communicate on.
4. 'san' network - this is where all SAN traffic and management of storage runs. cinder-volume, for instance, needs access on this network to communicate to the storage management system's API's.
5. 'public' network - this is where the external load balancing IP's are bound for access to endpoints - horizon and the api PublicURL's only. No internal services should need to communicate to this interface as they should all be using endpoints on the API network.
6. 'provider' networks - there are multiple provider networks, but this is essentially a trunked interface that services them.

It'd be great if we could define the purpose of the networks in the cookbooks, do whatever refactoring is required to bring everything in line with those definitions, then work with that common reference from there on.

[jameswthorne]

Some additional info on what service ties to what osops network:

management

Found using grep -r '\["network"\] = "management"' /root/chef-cookbooks.

graphite-statsd graphite-carbon-line-receiver graphite-carbon-pickle-receiver graphite-carbon-cache-query

memcached

collectd

mysql

keystone-internal-api

glance-admin-api glance-internal-api

nova-internal-api nova-admin-api

cinder-internal-api cinder-admin-api cinder-volume

ceilometer-internal-api ceilometer-admin-api ceilometer-central

nova

Found using grep -r '\["network"\] = "nova"' /root/chef-cookbooks.

keystone-admin-api

nova-xvpvnc-proxy nova-novnc-proxy nova-novnc-server

public

Found using grep -r '\["network"\] = "public"' /root/chef-cookbooks.

graphite-api

keystone-service-api

glance-api glance-registry

nova-api nova-ec2-admin nova-ec2-public nova-volume

quantum-api

cinder-api

ceilometer-api

horizon-dash horizon-dash_ssl

[jcannava]

We will have new documents release tomorrow that will describe the networks and what they are used for. Closing for now.