Proposed refactor of neutron_networks config entry

[msherman64]

Hi all,

I wanted to propose a change to how we define neutron physnets as well as the "default" networks created during post-deploy, specifically public, sharednet1, and ironic-provisioning

Currently, neutron_networks conflates neutron physical networks and logical networks, making it difficult to, for example, put public and sharednet1 onto the same physnet, or change them between flat or vlan type networks.

Therefore, I suggest the following new syntax, where:

• Configuration of physnets doesn't change, each list entry under neutron_networks has its properties used to populate neutron's ml2_conf.ini and openvswitch_agent.ini, mapping physnets to ovs bridges to external interfaces
  • however, we deprecate use of the top level keys neutron_ovs_bridge_mappings and network_vlan_ranges
  • We add an "path_mtu" field, allowing the setting of MTU per physnet as in case 2 here.
• We deprecate special behavior during post-deploy for physnets that happen to be named "public" or "sharednet"
• Instead, physnets may have keys used to define a neutron network+subnet, specifically public, sharednet, and provisioning

Physnets now have a schema like:

- name: <physnet_name>
  bridge_name: <name_of_ovs_bridge>
  external_interface: <ovs_external_ethernet_interface>
  path_mtu: 9000
  on_demand_vlan_ranges:
    - 3000:3100
    - 3300:3400
  reservable_vlan_ranges:
    - 3101:3299
  public: {network_dict}
  sharednet: {network_dict}
  provisioning: {network_dict}

Where network_dict has the schema:

key(public,sharednet,provisioning):
  segment_type: (flat,vlan)
  segment_id: (int if vlan, unset if flat)
  cidr: <ip/netmask>
  gateway: <ip>
  allocation_pools:
    - start: <ip>
      end: <ip>

note on segment_id: these networks will be created as admin during post-deploy, so this need-not fall within the on_demand_vlan_ranges, and should not fall within the resevable vlan ranges.

note on post-deploy: Currently, these networks will be created, but NOT updated during post-deploy. If one of these networks is modified in defaults.yml, and post-deploy is re-run, the corresponding neutron network won't be modified.

A full example could look like:

neutron_networks:
- name: physnet1
  bridge_name: br_physnet1
  external_interface: eth_used_for_physnet1
  path_mtu: 9000
  on_demand_vlan_ranges:
    - 3000:3100
    - 3300:3400
  reservable_vlan_ranges:
    - 3101:3299
  sharednet:
    segment_type: vlan
    segment_id: 2099
    cidr: 10.200.10.0/22
  provisioning:
    segment_type: vlan
    segment_id: 2098
    cidr: 10.205.10.0/24
- name: physnet2
  bridge_name: br_physnet2
  external_interface: eth_used_for_physnet2
  path_mtu: 1500
  public:
    segment_type: flat
    cidr: 192.168.100.0/24
    gateway: 192.168.100.1
    allocation_pools:
    - start: 192.168.100.20
       end: 192.168.100.200

Alternately, the post-deploy networks could be defined in a completely separate list, and just specify the physnet_name for each network. This increases the verbosity a little, but gives us a clear separation between:

# required at deploy-time, directly templated into neutron.conf
neutron_physical_networks:
 - one
 - two

# required for post-deploy, create-only, no updates applied
post_deploy_networks:
  - public:
       physnet_name: two
  - sharednet:
       physnet_name: one
  - provisioning:
       physnet_name: one

[codyhammock]

I like the approach with networks defined within the physnet structures, since it keeps everything colocated in the code. The network definition should also include DNS server entries, should it not?