arcalot / arcaflow-engine-deployer-kubernetes Goto Github PK

Please describe what you would like to see in this project

SecurityContext to be exposed from the schema both at Pod and container level.

Please describe your use case

Run kraken containers in openshift with security policies enabled

Additional context

Add any other context you would like to include here.

Please describe what you would like to see in this project

Currently the affinity feature of the k8s API is not supported in the spec parameters for a workflow plugin. This is a critical feature for ensuring pods are co-located or explicitly avoid co-location on the same nodes.

2022-11-22T10:51:15Z	info		Starting step metadata...
2022-11-22T10:51:15Z	error		Workflow execution failed (failed to unserialize deployer config for step metadata (Validation failed for 'pod' -> 'spec': Invalid parameter 'affinity', expected one of: initContainers, containers, pluginContainer, volumes))
exit status 1

Please describe your use case

When scheduling a metadata or metrics collection plugin alongside a workload plugin, it is critical that these plugins run on the same nodes in the cluster.

Sample workflow snippet:

  metadata:
    plugin: quay.io/arcalot/arcaflow-plugin-metadata:latest
    deploy:
      type: kubernetes
      connection: !expr $.steps.kubeconfig.outputs.success.connection
      pod:
        metadata:
          namespace: default
          labels:
            arcaflow: metadata
        spec:
          pluginContainer:
            imagePullPolicy: Always
          affinity:
            podAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                  - key: arcaflow
                    operator: In
                    values:
                    - uperf-client
    input: {}

We have an indirect dependency on a Go package named mergo. This package was updated from v0.3.6 to v1.0.0 recently, and the Renovate bot proposes that we update our go.mod file to match.

Unfortunately, as part of the update to v1.0.0, the package path was changed to use a new vanity hostname. As a result, when the bot updates our go.mod file, the path to the package in our requirements does not match the path in our direct dependency's requirement, and we get an error from go get, which, among other things, makes the bot upset.

The proper solution is, I presume, for our dependency to update their dependency to the v1.0.0 version so that the pathing problem is removed (but, this does not seem to be forthcoming). The interim solution is to manually maintain our indirect dependency at v0.3.16, which is functionally equivalent to v1.0.0 but which is still available from the old path.

However, every week, when the bot runs, it proposes updating to v1.0.0 again. And, because of the process failure, the bot refuses to run again while the PR is open, and so we are exposed in terms of missing other updates.

Other than simply closing the PR each week (after checking that it's not proposing to update anything other than mergo and its dependencies!), the only option would seem to be adding to the local bot configuration a matcher for mergo which says to ignore that particular upgrade. (But, I'm not sure exactly how to do that, and we would presumably need something to remind us to remove that configuration again, once our dependency updates their dependency.)

So, for now, I'm just going to close the PR. But, that's only going to help us until next week.

Describe the bug

current labelValue validation regex prevents the use of legit label values like master-0. Has been reported by a user that was trying to use a nodeSelector like kubernetes.io/hostname: mimmo-0 that is pretty common.

To reproduce

set a dash separated label value like master-0

Additional context

Add any other context about the problem here.