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

[BUG] Endless affinity list when using new schudlingPolicy field #8105

Open
cjc7373 opened this issue Sep 6, 2024 · 0 comments
Open

[BUG] Endless affinity list when using new schudlingPolicy field #8105

cjc7373 opened this issue Sep 6, 2024 · 0 comments
Assignees
Labels
kind/bug Something isn't working

Comments

@cjc7373
Copy link
Contributor

cjc7373 commented Sep 6, 2024

Describe the bug
Endless affinity list when using new schudlingPolicy field and a DATA_PLANE_AFFINITY in config

To Reproduce
Steps to reproduce the behavior:

  1. Have a DATA_PLANE_AFFINITY: '{"nodeAffinity":{"preferredDuringSchedulingIgnoredDuringExecution":[{"preference":{"matchExpressions":[{"key":"kb-data","operator":"In","values":["true"]}]},"weight":100}]}}' field in the config
  2. Create a cluster CR, with schedulingPolicy field not null. e.g.
    spec:
      schedulingPolicy:
        schedulerName: custom-scheduler
  3. cluster can't finish reconciling

The cluster CR will become like:

apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
spec:
  ...
  schedulingPolicy:
    affinity:
      nodeAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
        - preference:
            matchExpressions:
            - key: kb-data
              operator: In
              values:
              - "true"
          weight: 100
        - preference:
            matchExpressions:
            - key: kb-data
              operator: In
              values:
              - "true"
          weight: 100
        - preference:
            matchExpressions:
            - key: kb-data
              operator: In
              values:
              - "true"
          weight: 100
        [repeat hundreds of times]
        ...
    schedulerName: custom-scheduler
    tolerations:
    - effect: NoSchedule
      key: kb-data
      operator: Equal
      value: "true"
    - effect: NoSchedule
      key: kb-data
      operator: Equal
      value: "true"
    - effect: NoSchedule
      key: kb-data
      operator: Equal
      value: "true"
    [repeat hundreds of times]
    ...

Additional context
The root cause is that the generated scheduling policy is patched to cluster CR itself. Though it only should be in the component CR.

On a deeper view, this bug happened because cluster controller would modify cluster CR's spec. In which use case do we need this behavior? After all, the general idea is that a controller will not modify the CR's spec it reconciles.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants