MULTIARCH-4252: namespace-scoped Pod Placement Config #453
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@aleskandro: This pull request references MULTIARCH-4252 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.19.0" version, but no target version was set. 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 openshift-eng/jira-lifecycle-plugin repository. |
aleskandro
force-pushed
the
ep-per-namespace
branch
from
f90ad13 to
c364649
Compare
|
/cc @jeffdyoung @prb112 |
|
@aleskandro: This pull request references MULTIARCH-4252 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.19.0" version, but no target version was set. 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 openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci
bot
added
lgtm
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: prb112 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 |
aleskandro
force-pushed
the
ep-per-namespace
branch
from
29c97dc to
1598da1
Compare
aleskandro
force-pushed
the
ep-per-namespace
branch
4 times, most recently
from
f99229e to
c2769c2
Compare
| | security.openshift.io/securitycontextconstraints | use | it's used in case the pods are created by a user/SA that needs some privileges | | ||
| | events | create, patch | | | ||
| | podplacementconfigs.multiarch.openshift.io | get, list, watch | | | ||
| | configmaps, secrets | get, list, watch | (future) (not needed by the current plugins) if other plugins will require them to communicaet with the registries | |
There was a problem hiding this comment.
will secrets be a cluster role since we need the global pull secret?
|
/lgtm |
| - The pod placement controller should apply the configuration defined by the namespace-scoped `PodPlacementConfig` CRD to the pods in the selected namespaces, and the cluster-scoped `ClusterPodPlacementConfig` configuration for preferred affinities should be ignored | ||
| - The pod placement controller should apply the configuration defined by the highest-priority namespace-scoped `PodPlacementConfig` CRD to pods matching multiple `PodPlacementConfig` CRDs in the same namespace | ||
| - No PPC with the same priority should be allowed in the same namespace | ||
| - When no priority is set in the `PodPlacementConfig`, the operator should default to the lowest priority among the existing Pod Placement Configs in the same namespace decreased by 1 |
There was a problem hiding this comment.
what will occur when new ppc with no priority is created but the current lowest priority of ppc in the namespace is already 0? will the creation be rejected?
There was a problem hiding this comment.
That's a good point @lwan-wanglin. I updated the proposal by defaulting to 0 and increasing the value for each new one PPC that gets created.
In this way:
- 'newly' created PPCs (if the priority field is omitted), gets a higher priority (instead of a lower one)
- The issue arises when the highest priority is 255, in which case, we'd reject the creation (Adding a test case for this too).
There was a problem hiding this comment.
i'm wondering if we are being too rigid with the priority. if no priority is defined, we should just set it to 0. If there are multiple ppc's with no priority it's a random pick. If the user really cares, they will specify the priority. This way is less deterministic when ppcs get evaluated, but assuming that a PPC which is created first has a higher priority might not be the best assumption to go with.
On the other hand, if a value is specified, we should take care that no other ppc has the same value - I'm fine with that.
| 2. Get all the pod placement configurations in the pod's namespace, sorted by descending priority | ||
| 3. For each pod placement configuration: | ||
| - Check if the pod matches the label selector | ||
| - Apply the configuration to the pod. |
There was a problem hiding this comment.
Does the following situation exist:
the image supported architecture doesn't exist in preference Arch in plugins.
There was a problem hiding this comment.
Hi @lwan-wanglin, can you clarify your point here?
There was a problem hiding this comment.
what I mean is that if a pod container using single arch image like ppc64le, but the namespace-scoped ppc set a plugins configure like below, finially we set nodeAffinity with supported arch ppc64le, right?
plugins:
nodeAffinityScoring:
enabled: true
platforms:
- architecture: amd64
weight: 25
- architecture: arm64
weight: 75
There was a problem hiding this comment.
the required during scheduling affinity will always be added by cppc. in this case the preferred during scheduling affinity will also be added with weights - it just won't do anything
|
New changes are detected. LGTM label has been removed. |
aleskandro
force-pushed
the
ep-per-namespace
branch
from
58bbec9 to
4753570
Compare
|
@aleskandro: all tests passed! Full PR test history. Your PR dashboard. 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. I understand the commands that are listed here. |
This PR provides the design proposal for the namespace-scoped Pod Placement Configuration and minor fixes to the (to be updated) initial EP.