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

In Kubernetes container groups, user-supplied .metadata.labels is ignored #8486

Closed
domq opened this issue Oct 29, 2020 · 0 comments · Fixed by #8487
Closed

In Kubernetes container groups, user-supplied .metadata.labels is ignored #8486

domq opened this issue Oct 29, 2020 · 0 comments · Fixed by #8487

Comments

@domq
Copy link

domq commented Oct 29, 2020

ISSUE TYPE
  • Bug Report
SUMMARY

Due to awx/main/scheduler/kubernetes.py overriding the .metadata.labels of the pods it creates (instead of merging them with the user-supplied pod_spec_override), features such as pod anti-affinity between AWX runners cannot work.

ENVIRONMENT
  • AWX version: 15.0.1 (also present in devel)
  • AWX install method: openshift
  • Ansible version: irrelevant
  • Operating System: Linux (all versions)
  • Web Browser: irrelevant
STEPS TO REPRODUCE
  1. Create a Kubernetes container group with the below piece of YAML as the pod spec override
  2. Run a job out of this instance group
apiVersion: v1
kind: Pod
metadata:
  labels:
    deploymentconfig: ansible-runner
  namespace: wwp-test
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - topologyKey: kubernetes.io/hostname
          labelSelector:
            matchExpressions:
              - key: deploymentconfig
                operator: In
                values:
                  - ansible-runner
  # ...
EXPECTED RESULTS

The pods run by AWX as part of the container group should contain both the custom labels and the affinity structure.

ACTUAL RESULTS

Only the affinity structure shows up in the Kind: pod Kubernetes objects, rendering the podAntiAffinity clause inoperative (for lack of a label to match on under metdata)

ADDITIONAL INFORMATION

The cause is the equals sign on this line.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants