Currently, the Google OAuth manager is installed in the service-catalog namespace along with the core Service Catalog resources. This makes the case where users want to install Service Catalog themselves but still use our tool to manage the GCP broker, as we can't make assumptions about what is stored in service-catalog and whether we're able to delete them.
This PR:
1) Moves the auth manager to a new google-oauth namespace, so that we can definitively deal with these resources
2) Will only attempt to delete resources if they are not present
3) Adds deletion logic for the now-deprecated oauth resources in the service-catalog namespace
I tested with the following combinations of actions, and all worked as expected (old == old version of sc, new == version including these changes):
ADDED with OLD, REMOVE with NEW
ADDED with NEW, REMOVE with NEW
ADDED with OLD, ADDED with NEW (idempotent), REMOVE with NEW
ADD with NEW to custom-installed service catalog, REMOVE with NEW from custom-installed service catalog
Currently, the Google OAuth manager is installed in the
service-catalognamespace along with the core Service Catalog resources. This makes the case where users want to install Service Catalog themselves but still use our tool to manage the GCP broker, as we can't make assumptions about what is stored inservice-catalogand whether we're able to delete them.This PR: 1) Moves the auth manager to a new
google-oauthnamespace, so that we can definitively deal with these resources 2) Will only attempt to delete resources if they are not present 3) Adds deletion logic for the now-deprecated oauth resources in theservice-catalognamespaceI tested with the following combinations of actions, and all worked as expected (old == old version of sc, new == version including these changes):
fixes: #143