openstack/fuel-specs
Code Issues Proposed changes

Fix appearance and sync with latest changes

Browse Source 
Change-Id: I06c931ece562137a1cd08d799ca70c946cd6848a
Blueprint: templates-for-networking
This commit is contained in:
Aleksey Kasatkin 2015-07-27 20:26:03 +03:00
parent a1b09eaaa3
commit c268de89e4
1 changed files with 92 additions and 66 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

158
specs/7.0/networking-templates.rst
View File

@ -41,61 +41,65 @@ Proposed change
===============
Template solution is proposed to provide the following capabilities:
* Ability to create additional networks and delete networks (new API handlers
to be added to support this).
to be added to support this).
* Have a specific set of network roles.
* Ability to create network only in case relevant node role is present on the
node.
node.
* Ability to provide custom networking topologies (e.g. subinterface bonding).
Template solution details:
* REST API handler is added to load/cancel template for given environment
(/clusters/x/network_configuration/template/).
(/clusters/x/network_configuration/template/).
* Template is applied during serialization if it was set for the env. So,
template can be loaded/reloaded any time before deployment is started and after
reset. So, it is the same behaviour as for all network settings now. Deployment
serializer for networking will be selected with regard to the fact whether
template was loaded or not.
template can be loaded/reloaded any time before deployment is started and
after reset. So, it is the same behaviour as for all network settings now.
Deployment serializer for networking will be selected with regard to the fact
whether template was loaded or not.
* Template has priority over network schema (not network addresses or node
groups) in the DB (explained better below). If it is applied then DB data
(related to network roles to networks mapping, networks to interfaces mapping
and network objects topology) is ignored by networking serializer. If it is not
applied then DB data is taken into account by networking serializer.
Serialization of other data is not affected.
groups) in the DB (explained better below). If it is applied then DB data
(related to network roles to networks mapping, networks to interfaces mapping
and network objects topology) is ignored by networking serializer. If it is
not applied then DB data is taken into account by networking serializer.
Serialization of other data is not affected.
* Astute.yaml for particular node has priority over template by default.
If yaml was uploaded for particular nodes serialized data for them will be
taken from there. Additional flag is added to node to override network part of
astute.yaml. It the flag is set then network data is taken from serializer
output regardless of template presence. Node's yaml overriding task can be
postponed due to lack of time.
If yaml was uploaded for particular nodes serialized data for them will be
taken from there. Additional flag is added to node to override network part
of astute.yaml. It the flag is set then network data is taken from serializer
output regardless of template presence. Node's yaml overriding task can be
postponed due to lack of time.
* Template allows to override network roles to networks mapping and topology
(to support complex cases which cannot be configured via API, like subinterface
bonding). Network roles' set can be not equal to core set, it is up to user.
No verification of network roles' set is provided at this stage. Network roles
to networks mapping can be set for each node role independently. Sets of
network roles and networks may be different on every particular node.
Validation should be added to ensure that all required roles are present on
every node. It's naturally done with network roles to tasks mapping but can be
postponed due to lack of time.
(to support complex cases which cannot be configured via API, like
subinterface bonding). Network roles' set can be not equal to core set, it is
up to user. No verification of network roles' set is provided at this stage.
Network roles to networks mapping can be set for each node role
independently. Sets of network roles and networks may be different on every
particular node. Validation should be added to ensure that all required roles
are present on every node. It's naturally done with network roles to tasks
mapping but can be postponed due to lack of time.
* Template allows to use distinct network schemes for different node roles and
for different node network groups. It also allows to use different NICs' sets
for particular node network groups and particular nodes.
for different node network groups. It also allows to use different NICs' sets
for particular node network groups and particular nodes.
User should be able to use specific networks for swift & cinder traffic:
* Puppet manifests should support separated network roles for these services.
* Template solution will allow to use the separation of network roles and
networks.
networks.
All the networking metadata which is now defined within networks should be
moved to network roles description:
* Every task description has section [network_roles] where the list of names of
network roles required is declared. (It's required for template validation at
least.) It can be out of first feature release as not highest priority task
which takes significant time.
network roles required is declared. (It's required for template validation at
least.) It can be out of first feature release as not highest priority task
which takes significant time.
* Descriptions of network roles are propagated to Nailgun and include metadata
which is required for serialization to orchestrator.
which is required for serialization to orchestrator.
* VIPs assignment is done using network roles metadata instead of networks
metadata. It is true for both template and general flow.
metadata. It is true for both template and general flow.
Alternatives
@ -110,19 +114,19 @@ Data model impact
Template example::
adv_net_template:
- node_group: default
default:
nic_mapping:
default:
if1: eth0
if2: eth1
if3: wlan0
if3: eth2
node-3:
if1: eth0
if2: eth1
if3: eth2
if4: eth3
if4: wlan0
network_scheme:
common: &common
common:
transformations:
- action: add-br
name: br-fw-admin
@ -137,7 +141,6 @@ Template example::
roles:
admin/pxe: br-fw-admin
neutron/api: br-mgmt
neutron/mesh: br-mgmt
mgmt/corosync: br-mgmt
mgmt/database: br-mgmt
mgmt/messaging: br-mgmt
@ -158,7 +161,7 @@ Template example::
swift/replication: br-storage
ceph/replication: br-storage
cinder/iscsi: br-storage
public: &public
public:
transformations:
- action: add-br
name: br-ex
@ -179,7 +182,7 @@ Template example::
ceph/radosgw: br-ex
swift/public: br-ex
neutron/floating: br-floating
private: &private
private:
transformations:
- action: add-br
name: br-prv
@ -197,7 +200,6 @@ Template example::
- br-aux
roles:
neutron/private: br-prv
templates_for_node_role:
controller:
- common
@ -207,29 +209,54 @@ Template example::
- common
- private
network_assignments:
br-fw-admin:
subnet: fuelweb_admin
br-mgmt:
subnet: management
br-ex:
subnet: public
br-storage:
subnet: storage
br-mesh:
subnet: private
br-prv:
subnet: private
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:
* id - string, can be treated as name. It should be used in tasks' descriptions
for referencing network roles required for particular task. It is also used in
manifests.
* network properties - dictionary, properties which are required for underlying
network are described here, like CIDR, gateway, VIPs.
for referencing network roles required for particular task. It is also used
in manifests.
* default_mapping - string, name of the network to map this role be default
(when template is not in use).
* properties - dictionary, properties which are required for underlying network
are described here, like CIDR, gateway, VIPs.
* metadata - dictionary, it is metadata which is not related to networks,
e.g. neutron settings. It is in our DSL format. It will be shown in UI and
could be edited there. It is passed to orchestrator as is. Nailgun doesn't
process it.
e.g. neutron settings. It is in our DSL format. It will be shown in UI and
could be edited there. It is passed to orchestrator as is. Nailgun doesn't
process it. It will not be used in 7.0. So, it can be skipped for now.
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:
* name - string, it should be unique name within the environment, it cannot be
skipped.
* namespace - string, network namespace, that should be used for landing of
the VIP, will be serialized to null when skipped.
* node_roles - list, node roles where VIPs should be set up. It can be skipped.
Its value will be set to ["primary-controller", "controller"] then.
Network role descriptions are accessible for Nailgun. They are accumulated into
network_role_metadata field of Release DB table. They are used for assignment
@ -304,11 +331,12 @@ 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 "/clusters/x/network_configuration/networks/" URL to create/remove networks
for given environment.
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).
This handler will support POST/DELETE operations to create/remove networks.
Networks' configuration should be set using existing API.
All parameters and metadata can be changed for individual network via
"/networks/x/".
Upgrade impact
@ -443,8 +471,6 @@ Acceptance Criteria
* Descriptions of network roles are propagated to Nailgun and include metadata
which is required for serialization to orchestrator.
* Every task description has section [network_roles] where the list of names of
network roles required is declared.
* API handler is added to load/cancel template for given environment.
* API handler is added to create/remove networks for given environment.
* Template is applied during serialization if it was set for the env.