control-service: add enabled flag of deployments to the database #421
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently, the enabled status of data job deployments is inferred from their respective cronjob in Kubernetes. This has multiple implications, including the fact that when we need to know whether a deployment is enabled, we need to query the Kubernetes API. It is also strange to not have the complete state of the data jobs in the database and instead rely for this on Kubernetes. This commit is a small step towards moving the deployment state entirely in the database by adding the enabled status of deployments (currently in the data_job table, but subsequently in a separate table dedicated to deployments). Testing done: Manually tested the change by first starting the service with the new Flyway script and observing that the new column is added to the data_job table. Validated that the existing jobs have true as a value of the newly added column. Then, created, and deployed a new job. Finally disabled, enabled, and deleted the deployment and verified that the enabled value changed accordingly. Also, extended the unit tests to verify that the enabled flag is persisted when it should. Signed-off-by: Tsvetomir Palashki <[email protected]>
mivanov1988
reviewed
Oct 19, 2021
...s/pipelines_control_service/src/main/resources/db/migration/V20213109120000__add_enabled.sql
Outdated
Show resolved
Hide resolved
mivanov1988
reviewed
Oct 19, 2021
...ojects/pipelines_control_service/src/main/java/com/vmware/taurus/service/JobsRepository.java
Show resolved
Hide resolved
mivanov1988
reviewed
Oct 19, 2021
...ojects/pipelines_control_service/src/main/java/com/vmware/taurus/service/JobsRepository.java
Show resolved
Hide resolved
Signed-off-by: Tsvetomir Palashki <[email protected]>
tpalashki
force-pushed
the
person/tpalashki/control-service
branch
from
e93da4f to
eb4325a
Compare
|
Please add unit test for |
mivanov1988
approved these changes
Oct 20, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, the enabled status of data job deployments is inferred from
their respective cronjob in Kubernetes. This has multiple implications,
including the fact that when we need to know whether a deployment
is enabled, we need to query the Kubernetes API. It is also strange
to not have the complete state of the data jobs in the database and
instead rely for this on Kubernetes.
This commit is a small step towards moving the deployment state entirely
in the database by adding the enabled status of deployments (currently
in the data_job table, but subsequently in a separate table dedicated
to deployments).
Testing done: Manually tested the change by first starting the service
with the new Flyway script and observing that the new column is added
to the data_job table. Validated that the existing jobs have true as
a value of the newly added column. Then, created, and deployed a new job.
Finally disabled, enabled, and deleted the deployment and verified
that the enabled value changed accordingly.
Also, extended the unit tests to verify that the enabled flag is
persisted when it should.
Signed-off-by: Tsvetomir Palashki [email protected]