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

Support for Multiple Python Versions in VDK #1739

Closed
doks5 opened this issue Mar 12, 2023 · 2 comments · Fixed by #1748, #1761, #2002 or #2075
Closed

Support for Multiple Python Versions in VDK #1739

doks5 opened this issue Mar 12, 2023 · 2 comments · Fixed by #1748, #1761, #2002 or #2075

Comments

@doks5
Copy link
Contributor

doks5 commented Mar 12, 2023

What is the feature request? What problem does it solve?
At the moment, if a user deploys a data job with python 3.8 in a k8s cluster, and decides they want to deploy another job with python 3.10, the only way to do it, is to re-configure and re-deploy the Control Service. This, however, creates issues because the moment the first job (the one that uses python 3.8) is re-deployed, it would automatically be switched to python 3.10 with unforeseeable consequences.

A new mechanism is needed to make it possible to dynamically configure what python version a data job uses when it is deployed in a k8s cluster.

Suggested solution
A possible solution is to introduce a new property in the data job's config.ini file, indicating what python version is supposed to be used, when the data job is deployed. This way, when the vdk deploy command is invoked, the Control Service would deploy the data job with the specified python version.

For this to be possible, the Control Service would need to store configuration what python versions are supported, and to dynamically pass the user-defined python version to the data job builder.

Additional context
A VEP with more details will be created for this enhancement.

@antoniivanov
Copy link
Collaborator

It's not closed , right? This is the Epic issue for teh whole effort - it would be closed when everything (outlined in the VEP https://github.com/vmware/versatile-data-kit/tree/main/specs/vep-1739-multiple-python-versions) is completed.

@doks5
Copy link
Contributor Author

doks5 commented Mar 30, 2023

It's not closed , right? This is the Epic issue for teh whole effort - it would be closed when everything (outlined in the VEP https://github.com/vmware/versatile-data-kit/tree/main/specs/vep-1739-multiple-python-versions) is completed.

Correct. It will stay open till the end. :)
Thanks for re-opening it, by the way

@doks5 doks5 linked a pull request Mar 30, 2023 that will close this issue
@doks5 doks5 linked a pull request May 1, 2023 that will close this issue
@doks5 doks5 reopened this May 2, 2023
@doks5 doks5 linked a pull request May 29, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment