Fuel will be able to provide more flexible networking configurations via templates. Services will not be tied to networks 1:1. User will be able to create any number of networks and map them to services (i.e. network roles). User will be able to use different sets of network roles for different nodes depending on node roles’ sets for those nodes.
It is required to support both “new” and “old” networking strategies in RPC. We need to support “old” one for environments based on earlier releases and for environments configured via API.
Nova-Network is not supported for new environments, it is supported for old ones only. Multi-rack is supported with templates only.
Fuel 6.1 has a very straightforward networking configuration procedure. It’s required for environment to use 4-5 networks depending on environment configuration. Every service uses its own (predefined) network. Furthermore, most networks are configured on all environment nodes no matter are they required or not (with the exception of Public network for Fuel 5.1 and later). Topology configuration is not flexible enough (e.g. subinterface bonding cannot be used via API).
Template solution is proposed to provide the following capabilities:
Template solution details:
User should be able to use specific networks for swift & cinder traffic:
All the networking metadata which is now defined within networks should be moved to network roles description:
adv_net_template: default: nic_mapping: default: if1: eth0 if2: eth1 if3: eth2 node-3: if1: eth0 if2: eth1 if3: eth2 if4: wlan0 network_scheme: common: transformations: - action: add-br name: br-fw-admin - action: add-br name: br-mgmt - action: add-br name: br-storage endpoints: - br-mgmt - br-storage - br-fw-admin roles: admin/pxe: br-fw-admin neutron/api: br-mgmt mgmt/corosync: br-mgmt mgmt/database: br-mgmt mgmt/messaging: br-mgmt mgmt/api: br-mgmt mgmt/vip: br-mgmt nova/api: br-mgmt murano/api: br-mgmt sahara/api: br-mgmt ceilometer/api: br-mgmt heat/api: br-mgmt keystone/api: br-mgmt horizon: br-mgmt glance/api: br-mgmt ceph/public: br-mgmt swift/api: br-mgmt cinder/api: br-mgmt mongo/db: br-mgmt swift/replication: br-storage ceph/replication: br-storage cinder/iscsi: br-storage public: transformations: - action: add-br name: br-ex - action: add-br name: br-floating provider: ovs - action: add-patch bridges: - br-floating - br-ex mtu: 65000 provider: ovs endpoints: - br-ex - br-floating roles: public/vip: br-ex ceph/radosgw: br-ex swift/public: br-ex neutron/floating: br-floating private: transformations: - action: add-br name: br-prv provider: ovs - action: add-br name: br-aux - action: add-patch bridges: - br-prv - br-aux mtu: 65000 provider: ovs endpoints: - br-prv - br-aux roles: neutron/private: br-prv templates_for_node_role: controller: - common - public - private compute: - common - private network_assignments: storage: ep: br-storage private: ep: br-prv public: ep: br-ex management: ep: br-mgmt fuelweb_admin: ep: br-fw-admin
Network roles are introduced. Network role description contain:
Network role description example:
id: "mgmt/vip" default_mapping: "management" properties: subnet: true gateway: false vip: - name: "vrouter" namespace: "vrouter" - name: "management" namespace: "haproxy" node_roles: ["primary-controller", "controller"]
VIPs can be requested in network role’s description. Description of VIP includes:
Network role descriptions are accessible for Nailgun. They are accumulated into network_role_metadata field of Release DB table. They are used for assignment of VIPs at this stage. They will be used more heavily when network roles to networks mapping will be added to API.
Network roles to networks mapping can be set almost freely via templates. There is no check of network roles’ set which is defined in template at this stage. It is on user now. Network roles to networks mapping is fixed when template is not applied.
Assignment of VIPs will be changed: it will be done using network roles metadata for 7.0 environments regardless of template usage. Assignment of VIPs for pre-7.0 environments will remain the same. This duality will be solved with versioning of network manager.
There is an ability to load a template for networking configuration. It is loaded/cancelled with separate API call. When it is loaded/cancelled, networks DB objects are not changed. Networks to interfaces mapping in DB will be wrong when template is being used. It is not synchronized as template provides much more flexible scheme than DB relations can address for now. So, some checks of network configuration consistency will be disabled while working with template.
Template is loaded into ‘configuration_template’ field of ‘networking_configs’ DB table. Serialization of network configuration for deployment supports two modes: serialization according template and serialization according DB. In both cases DB will be used as source of information about networks L3 configuration and IP addresses. But there will be difference regarding network roles to networks mapping, networks to interfaces mapping, L2 topology.
IPs allocation for nodes in case of template will take in account which networks are in use on particular node.
Basic verification of template should be done while it is being loaded: nodes and node network groups listed in template must exist in DB. Verification of network roles, nodes’ interfaces, etc. is to be added later.
Proper parameters for network verification tool should be provided in case of template usage to allow network verification in this mode. It can be done using template parsing or using some additional metadata provided by user in the same template.
The following symbols will not be used in Nailgun output for orchestrator for 7.0 environments as we do not have fixed names of networks any longer: - internal_address - internal_int - internal_netmask - management_network_range - network_size - novanetwork_params - private_int - public_address - public_int - public_netmask - storage_address - storage_hash - storage_netmask - storage_network_range Network properties will be tied to network roles and/or endpoints instead. We need to write up a migration plan here, we cant drop this in a single release - TBD.
Add “/clusters/x/network_configuration/template/” URL to load/cancel template for given environment.
Template body is provided with this API call. It should be verified and loaded into DB. If validation failed DB is kept without changes. Template is cancelled if empty template body was provided with this API call. DB will be updated with empty template then.
Add “/networks/” URL to create networks and get their parameters (POST/GET). Add “/networks/x/” URL to get/set parameters of individual network and delete network (GET/PUT/DELETE).
All parameters and metadata can be changed for individual network via “/networks/x/”.
Migration of schema and data must be provided to support previously created environments and creation of environments with older releases. It should include migration of existing releases and clusters.
No additional security modifications needed.
No Nailgun/Library performance impact is expected.
Feature Lead: Aleksey Kasatkin
Mandatory Design Reviewers: Andrew Woodward, Sergey Vasilenko
Developers: Ivan Kliuk, Ryan Moe, Sergey Vasilenko, Stas Makar
QA: Alexander Kostrikov, Artem Panchenko
The documentation should describe new networking architecture of Fuel, networking templates workflow, limitations of network scheme provided by templates, a library of templates.