v0.3.43

This release add a new command line utility clm. It can be used (similar to helm) to deploy arbitrary components to a kubernetes cluster, without requiring any additional operators or other resources to be installed in the cluster:

A Kubernetes package manager

Common actions for clm:
- clm apply              Apply given component manifests to Kubernetes cluster
- clm delete             Remove component from Kubernetes cluster
- clm status             Show component status
- clm ls                 List components

Usage:
  clm [command]

Available Commands:
  apply       Apply component
  completion  Generate the autocompletion script for the specified shell
  delete      Delete component
  help        Help about any command
  list        List components
  status      Show component status
  version     Show version

Flags:
      --as string                      Username to impersonate for the operation. User could be a regular user or a service account in a namespace.
      --as-group stringArray           Group to impersonate for the operation, this flag can be repeated to specify multiple groups.
      --as-uid string                  UID to impersonate for the operation.
      --cache-dir string               Default cache directory (default "/Users/xxx/.kube/cache")
      --certificate-authority string   Path to a cert file for the certificate authority
      --client-certificate string      Path to a client certificate file for TLS
      --client-key string              Path to a client key file for TLS
      --cluster string                 The name of the kubeconfig cluster to use
      --context string                 The name of the kubeconfig context to use
      --disable-compression            If true, opt-out of response compression for all requests to the server
      --insecure-skip-tls-verify       If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure
      --kubeconfig string              Path to the kubeconfig file to use for CLI requests.
  -n, --namespace string               If present, the namespace scope for this CLI request (default "default")
      --request-timeout string         The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0")
  -s, --server string                  The address and port of the Kubernetes API server
      --tls-server-name string         Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used
      --token string                   Bearer token for authentication to the API server
      --user string                    The name of the kubeconfig user to use
  -h, --help                           help for clm

Use "clm [command] --help" for more information about a command.

For example:

clm  -n my-ns apply my-comp ./my-manifests -f my-values.yaml

A kubeconfig can be provided by flag --kubeconfig. If not set, the environment variable KUBECONFIG will be used to get the path to the kubeconfig. The provided manifests can either be a helm chart (detected by the presence of a Chart.yaml file in the specified directory), or a kustomization folder (otherwise). In the kustomization case (no Chart.yaml), if there is no kustomization.y(a)ml file found, then the directory will be searched recursively for all files ending with .y(a)ml, and the content of all these files will form the set of manifests to be deployed.

Under the hood, component-operator-runtime is used to render and deploy the manifests. That means, all the features described in the documentation are available, such as:

• apply/delete waves
• smart handling of custom types (such as CRDs)
• improved status detection
• go templating also for kustomizations resp. plain yaml sources