Closed grybak-arista closed 3 years ago
@grybak-arista that page is only for the vATDs and not standard ATDs. This is expected behavior.
It does not run since there is not an app:
parameter in ACCESS_INFO.yaml. Which is required to run that application.
@networkRob The issue we are seeing in the Datacenter-nocvp.yml topology is affecting vATD. When we allow our cache pool to deploy the -nocvp topology it is unreachable from the vATD frontend. When we manually access the page by entering the expected address in a browser, it returns the 502 error.
At the moment, we are using the Datacenter.yml topology for all deployments for the vATD pool, though we do not need the CVP host. So testing from the vATD frontend is giving a false success because it is not actually using the -nocvp topology right now.
Since vATD is going live very soon, we need to try to get this worked out as soon as possible.
As an aside but in reference to the -nocvp topology, I would suggest changing the topology name in Datacenter-nocvp.yml to distinguish it from the Datacenter.yml topology name. Something like datacenter-latest-nocvp
should be fine.
@grybak-arista Based on this log you provided:
● labModule.service - Creates a new lab UI for modules
Loaded: loaded (/lib/systemd/system/labModule.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Thu 2020-11-12 22:57:57 UTC; 7min ago
Process: 4541 ExecStart=/usr/local/bin/labModule.py (code=exited, status=0/SUCCESS)
Nov 12 22:57:57 ip-10-33-6-59 systemd[1]: Starting Creates a new lab UI for modules...
Nov 12 22:57:57 ip-10-33-6-59 /labModule.py[4541]: [OK] Starting...
Nov 12 22:57:57 ip-10-33-6-59 /labModule.py[4541]: [OK] The default_lab parameter was not found in ACCESS_INFO.yaml, exiting...
Nov 12 22:57:57 ip-10-33-6-59 systemd[1]: Started Creates a new lab UI for modules.
The deployment server is not providing the app: <lab_type>
parameter, ie app: ucn-mlag
This parameter is needed to have labModule
run successfully which configure all the EOS nodes in place of CVP if it is not present in the topology. Also if the app:
parameter is there, then it will start the labUI
application, which is the endpoint application for http://<fqdn_or_ip>/module?lab=<lab_module>
Do you have an active topo for me to investigate with?
Performed a test on a standard datacenter-latest topology and performed the following actions:
ACCESS_INFO.yaml
ACCESS_INFO.yaml
app: ucn-mlag
Everything worked as expected.
Running some more tests on my side just to make sure.
We had to do some extra parsing due to the shared topology_name in the two topologies. When I tried simply changing the topology_name in the -nocvp version, the 502 error shows up. I guess there must be something in the scripts that is looking for datacenter-latest
, and datacenter-latest-nocvp
throws it off.
Added some extra handling code in the lab pool code to make sure the nocvp version is used when the lab is a UCN lab. Leaving the nocvp topology_version as datacenter-latest
for now.
Going to close this issue since it seems to be working with the changes to the lab pool.
Since datacenter-latest
topologies with CVP and without CVP leverage the same content, they both target the topologies/datacenter-latest
directory and content. This reduces the overhead on our end.
Describe the bug The topologies/datacenter-latest/Datacenter-nocvp.yml topology does not complete the ATD post-deployment setup process. Accessing the lab module page results in a
502 Bad Gateway
error.To Reproduce
Expected behavior Expected to see the normal UCN lab module landing page.
Screenshots
Additional context This issue is relevant to the upcoming vATD live public release, as the current setup deploys topologies/datacenter-latest/Datacenter.yml, which deploys an unused CVP node, in order to allow the UCN labs to run. To reduce cost, we would like to not have to deploy the CVP node for the UCN labs.
From the information provided below, this appears to be an issue with the ATD services on startup. The cloud-deploy process is completing successfully, and the nodes are all reachable by CLI directly. Just the lab landing pages are returning the error. The sslUpdater and labModule services seem to be reporting a problem.
Logging in to the jump host and checking the status of the ATD services yields the following output: