You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Scenario: deployment of a network service on a newly created tenant (without private networks available)
At first attempt the NFVO tries to create the private network and respective router. However, there are no floating IPs available, thus the NSR is not created.
After this operation, a new private network exists, but no router.
After allocating floating IPs to the tenant, a new NSD deployment is triggered. Since network already exists, NFVO does not try to create it. But deployment fails as the network is not associated to any external one (since no router was created) and floating IPs can't be allocated.
Opening it here, but I think it is an issue on the NFVO which does not clean correctly in case of failure
The text was updated successfully, but these errors were encountered:
@gc4rella
Is the desired behavior be that if any step of the network creation (i.e. creating the subnet, creating the router, connecting to the router) fails should whatever is created of the router, network and subnet be deleted?
Also how should we handle when a subnet is being added during a network update? Do we just ignore the error then? Or try to undo the update? Delete the entire network?
Scenario: deployment of a network service on a newly created tenant (without private networks available)
At first attempt the NFVO tries to create the private network and respective router. However, there are no floating IPs available, thus the NSR is not created.
After this operation, a new private network exists, but no router.
After allocating floating IPs to the tenant, a new NSD deployment is triggered. Since network already exists, NFVO does not try to create it. But deployment fails as the network is not associated to any external one (since no router was created) and floating IPs can't be allocated.
Opening it here, but I think it is an issue on the NFVO which does not clean correctly in case of failure
The text was updated successfully, but these errors were encountered: