Installation framework for python packages #11158
Conversation
Some ansible module requires specific python libraries on the hosts managed by ansible. In particular, the kubernetes.core.k8s module (which is a better alternative than our own custom kubernetes-sigs.kubespray.kube module) require "kubernetes". Another potential useful candidate would be python "cryptography", which would allow us to use the community.crypto collection, advantageously replacing the ad-hoc stuff we have in roles/etcd. To allow granular python packages installation (only install where needed), we reuse the infrastructure introduced in 663fcd1 (Filter packages installation by OS and by group, 2024-04-05) to also install python packages in a dedicated kubespray virtualenv. This implementation is missing a critical part, supply chain security. This will be addressed soon.
|
Skipping CI for Draft Pull Request. |
k8s-ci-robot
added
the
do-not-merge/work-in-progress
k8s-ci-robot
added
kind/design
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: VannTen The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
size/M
|
/label tide/merge-method-merge |
k8s-ci-robot
added
the
tide/merge-method-merge
|
I'm actually contemplating using poetry (only in the dev workflow, mind you) to export a "cross-platform" (poetry cross-platform stuff has some caveats, from what I understand) requirements.txt instead of killing myself over trying to install a specific python version for all supported os targets 🤔 |
|
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
k8s-ci-robot
added
the
needs-rebase
|
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
k8s-ci-robot
added
lifecycle/rotten
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
|
@k8s-triage-robot: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
What type of PR is this?
/kind design
What this PR does / why we need it:
Some ansible module requires specific python libraries on the hosts
managed by ansible.
In particular, the kubernetes.core.k8s module (which is a better
alternative than our own custom kubernetes-sigs.kubespray.kube module)
require "kubernetes".
Another potential useful candidate would be python "cryptography", which
would allow us to use the community.crypto collection, advantageously
replacing the ad-hoc stuff we have in roles/etcd.
To allow granular python packages installation (only install where
needed), we reuse the infrastructure introduced in 663fcd1 (Filter
packages installation by OS and by group, 2024-04-05) to also install
python packages in a dedicated kubespray virtualenv.
This is the last preparation PR for #10701 (which I'm gonna update after posting this)
Special notes for your reviewer:
This is missing supply-chain security (I plan to use pip-tools to compile fully resolved stack with hashes, see commits)
I'm not completely decided on the way to use different ansible modules which requires different python stacks:
kubernetes.core.k8s/community.crypto.*for instances)2 might be preferrable to avoid dependencies clashs, but I don't know if this is an actual concern in practice ; I'd appreciate opinions on that.
/cc @MrFreezeex @mzaian @floryut @ErikJiang @yankay
Does this PR introduce a user-facing change?: