re-factor lib/networking

[hjensas]

When trying to re-use this for a DT I had to duplicate everything in lib/networking because the netconfig requires values for an external network.

I think splitting to separate subdirectories/kustomization files in lib/networking will allow me to re-use the metallb and nad bits.

[fultonj]

Thank you @hjensas

In general I think this is good so that the lib directory is more usable. I understand you need this so that you can still use the common nad and metallb directories while adding an IPv6 controlplane with Ironic (PR 168). I'd like to merge this after we are sure it will not break anything.

A few questions:

• With this patch kustomize build control-plane in architecture/examples/va/hci produces networks with CamelCase names (e.g. InternalApi) while prior to this patch they were all lower case (e.g. internalapi). Is this intentional?

• @Jaganathancse do you see any issues with this that might affect VA2?

I did some quick testing of this PR and saw that the kustomize build commands as described in the VA1 readme and it seemed to produce the correct CRs. However, I think we need to see results of a fully automated VA1 deployment triggered by something like this:

ansible-playbook reproducer.yml \
    -i custom/inventory.yml \
    -e cifmw_target_host=hypervisor-1 \
    -e @scenarios/reproducers/va-hci.yml \
    -e @scenarios/reproducers/networking-definition.yml \
    -e @custom/secrets.yml \
    -e @custom/default-vars.yaml \
    [-e @custom/hci.yaml] \
    -e cifmw_deploy_architecture=true

[hjensas]

A few questions:

* With this patch `kustomize build control-plane` in `architecture/examples/va/hci` produces networks with CamelCase names (e.g. InternalApi) while prior to this patch they were all lower case (e.g. internalapi). Is this intentional?

This was not intentional - I moved this to Draft. I will look into why that changed.

[Jaganathancse]

Thank you @hjensas

In general I think this is good so that the lib directory is more usable. I understand you need this so that you can still use the common nad and metallb directories while adding an IPv6 controlplane with Ironic (PR 168). I'd like to merge this after we are sure it will not break anything.

A few questions:

• With this patch kustomize build control-plane in architecture/examples/va/hci produces networks with CamelCase names (e.g. InternalApi) while prior to this patch they were all lower case (e.g. internalapi). Is this intentional?
• @Jaganathancse do you see any issues with this that might affect VA2?
  @fultonj Looks like fine only code refactoring, will also try this PR locally and confirm it.

I did some quick testing of this PR and saw that the kustomize build commands as described in the VA1 readme and it seemed to produce the correct CRs. However, I think we need to see results of a fully automated VA1 deployment triggered by something like this:

ansible-playbook reproducer.yml \
    -i custom/inventory.yml \
    -e cifmw_target_host=hypervisor-1 \
    -e @scenarios/reproducers/va-hci.yml \
    -e @scenarios/reproducers/networking-definition.yml \
    -e @custom/secrets.yml \
    -e @custom/default-vars.yaml \
    [-e @custom/hci.yaml] \
    -e cifmw_deploy_architecture=true

[hjensas]

A few questions:

* With this patch `kustomize build control-plane` in `architecture/examples/va/hci` produces networks with CamelCase names (e.g. InternalApi) while prior to this patch they were all lower case (e.g. internalapi). Is this intentional?

This was not intentional - I moved this to Draft. I will look into why that changed.

So I tried locally - and I get the same result with/without the patch:

$ git branch 
* main
  re-stucture-lib-networking
$ kustomize build control-plane > pre-lib-refactor-control-plane.yaml
$ git checkout re-stucture-lib-networking 
Switched to branch 're-stucture-lib-networking'
Your branch is up to date with 'origin/re-stucture-lib-networking'.
$ kustomize build control-plane > post-lib-refactor-control-plane.yaml
 diff -s pre-lib-refactor-control-plane.yaml post-lib-refactor-control-plane.yaml
Files pre-lib-refactor-control-plane.yaml and post-lib-refactor-control-plane.yaml are identical

[abays]

Tested in a fully-automated VA1 deployment and it succeeded

/lgtm