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

control-service: Add python_version to Control Service API #1806

Merged
merged 9 commits into from
Apr 5, 2023

Conversation

doks5
Copy link
Contributor

@doks5 doks5 commented Mar 30, 2023

As part of the effort to provide users with the ability to specify the python release version, which they want their data jobs to be deployed with, we need to expose a property in the Control Service's API and ensure that the configuration is stored in the database and the kubernetes objects.

This change exposes a python_version property in the api schemas of the DataJobDeployment and DataJobDeploymentStatus components, and propagates the property to the database model and kubernetes resources. All of this is done as one change, to avoid unexpected behaviour or regressions.

VEP for Reference: https://github.com/vmware/versatile-data-kit/tree/main/specs/vep-1739-multiple-python-versions

Testing Done: New and modified existing tests.

@doks5 doks5 self-assigned this Mar 30, 2023
@doks5 doks5 linked an issue Mar 30, 2023 that may be closed by this pull request
Copy link
Contributor

@ivakoleva ivakoleva left a comment

Choose a reason for hiding this comment

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

LGTM;
May you link to PR description for convenience, the VEP-1739 described API and use cases?

For example, having a pinned python version corresponds to an exact python version requirement. Is there a use case of applying a lower bound only, so you still get your data job automatically upgraded to latest?

@mivanov1988
Copy link
Contributor

python_version validation will be added in a separate PR, right?

@mivanov1988
Copy link
Contributor

mivanov1988 commented Mar 31, 2023

Shouldn't we return a default python version in case of empty python-version annotation?

@doks5 doks5 force-pushed the person/andonova/api-job-deployment branch from 9f5b111 to 45c1d4f Compare April 2, 2023 21:31
@doks5 doks5 linked an issue Apr 3, 2023 that may be closed by this pull request
@doks5 doks5 force-pushed the person/andonova/api-job-deployment branch from 45c1d4f to f2573cb Compare April 4, 2023 06:18
@doks5
Copy link
Contributor Author

doks5 commented Apr 4, 2023

python_version validation will be added in a separate PR, right?

Added in this PR.

@doks5
Copy link
Contributor Author

doks5 commented Apr 4, 2023

Shouldn't we return a default python version in case of empty python-version annotation?

In case of empty python-version, we set the defaultPythonVersion.

@doks5 doks5 force-pushed the person/andonova/api-job-deployment branch from 85f8c32 to 3470770 Compare April 4, 2023 06:44
@doks5 doks5 force-pushed the person/andonova/api-job-deployment branch from 3470770 to 37dc043 Compare April 4, 2023 08:30
@mivanov1988
Copy link
Contributor

Have you seen the Codacy issues?

doks5 and others added 5 commits April 4, 2023 14:41
As part of the effort to provide users with the ability to specify the python
release version, which they want their data jobs to be deployed with, we need to
expose a property in the Control Service's API and ensure that the configuration
is stored in the database and the kubernetes objects.

This change exposes a `python_version` property in the api schemas of the
DataJobDeployment and DataJobDeploymentStatus components, and propagates the property
to the database model and kubernetes resources. All of this is done as one change,
to avoid unexpected behaviour or regressions.

Testing Done: New and modified existing tests.

Signed-off-by: Andon Andonov <andonova@vmware.com>
Signed-off-by: Andon Andonov <andonova@vmware.com>
Signed-off-by: Andon Andonov <andonova@vmware.com>
@doks5 doks5 force-pushed the person/andonova/api-job-deployment branch from 37dc043 to 68e53cd Compare April 4, 2023 11:41
@doks5
Copy link
Contributor Author

doks5 commented Apr 4, 2023

Have you seen the Codacy issues?

As discussed offline, these are fixed now. Thanks

@doks5 doks5 requested a review from mivanov1988 April 4, 2023 13:47
doks5 and others added 2 commits April 4, 2023 18:14
Signed-off-by: Andon Andonov <andonova@vmware.com>
Copy link
Collaborator

@antoniivanov antoniivanov left a comment

Choose a reason for hiding this comment

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

The change looks good to me.

But I'd like to discuss following questions (at some point before the feature is considered implemented)
:

  1. What happens when administrators change the supported versions?

What is the right behaviour ?

  1. the same goes for the default version. What happens when administrators change teh default version ?

I don't think we've thought about and discussed it.

@doks5 doks5 enabled auto-merge (squash) April 5, 2023 05:31
@doks5 doks5 merged commit 5086fa3 into main Apr 5, 2023
4 of 5 checks passed
@doks5 doks5 deleted the person/andonova/api-job-deployment branch April 5, 2023 06:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Control Service: Add python_version property to api
5 participants