Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/498 #581

Merged
merged 4 commits into from
Oct 10, 2022
Merged

Feature/498 #581

merged 4 commits into from
Oct 10, 2022

Conversation

aranega
Copy link
Member

@aranega aranega commented Sep 19, 2022

Closes #498

Implemented solution:
The helm.py module, responsible for the helm chart generation, is modified to include a detection of unused DBs.
The __clear_unused_db_configuration contains the cleaning logic.
First, the used db is identified using the type property of the database entry of the current configuration.
All the DBs configurations are extracted relying on the fact that each DB entry always contains an image key and a ports key.
The DBs configurations that are not used in the project are deleted.

Writing tests I saw that even if I remove the entries from the helm_values during the process, some are added back by the HarnessMainConfig at the end.
This is not a problem for the deployment/values.yaml generation as the file generation is performed before the instance of HarnessMainConfig is created, but it looks weird anyway.

How to test this PR:

Some tests are integrated with the PR.
To test the PR, it is possible to generate an app for a dedicated DB and check in the values.yaml that there is no other entries.

The generation of the app:

harness-application dbtest -t db-mongo
harness-deployment cloud-harness . -i dbtest

# then check if there is well mongo in values.yaml and nothing else
grep -i mongo deployment/helm/values.yaml

# and there is not the others entries
grep -i postgres deployment/helm/values.yaml
grep -i neo4j deployment/helm/values.yaml

Sanity checks:

  • The pull request is explicitly linked to the relevant issue(s)
  • The issue is well described: clearly states the problem and the general proposed solution(s)
  • From the issue and the current PR it is explicitly stated how to test the current change
  • The labels in the issue set the scope and the type of issue (bug, feature, etc.)
  • All the automated test checks are passing
  • All the linked issues are included in one milestone
  • All the linked issues are in the Review/QA column of the board
  • All the linked issues are assigned

Breaking changes (select one):

  • The present changes do not change the preexisting api in any way
  • This PR and the issue are tagged as a breaking-change

Possible deployment updates issues (select one):

  • There is no reason why deployments based on CloudHarness may break after the current update
  • This PR and the issue are tagged as alert:deployment

Test coverage (select one):

  • Tests for the relevant cases are included in this pr
  • The changes included in this pr are out of the current test coverage scope

Documentation (select one):

  • The documentation has been updated to match the current changes
  • The changes included in this PR are out of the current documentation scope

Nice to have (if relevant):

  • Screenshots of the changes
  • Explanatory video/animated gif

Copy link
Collaborator

@filippomc filippomc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, thanks @aranega!

Including as part of the next 2.1.0 release as I'm not sure what happens the database key lookup when it's missing so need more general testing

@filippomc filippomc merged commit 8f3e237 into develop Oct 10, 2022
@filippomc filippomc deleted the feature/498 branch October 10, 2022 09:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Clean unused database properties from generated values.yaml
2 participants