arikkfir / kude Goto Github PK

Evaluate using https://github.com/evanphx/json-patch

Allow a resource to specify an "externalName" (in addition to its standard Kubernetes name), probably through an annotation; that external name will be used by Kude to find references to that external name elsewhere, and replace those references with the actual Kubernetes name of that resource.

For example:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cfg-aj491djs2
  namespace: main
  annotation:
    # this annotation tells Kude to replace references ConfigMaps named
    # "cfg" in namespace "main" to the actual name of this resource
    kude.kfirs.com/externalName: cfg
data:
  foo: bar
---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: server
    env:
    - name: FOO
      valueFrom:
        configMapKeyRef:
          name: cfg # this should be replaced with "cfg-aj491djs2"
          key: foo

Current values from the configmap generator function are base64 encoded, even though they should not be. Only values in the Secret resource should be base64 encoded.

Allow providing kustomize directories as resources in a Kude pipeline.

Known objects that should not get namespace:

• Namespace
• ClusterRole
• ClusterRoleBinding
• ValidatingWebhookConfiguration
• CustomResourceDefinition

Support targeting specific resource types as well.

Something like this:

- image: .../annotate
  config:
    name: my-annotation

    # annotate any resource matching ANY of the following predicates (logical OR)
    targets:
      # This will annotate all resources of type "Namespace" (even if they are not of API version "v1")
      - kind: Namespace

      # This will annotate all service accounts (this is more specific, using the "apiVersion"...)
      - apiVersion: v1 
        kind: ServiceAccount

      # This will annotate all config maps with the label "component=mysql"
      - apiVersion: v1
        kind: ConfigMap
        labels:
          component: mysql

Currently values must be stored as plain-text values either in kude.yaml files or as text files read by Kude during processing.

We should support some kind of encryption/decryption mechanism that will allow users to store such values committed in the source code (or at least available to the pipeline externally) so that Kude is able to incorporate those secret values into the YAML output.

Increase the tests coverage - both reporting-wise as well as actual coverage.

This will likely require a refactor of the testing mechanism to be more scenario-declarative.

Allow functions to specify the minimum version of Kude they require, by adding a Docker label.

When a URL is detected to be a Helm chart, we can use a helm template ... command to render it.

Functions could require local files from the workspace to be provided to them in order to function.

Primary use-case would be generators of ConfigMap or Secret objects from data in local files.