sven-dmlr
commented
2 years ago I'd vote for variant B :star:
We can implement variant D later if there's need for it.
Open de-jcup opened 2 years ago
sven-dmlr
commented
2 years ago I'd vote for variant B :star:
We can implement variant D later if there's need for it.
Situation
With #1279 we introduced a possiblity to have auto cleanup. Via REST API it is possible to setup auto cleanup configuration. But ... this setup must be done for every PDS by administrators
Wanted
It shall be easy for an administrator to change the auto cleanup configuration for all PDS servers by one single action
Solution
Variant A: Auto cleanup of SecHub and active PDS servers are synchronized
Inside scan domain we listen to the change event (auto cleanup configuration) When the event arrives we fetch all active pds executor configurations, grab the URLs and trigger the auto cleanup configuration change at the PDS server side as well.
Variant B: Extra "configure autocleanup for all PDS servers" action
We provide a REST api endpoint where an administrator can set the new auto cleanup configuration for ALL active PDS servers. Will just iterate over each active PDS serer and send to REST API defined in #1279
Variant C: sechub-api.sh and DeveloperAdminUI only
Not really suitable, because sometimes (depending on Setup) no direct communication with PDS cluster/members is possible
Variant D: Extra "configure autocleanup for a list of PDS servers" action
We provide a REST api endpoint where an administrator can set the new auto cleanup configuration for a dedicated list of product executor uuids. Will just iterate over each active PDS serer and send to REST API defined in #1279 Advantage: On Web UI, we could have a table of PDS serves to configure, on sechub-api.sh and developer admin UI we could also create something similar. So admins could for example just configure some dedicated servers or keep some as is.