fix: enable resource config & remove unnecessary configs from helm-charts

[florianrusch-zf]

WHAT

• Enabling default resource configuration in helm charts
• Removing unnecessary configurations from helm charts
• Improve documentations

WHY

To fulfil TRG 5.04 and to avoid confusions

FURTHER NOTES

Closes #1274

[paullatzelsperger]

all good, apart from one rogue "x"

[paullatzelsperger]

We cannot change the test value files yet, otherwise the upgradeability test will fail: we install the old (0.5.4) version first, and then do a helm upgrade, and for that version we still need the values.

Once we have released 0.7.1 we can remove those values, because then, the upgradeability check will be 0.7.0 -> 0.7.1.

[saschaisele-zf]

Looks good and can be merged after the release of 0.7.1

[florianrusch-zf]

Fine for me! And thanks for the review :-)

@paullatzelsperger Regarding the upgradability check: This check only checks whether the EDC starts successfully after changing the helm chart version, right? I guess it doesn't check if all necessary database migrations are in place, or? Of course, if the migration fails, the pod will not start successfully - but in the past there have been missing migrations that basically resulted in a corrupted database after the upgrade.

related feature: #670

[wolf4ood]

Hi Folks can we merge this?

[florianrusch-zf]

Nope, I've just seen that some of the documentation is also incorrect in the helm chart. I will add a correction to this PR in the near future.

[paullatzelsperger]

@paullatzelsperger Regarding the upgradability check: This check only checks whether the EDC starts successfully after changing the helm chart version, right? I guess it doesn't check if all necessary database migrations are in place, or? Of course, if the migration fails, the pod will not start successfully - but in the past there have been missing migrations that basically resulted in a corrupted database after the upgrade.

correct: those upgradeability checks only perform a smoke-test to satisfy TRG 5.11. The only way to be 100% certain that nothing is broken database-wise is to hit every table of the database with a request. We have no plans currently to do that.

Apart from that, I would expect any serious production deployment of EDC to provide their own migration system, as a simple "update-on-startup" may not be sophisticated enough.

[github-actions]

This pull request is stale because it has been open for 7 days with no activity.

[github-actions]

This pull request is stale because it has been open for 7 days with no activity.

[paullatzelsperger]

@florianrusch-zf I think you gotta rebase

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud