eos_designs will not document multiple fabrics in a play

ryanmerolle commented 3 years ago

Issue Type

[ ] Bug Report
[ ] EOS Configuration rendering error
[X] Documentation Issue Report

Summary

Though the module eos_designs will take multiple devices/fabrics as an input, and spit out relevant files for each switch/device, it will only spit out 1 Fabric document given the way in which the task is run as run_once.

I suggest an approach of getting the unique Fabric Namesin the play, and looping through those Fabric Names in a task. You might be able to somehow run against 1 member device so you could inherit all the required group_vars and host_vars if needed. That you you could introduce a standard way of defining a fabric using something like looping through all files in a fabric_vars (similar to your global_vars approach).

Component Name

arista,avd,eos_designs

Steps to reproduce

Example play: https://gitlab.com/ryanmerolle/avd-demo/-/jobs/1274317183

Expected results

TASK [arista.avd.eos_designs : Store checksum of existing fabric documentation] ***
ok: [DC1-SPINE1]
TASK [arista.avd.eos_designs : Store checksum of existing fabric documentation] ***
ok: [DC2-SPINE1]
TASK [arista.avd.eos_designs : Generate fabric documentation in Markdown Format.] ***
ok: [DC1-SPINE1]
TASK [arista.avd.eos_designs : Generate fabric documentation in Markdown Format.] ***
ok: [DC2-SPINE1]
TASK [arista.avd.eos_designs : Generate TOC for fabric documentation] **********
changed: [DC1-SPINE1]
TASK [arista.avd.eos_designs : Generate TOC for fabric documentation] **********
changed: [DC2-SPINE1]
TASK [arista.avd.eos_designs : Generate fabric point-to-point links summary in csv format.] ***
changed: [DC1-SPINE1]
TASK [arista.avd.eos_designs : Generate fabric point-to-point links summary in csv format.] ***
changed: [DC2-SPINE1]
TASK [arista.avd.eos_designs : Generate fabric topology in csv format.] ********
changed: [DC1-SPINE1]
TASK [arista.avd.eos_designs : Generate fabric topology in csv format.] ********
changed: [DC2-SPINE1]

Actual results

TASK [arista.avd.eos_designs : Store checksum of existing fabric documentation] ***
ok: [DC1-SPINE1]
TASK [arista.avd.eos_designs : Generate fabric documentation in Markdown Format.] ***
ok: [DC1-SPINE1]
TASK [arista.avd.eos_designs : Generate TOC for fabric documentation] **********
changed: [DC1-SPINE1]
TASK [arista.avd.eos_designs : Generate fabric point-to-point links summary in csv format.] ***
changed: [DC1-SPINE1]
TASK [arista.avd.eos_designs : Generate fabric topology in csv format.] ********
changed: [DC1-SPINE1]

ryanmerolle commented 3 years ago

I was thinking about how to approach this in a way that does not break existing deployments and should work no matter if someone passes a separate inventory per fabric, leverages SoT like NetBox, or passes one single multi-fabric ansible inventory.

group_by would allow the role to not have to know what group the fabric_name var is tied to. You could build groups based on these values. To limit the number of hosts in these groups, you could limit to only where type=="spine" since all fabrics need atleast 1 spine.
Build a list which includes the first host in each newly created group_by list
Run a task where inventory_hostname is in the first host list from step 2.

carlbuchmann commented 3 years ago

@ryanmerolle - This is supported to and likely that you need to update the required hierarchy naming. ->fabric (all interconnected devices and should only be one name) ----> dc_name (think of this as the physical location) --------> pod_name see documentation see documentation: https://avd.sh/en/latest/roles/eos_designs/doc/l3ls-evpn/fabric-topology/

See sample output of fabric documentation for multi-dc topology-> https://github.com/aristanetworks/ansible-avd/blob/devel/ansible_collections/arista/avd/molecule/eos_designs-twodc-5stage-clos/documentation/fabric/TWODC_5STAGE_CLOS-documentation.md

ryanmerolle commented 3 years ago

All I did was fork https://github.com/arista-netdevops-community/ipspace-webinar-september15-2020 and combine inventories given netbox will feed a of this data for me off the bat.

It sounds like in the repo I forked, fabric_name, given the current version of AVD could have used one fabric_name and different dc_names.

I read that documentation, and though dc_name did not explicitly say this is only for 5-stage CLOS, I for some reason understood it as such.

Here are my notes:

A "fabric" of closely related elements where you extend VXLAN... in your case you may have multiple "fabrics" (direct from @carlbuchmann via slack)
Documentation for the repo is pretty good, but full working examples are not really available for the showing off the most recent approach with the latest AVD version
Currently better documentation could be output for DCs/pods/sites, and maybe even output per DC/pod/site. Fabric documentation will not allow for multiple fabric_names in 1 play (You may want to fix that given users may not follow that).
You recommend a single play per fabric which I do not love, because I rather my automation run for any new site automatically if the site is tagged in netbox as l3clos. Ideally a fabric would be tied to the site or sub-region where fabric extends beyond a single site.

github-actions[bot] commented 3 years ago

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 15 days

ryanmerolle commented 3 years ago

This is likely still valid to investigate

github-actions[bot] commented 2 years ago

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 15 days

ryanmerolle commented 1 year ago

Should this be reopened?

aristanetworks / avd