Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[doc] -w changed to --wrap-config-in #143

Open
wants to merge 1 commit into
base: stable/yoga-m3
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 10 additions & 10 deletions doc/source/configuration/config-gen.rst
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ Netbox Config Generator


Netbox Config Generator will fetch all devices that belong to below Netbox roles. It will then fetch all interfaces and create hostgroups from clusters that are connected to the interfaces.
The driver configuration is generated based on input from external tooling (Netbox).
The driver configuration is generated based on input from external tooling (Netbox).

A reference how the Config Generator expects Netbox objects can be found in `netbox_model.py`_

Expand All @@ -13,7 +13,7 @@ Run

The config generator is available under :code:`networking_ccloud/tools/netbox_config_gen.py` using the entrypoint :code:`cc-netbox-config-gen`.

It does support nesting the configuration under certain YAML keys if the config need to be picked up by helm. Use the :code:`--wrap-in` parameter for that.
It does support nesting the configuration under certain YAML keys if the config need to be picked up by helm. Use the :code:`--wrap-config-in` parameter for that.

Vault references can also be injected instead of plain-text passwords using the :code:`--vault-ref` parameter.

Expand All @@ -25,7 +25,7 @@ Example

::

cc-netbox-config-gen -r $OS_REGION_NAME -u MYAPIUSER -V $OS_REGION_NAME/my/vault/path -a $PYCCLOUD_SECRETS_REPO_PATH/global/values/neutron-networking-global.yaml -w cc_fabric/driver_config -o $PATH_TO_HELM_VALUES/$OS_REGION_NAME/values/neutron-cc-fabric.yaml
cc-netbox-config-gen -r $OS_REGION_NAME -u MYAPIUSER -V $OS_REGION_NAME/my/vault/path -a $PYCCLOUD_SECRETS_REPO_PATH/global/values/neutron-networking-global.yaml --wrap-config-in cc_fabric/driver_config -o $PATH_TO_HELM_VALUES/$OS_REGION_NAME/values/neutron-cc-fabric.yaml



Expand All @@ -47,7 +47,7 @@ Leaf pair hostnames must be compliant with the following regex::
^(?P<region>\w{2}-\w{2}-\d)-sw(?P<az>\d)(?P<pod>\d)(?P<switchgroup>\d{2})(?P<leaf>[ab])(?:-(?P<role>[a-z]+(?P<bb_no>[0-9]+)?))$

Or in a more readable way::

[region]-sw[az][pod][switchgroup][leaf][role]
i.e.: eu-de-1-sw4223a-bb147

Expand All @@ -67,7 +67,7 @@ Each leaf pair (MLAG/VPC) requires a fabric unique 4 digit ID ([az][pod][switchg
- a 2 digit number uniquely identifying the leaf pair in a region
* - leaf
- a=fist leaf in pair, b=second leaf in pair
* - role
* - role
- any sequence of lower case characters followed by digits as a pod identifier, such as bb147. The pod identifier is optional.

Each leaf pair (MLAG/VPC) requires a fabric unique 4 digit ID :code:`(f{az}{pod}{switchgroup})` with an a/b identifier for leaf in group per leaf pair used to generate device specific configuration settings (ASN etc.)
Expand All @@ -89,7 +89,7 @@ Any leaf connecting any CC platform equipment must be tagged with the applicable

CND EVPN Leaf Types:
.....................
The driver needs to identify certain non-pod leaf pairs to
The driver needs to identify certain non-pod leaf pairs to
push tenant configuration:

* **CND-NET-EVPN-BL**: Border leaf connecting to core routing, required for subnet pool summarization
Expand Down Expand Up @@ -142,7 +142,7 @@ If an Infrastructure Network shall be layer 3 enabled, the following conditions
* The *VLAN* object must have a prefix associated,
* the prefix must have the correct VRF assigned,
* the prefix should be subnetted from the pod-specific management supernet if applicable,
* the prefix must have a parent prefix associated which will be added as an BGP aggregate to the config.
* the prefix must have a parent prefix associated which will be added as an BGP aggregate to the config.

In addition, we expect all layer 3 Infrastructure Networks to be anycast-gateway routed. As these anycast gateways live on the TOR leaf, those must be moddeled as follows:

Expand All @@ -153,7 +153,7 @@ In addition, we expect all layer 3 Infrastructure Networks to be anycast-gateway

DHCP Relay (not implemented so far)
....................................
For infra networks requiring a DHCP relay one or more Netbox *Tags*
For infra networks requiring a DHCP relay one or more Netbox *Tags*
must be added to the *VLAN* object, one for each DHCP relay server
in the form::

Expand All @@ -172,7 +172,7 @@ Whenever an extra VLAN is required, it needs to be modelled in Netbox in order t
* There must be a *VLAN* object existing,
* the *VLAN* must be assigned to the logical port in *tagged* mode,
* the *VLAN* or its associated VLAN group must have the :code:`cc-net-driver-extra-vlan`.

As our Netbox version currently does not yet support tags on VLAN groups, we additionally consider the following VLANs as extra VLANs as long as Netbox is not upgraded:

* *VLAN group* name starts with region and ends with :code:`cp`
Expand Down Expand Up @@ -246,7 +246,7 @@ The driver will assemble all lags that are known to it in its config. Within CCl
which is not policy enforced at the moment. However the netbox modeller will generate LAG-ids based on this.

LAGs can either have ports only on one leaf or be spanned across two leaves (MLAG/vPC).
The following convention will be used to distinguish the two
The following convention will be used to distinguish the two
variants::

port-channel100 defined on device 1110a only: a regular port-channel will be configured
Expand Down
Loading