10 Commits

Author SHA1 Message Date
Jeff McCune
cde4380049 Add holos component HelmChart type
This patch implements rendering a holos component from an upstream helm
chart using a values.yaml file generated by CUE.  The resulting
kubernetes api objects are saved to the deploy directory in the same way
the KubernetesObject holos component type.

```
❯ holos render --cluster-name=core2 ./docs/examples/platforms/reference/projects/secrets/components/...
3:55PM INF render.go:39 rendered prod-secrets-eso version=0.41.0 status=ok action=rendered name=prod-secrets-eso
3:55PM INF render.go:39 rendered prod-secrets-namespaces version=0.41.0 status=ok action=rendered name=prod-secrets-namespaces
```

```
❯ tree deploy
deploy
└── clusters
    └── core2
        ├── components
        │   ├── prod-secrets-eso
        │   │   └── prod-secrets-eso.gen.yaml
        │   └── prod-secrets-namespaces
        │       └── prod-secrets-namespaces.gen.yaml
        └── holos
            └── components
                ├── prod-secrets-eso-kustomization.gen.yaml
                └── prod-secrets-namespaces-kustomization.gen.yaml

7 directories, 4 files
```
2024-02-12 15:56:06 -08:00
Jeff McCune
0d4f36333f Add platform and instance values to helm values 2024-02-12 10:16:40 -08:00
Jeff McCune
69916a13ab Decode cue values for use as helm values
In helm mode, cue is responsible for producing the values.yaml file.
Holos is responsible for taking the values produced by cue and providing
them to helm to produce rendered kubernetes api objects.

This patch adds intermediate data structures to hold the output from
cue: the helm values, the flux kustomization, and the helm charts to
provide the helm values to.

Holos takes this information and orchestrates running helm template to
render the api objects and write them to the file system for git ops.
2024-02-12 09:53:47 -08:00
Jeff McCune
9739fc6471 Initial structure for helm support
Stopping here to look into generating go types from the cue output type
definitions.
2024-02-10 17:14:42 -08:00
Jeff McCune
bb06fa742a Render flux Kustomization along with api objects
This patch writes a Flux Kustomization to apply the api objects rendered
by a component instance.

    ❯ holos render --log-format=json --log-level=debug --cluster-name core2 ./docs/examples/platforms/reference/projects/secrets/components/namespaces/ 2> >(./scripts/msgs)
    config.go:91    finalized config from flags
    builder.go:129  cue export --out yaml -t cluster=core2 ./platforms/reference/projects/secrets/components/namespaces
    builder.go:134  configured cue tags: [cluster=core2]
    builder.go:94   wrote deploy/clusters/core2/components/prod-secrets-namespaces/prod-secrets-namespaces.gen.yaml
    builder.go:94   wrote deploy/clusters/core2/holos/components/prod-secrets-namespaces-kustomization.gen.yaml
    render.go:39    rendered prod-secrets-namespaces

```yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: prod-secrets-namespaces
  namespace: flux-system
spec:
  interval: 30m0s
  path: deploy/clusters/core2/components/prod-secrets-namespaces
  prune: true
  retryInterval: 2m0s
  sourceRef:
    kind: GitRepository
    name: flux-system
  timeout: 3m0s
  wait: true
```
2024-02-09 15:42:50 -08:00
Jeff McCune
7dce445c1a Import flux v2.2.3 crds into cue schemas
timoni mod vendor crds -f https://github.com/fluxcd/flux2/releases/download/v2.2.3/install.yaml
2024-02-09 13:45:57 -08:00
Jeff McCune
e2b1fa0d47 Rename cue out field to content and add content-type
Content seems more appropriate of a field name, and it makes sense since
we are likely to output other formats than yaml, probably json too.  We
need to discriminate on content type, so also add a contentType field.

Semantics are meant to be the same has the http content type header, but
simple.
2024-02-08 22:26:07 -08:00
Jeff McCune
e018deef5a Add name field to cue output schema
The intent is for all of the output formats to share a common `name`
field, useful to construct a file name to write rendered output to for
git ops.

This is equivalent to the OrderedComponent name specified in the
platform.yaml in the prototype.
2024-02-08 22:09:00 -08:00
Jeff McCune
9bebd2e4b6 Discriminate on cue export type
Leaf directories can output different kinds of things:

 1. Platform specification.  A list of components to manage.
 2. Kubernetes API Objects suitable for kubectl apply -f- and friends.
 3. Helm values to provide to a helm chart to render API objects.

This patch adds an output schema and a kind discriminator so the holos
cli can figure out what type of output it's working with.  This makes it
possible to have a single `holos build <directory>` command that does
the right thing.
2024-02-06 15:47:13 -08:00
Jeff McCune
9603e6b551 Manage the external-secrets namespace
This patch adds the first platform component built with CUE.  The intent
is to give a concrete use case for migrating the platform.yaml spec over
to the new approach with CUE.

This component is a simple namespace for the external secrets operator.
The majority of this patch is in setting up the structure of the CUE
module.  The component is _not_ wired up to the holos cli yet, instead
it's built directly with cue using:

    cd ./docs/examples/
    cue export --out text -t cluster=core1 -e out ./platforms/reference/projects/secrets/components/namespaces/...

The command produces the same output as the was previously produced
using helm templates [here][1].

[1]: https://github.com/holos-run/holos-infra/blob/v0.4.0/deploy/clusters/core1/components/prod-secrets-namespaces/prod-secrets-namespaces.nofmt.yaml
2024-02-05 14:07:56 -08:00