Make Neutron physnet set generated automatically

https://blueprints.launchpad.net/fuel/+spec/dyn-gen-physnet-set

Last time too many people interested two question:

• How to make “provider networks” by fuel?
• How to make multiple external (floating) networks?

Unfortunately Fuel does not support out of box such features.

Problem description

Now we have a bush of non-optimal technical solutions in the Fuel library:

• Order and amount of physnets for Neutron are hardcoded in the fuel-library code.
• For floating network is used old, deprecated in the next release, method of plug-in.

Combination of this leads to the following inconvienences:

• End-user can’t create additional floating network by standart manners without re-creating existing external network and router and modifying plugin.ini on all controllers.
• Plugin-writers has no ability to add additional physnets.
• Ml2 plugin has configuration, looks like deprecated

Proposed changes

• Nailgun should make more-specifc description of physnets
• Floating network should be attached through integration bridge (as private network now)
• Parameters, like bridge_mappings, physical_network_mtus, network_vlan_ranges should be generated by puppet parser functions from quantum_settings/L2/phys_nets, network scheme, and node-type

Fuel Library

There are 3 parser functions should be written:

• generate_bridge_mappings(neutron_config, network_scheme, flags)
• generate_physnet_mtus(neutron_config, network_scheme, flags)
• generate_physnet_vlan_ranges(neutron_config, network_scheme, flags)

These functions should be used while call ML2-plugin and OVS-agent configuration classes. Parameter ‘flags’ is needed for adding an ability to disable some physnets. By default ‘flags’ field looks like:

flags = {
  do_floating => true,
  do_tenant   => true,
  do_provider => false,
}

Example of usage: Neutron config on compute node, if DVR is chosen, should contain external (floating) physnet in the mappings. However if DVR is not chosen, this physnet shouldn’t be present in config file.

These functions should return:

• generate_bridge_mappings:

  list of strings 'physnet_name:bridge_name', like
  ['physnet1:br-floating', 'physnet2:br-prv']
  

• generate_physnet_mtus:

  list of strings 'physnet_name:mtu_value', like
  ['physnet1:1500', 'physnet2:9000']
  

• generate_physnet_vlan_ranges:

  list of strings 'physnet_name:start_of_range:end_of_range', like
  ['physnet1', 'physnet2:100:300']
  (ranges should be ommited for flat physnets)
  

Plugins

Plugin developers got ability to override standart physnet list. No backward incompatible changes planned.

Web UI

None

Nailgun

Currently Nailgun pass to nodes following data hash (only valuable parameters shown):

quantum_settings:
  L2:
    phys_nets:
      physnet2:
        bridge: br-prv
        vlan_range: 1000:1030
  predefined_networks:
    net04_ext:
      L2:
        network_type: local
        physnet:

New data from the same configuration should be:

quantum_settings:
  L2:
    phys_nets:
      physnet1:
        bridge: br-floating
      physnet2:
        bridge: br-prv
        vlan_range: 1000:1030
  predefined_networks:
    net04_ext:
      L2:
        network_type: flat
        physnet: physnet1

Data model

None

REST API

None

Orchestration

RPC Protocol

None

Fuel Client

None

Alternatives

Do nothing. Leave post-deployment physnet configuration as hell.

Upgrade impact

None

Security impact

None

Notifications impact

None

End user impact

None

Performance impact

None

Deployment impact

None

Developer impact

None

Infrastructure impact

None

Documentation impact

None

Expected OSCI impact

None

Implementation

None

Work Items

• simple patch for Nailgun for generating propper physnets hash
• patch ml2-plugin, l3-agent and network creating granulas (puppet manifests) in osnailyfacter module
• modify NOOP-tests

Assignee(s)

Feature Lead: Sergey Vasilenko

Mandatory reviewers: Igor Zinovik, Sergey Kolekonov, Sergey Vasilenko

Developers: Bulat Gaifullin, Stas Makar

QA: Anastasiia Urlapova, PI team, Neutron team

Dependencies

None

Testing, QA

No changes for base cases. All existing tests should be used. Noop-tests should be written additionally for cases where physnet list should be extendedю

Acceptance criteria

Acceptance criteria is the same as for fuel-library ordinary bug-fixes. Standard BVT should be passed for ordinary configurations

References

1. LP blueprint https://blueprints.launchpad.net/fuel/+spec/dyn-gen-physnet-set
2. Description of new plug-in style for floating networks http://www.marcoberube.com/archives/248