Issue
This is related to an effort to address: #38
The issue here is specific to some SCC implementation details for "System Credentials". The SCC backend changes have been put in place already and per my understanding we should already potentially see reduction of new duplicates 🤞 . This change will not address existing duplicates.
Eventually as a follow up to the backend change the SCC Client library will be updated and our team will need to match that change. With that in mind we will be blocked until a new connect-ng library is released. When the new version is ready we will just essentially need to update and use the new configs for "no system token mode". And then also would expect that we will no longer need "system token" related code in the SCC Operator and on the credentials secret we store.
Proposed Fix
The SCC fix is already implemented meaning the SCC backend handles tokens different based on it being a Rancher product. This means technically we can still send a token and it never should matter - so making no change for 2.13.1 is a valid result here. Alternatively, if the connect-ng library allows it we can disable token sending via config of the client connection.
We don't want to fully remove the ability to store and use Tokens as part of SCC Credentials. Eventually we may re-add the token mechanic to the SCC Operator so removing it completely would affect that effort later. Additionally the connect-ng library owns the interface/struct so we can't exactly remove it totally anyway.
Issue
This is related to an effort to address: #38
The issue here is specific to some SCC implementation details for "System Credentials". The SCC backend changes have been put in place already and per my understanding we should already potentially see reduction of new duplicates 🤞 . This change will not address existing duplicates.
Eventually as a follow up to the backend change the SCC Client library will be updated and our team will need to match that change. With that in mind we will be blocked until a new
connect-nglibrary is released. When the new version is ready we will just essentially need to update and use the new configs for "no system token mode". And then also would expect that we will no longer need "system token" related code in the SCC Operator and on the credentials secret we store.Proposed Fix
The SCC fix is already implemented meaning the SCC backend handles tokens different based on it being a Rancher product. This means technically we can still send a token and it never should matter - so making no change for 2.13.1 is a valid result here. Alternatively, if the
connect-nglibrary allows it we can disable token sending via config of the client connection.We don't want to fully remove the ability to store and use Tokens as part of SCC Credentials. Eventually we may re-add the token mechanic to the SCC Operator so removing it completely would affect that effort later. Additionally the
connect-nglibrary owns the interface/struct so we can't exactly remove it totally anyway.