During RMA ZTP for a site, the site activation is stuck with commit error for a second site. This is a rare scenario for site activation in CSO.

Task: site-activation
May 17, 2023, 8:10:53 AM Site activation rpc called for device <uuid>
May 17, 2023, 8:11:42 AM Site activation rpc completed successfully in RM
May 17, 2023, 8:11:49 AM Task started
May 17, 2023, 8:16:08 AM Deploy configs on the devices (this may take some time) ...
May 17, 2023, 8:16:58 AM
May 17, 2023, 8:16:58 AM JNPR1111-spoke03: config-deploy SUCCESS
May 17, 2023, 8:18:15 AM Phub-01: config-deploy SUCCESS
May 17, 2023, 8:18:15 AM JNPR1111-spoke25: config-deploy FAILED - config COMMIT ERROR
May 17, 2023, 8:18:15 AM Phub-02: config-deploy SUCCESS
May 17, 2023, 8:18:15 AM
May 17, 2023, 8:18:16 AM Task complete
May 17, 2023, 8:18:16 AM site activation failed : Site-activate workflow for site <> having ems-device-id <> with job-id: <>

As per design, the task step: Site-activation consists of major aspects of committing correct config on:

1. Spoke being activated 
2. Phubs Spoke is connected towards.

As indicated above, CSO is trying to commit some configuration on a Spoke25 other than the above 2 expected by design. 
Upon investigation of the above state, the history and jobs performed on spoke25 was understood as the following:

1. Upon onboarding, spoke03 had a Pre-Compute DVPN with spoke25. However, the above DVPN never got configured.
2. The user made some changes on WAN configured in CSO connected to spoke25 manually.
3. CSO in its database still contains DVPN config related to the WAN which customer modified.
4. The above led CSO to try and push the config for DVPN which is in its database but the peer spoke has inconsistent WAN config due to manual changes. 
5. Hence, Juniper never recommends to make any manual changes to the spokes onboarded by CSO.

When stuck in such a state, there are 2 options:

1. Re-Onboard the spoke25 which had manual changes 
2. Consult Juniper by opening a JTAC case.

2023-07-31: Initial publication