JeffMcCune

Why would you guess that? Most justices concern themselves with statute.

This is not accurate. I filed a claim against Bungalow in Oregon. They petitioned the judge to allow their in house attorney I was dealing with to represent them. The judge denied the request citing the Oregon statute that attorneys may not participate in small claims proceedings. Bungalow flew out their director of some division who was ill prepared.

Slam dunk. took all of 6-8 hours of my time end to end. The claim was a single page document. Got the max award allowable. Would have got more had it been California.

55.090 Appearance by parties and attorneys; witnesses. (1) Except as may otherwise be provided by ORS 55.040, no attorney at law nor any person other than the plaintiff and defendant shall become involved in or in any manner interfere with the prosecution or defense of the litigation in the department without the consent of the justice of the justice court, nor shall it be necessary to summon witnesses.

You can’t revoke, rotate, or audit access to them.

These are effectively MSPs and perform the kind of role GP describes.

Use a bucket for this. Or if you’re in a home lab use a boring old NFS server outside k8s

Harder to scale, stateful.

That was the first album on it for sure and yes he repeats it constantly. Luckily the speaker is in his room.

He’s got a yoto too but won’t wear the headphones, so this has been a nice compromise.

I don’t. It works, reliably enough that my son hasn’t had any issues using it for a week. What’s bad about it?

It’s anthropomorphism taking over. I pretend I’m talking with a colleague when I do this sort of thing.

Except you can easily install calico, istio, and ceph on used hardware in your garage and get an experience nearly identical to every hyper scaler using entirely free open source software.

Is Google sheets backend (from the screenshot in the readme) what I think it is? Sheets API as a database?

If so props to you.

My original idea behind https://holos.run was to create a Heorku like experience for k8s so I’m super happy to see this existing in the world. I’d love to explore an integration, potentially spinning up the single or multi node clusters with cluster api.

  Location: Portland, OR
  Remote: Yes
  Willing to relocate: No
  Technologies: Kubernetes, Go, Python, AWS, GCP, OIDC, TCP/IP, TLS
  Résumé/CV: https://docs.google.com/document/d/1L4l22IdwtW75MaNzQnJoOx2apQUKV9-J5TBz6bMS5BQ/edit?usp=sharing
  Email: mccune.jeff+hn2506@gmail.com

Specializing in infrastructure and deployment automation, platform integration, networking, and security. Recently launched Holos, a holistic platform management tool here on Show HN. Previous startup experience at Puppet as the 12th employee. Overhauled and redesigned Twitter's configuration management system for 300K+ hosts before it was acquired. Lots of successful cloud projects over the past 10 years.

Resume/CV Link: https://docs.google.com/document/d/1L4l22IdwtW75MaNzQnJoOx2a...

Yesterday I installed Karabiner Elements to get a jk chord mapped to escape globally. I’m a bit disappointed it’s not actually a chord, it’s a simultaneous press with a 100ms window.

Does Kanata support chords like jk to escape with a configurable timeout on when k is pressed, say 80ms or so?

An artifact depends on the tools used to build it.

This is why we pin versions. Go tool is common sense, allowing for any old tool version in the build chain invites failure.

As other sibling comments suggest these use cases are better solved with a generator.

The rendered manifest pattern is a simpler alternative. Holos [1] is an implementation of the pattern using well typed CUE to wrap Helm and Kustomize in one unified solution.

It too supports Projects, they’re completely defined by the end user and result in the underlying resource configurations being fully rendered and version controlled. This allows for nice diffs for example, something difficult to achieve with plain ArgoCD and Helm.

[1] https://holos.run/docs/overview/

Congrats on the launch! Since this is Go have you considered using CUE or looked at their flow package? Curious how you see it relating or helping with data pipelines.

For posterity, I'm documenting the integration between Holos and Kargo at https://holos.run/docs/kargo/

Go was the first language where I deeply appreciated strong typing. I’d used other before but it was go to definition working 100% of the time that did it for me. Maybe start there with them?

CUE is a close cousin to Go, the authors are deeply involved in Go. Marcel worked with Rob Pike on the design of CUE. I could see how it’d feel foreign, without first appreciating Go maybe CUE wouldn’t have clicked for me.

Very nice, would love to see a kubectl explain type plugin to integrate with this somehow.

Got you, I did not mean to be argumentative, only to explain why Holos is what it is.

Could you clarify what process you're speaking of as the end goal?

Holos is designed to produce configuration for Kubernetes. That configuration can be as small as a 10 line yaml file, but in larger operations it often ends up being multiple millions of lines of yaml spread over multiple clusters across the globe.

Once Holos produces the configuration, we stop. We leave it up to you to decide what to do next with it. For example we pass it to ArgoCD to deploy, others pass it to Flux. In development I pass it directly to kubectl apply.

Holos writes fully rendered manifests to the local filesystem, a gitops repository. Kargo watches a container registry for new images, then uses the rendered manifests Holos produced as the input to the promotion process.

The specific integration point I explored last week was configuring Holos to write a Kustomize kustomization.yaml file along side each of the components that have promotable artifacts. This is essentially just a stub for Kargo to come along and edit with a promotion step.

For example the output of the Holos rendering process for our demo "Bank of Holos" front end is this directory:

https://github.com/holos-run/bank-of-holos/tree/v0.6.2/deplo...

Normally, ArgoCD would deploy this straight from Git, but we changed the Application resource we configure to instead look where Kargo suggests, which is a different branch. Aside, I'm not sure I like the multiple branches approach but I'm following Kargo's docs initially then will look at doing it again in the same branch but using different folders.

https://github.com/holos-run/bank-of-holos/blob/v0.6.2/deplo...

Note the targetRevision: stage/dev Kargo is responsible for this branch.

The Kargo promotion stages are configured by this manifest Holos renders:

https://github.com/holos-run/bank-of-holos/blob/v0.6.2/deplo...

Holos writes this file out from the CUE configuration when it renders the platform. The corresponding CUE configuration responsible for producing that rendered manifest is at:

https://github.com/holos-run/bank-of-holos/blob/v0.6.2/proje...

This is all a very detailed way of saying: Holos renders the manifests, you commit them to git, Kargo uses Kustomize edit to patch in the promoted container image and renders the manifests _again_ somewhere else (branch or folder). ArgoCD applies the manifests Kargo writes.

I'll write it up properly soon, but the initial notes from my spike last week are at https://github.com/holos-run/bank-of-holos/blob/main/docs/ka...

I recorded a quick video of it at https://www.youtube.com/watch?v=m0bpQugSbzA which is more a demo of Kargo than Holos really.

What we were concerned about was we'd need to wait for Kargo to support arbitrary commands as promotion steps, something they're not targeting on having until v1.3 next year. Luckily, we work very well with their existing promotion steps because we take care to stop once we write the rendered manifests, leaving it up you to use additional tools like kubectl apply, Kargo, Flux, ArgoCD, etc...

I share Marcel's view, a DSL is the ideal position on the configuration complexity clock. CUE in particular is ideal for configuration because of how it handles unification.

I wrote up why we selected CUE here, with links to explanations from Marcel who explains it better than I: https://holos.run/blog/why-cue-for-configuration/

These comments in particular reminded me of Marcel's video linked at the bottom of that article, where he talks about the history of CUE in the context of configuration languages at Google: https://www.youtube.com/watch?v=jSRXobu1jHk

This is a great summary, thank you.

Thanks! Holos and Timoni solve similar problems but at slightly different levels of the stack and with a different approach. Timoni is focused on managing applications by evaluating CUE stored in an OCI container. Stephan expressed his intention to have a controller apply the resulting manifests similar to Flux. Timoni defers to Flux to manage Helm charts in-cluster, Holos renders Helm charts to manifests much like ArgoCD does, using helm template within the rendering pipeline.

We take a slightly different approach in a few important ways.

1. Holos stops short of applying manifests to a cluster, leaving that responsibility to existing tools like ArgoCD, Flux, plain kubectl apply, or other tools. We're intentional about leaving space for other tools to operate after manifests are rendered before they're applied. For example, we pair nicely with Kargo for progressive rollouts. Kargo sits between Holos and the Kubernetes API and fits well with Holos because both tools are focused on the rendered manifest pattern.

2. Holos focus on the integration of multiple Components into an overall Platform. I capitalized them because they mean specific things in Holos, a Component is our way of wrapping existing Helm charts, Kustomize bases, and plain raw yaml files, in CUE to implement the rendering pipeline.

3. We're explicit about the rendering pipeline, our intent is that any tool that generates k8s config manifests could be wrapped up in a Generator in our pipeline. The output of that tool can then be fed into existing transformers like Kustomize.

I built the rendering pipeline this way because I often would take an upstream helm chart, mix in some ExternalSecret resources or what not, then pipe the output through Kustomize to tweak some things here and there. Holos is a generalization of that, it's been useful because I no longer need to write any YAML to work with Kustomize, it's all pure data in CUE to do the same thing.

Those are the major difference. I'd summarize them as holos focuses on the integration layer, integrating multiple things together. Kind of like an umbrella chart, but using well defined CUE as the method of integrating things together. The output of each tool is another main difference. Holos outputs fully rendered manifests to the local file system intended to be committed to a GitOps repo. Timoni acts as a controller, applying manifests to the cluster.

Thanks for asking! The teams we've worked with do one of two things when deploying Helm charts with ArgoCD. They either pass values directly to the chart from the Application resource, or they use scripts to merge values.yaml files together and pass them to the helm template command to implement the rendered manifests pattern.

In both cases it's tedious to manage the helm values, and they're usually managed without strong type checking or having been integrated into your platform as a whole. For example, you might pass a domain name to one chart and another value derived from the domain name to another chart, but the two charts likely use different field names for the inputs so the values are often inconsistent.

Holos uses CUE to unify the configuration into one holistic data structure, so we're able to look up data from well defined structures and pass them into Helm. We have an example of how this helps integrate the prometheus charts together at: https://holos.run/docs/v1alpha5/tutorial/helm-values/

This unification of configuration into one data structure isn't limited to Helm, you can produce resources for Kustomize from CUE in the same way, something that's otherwise quite difficult because Kustomize doesn't support templating. You can also mix-in resources to your existing Helm charts from CUE without needing to template yaml.

This approach works equally well for both in-house Helm charts you may have created to deploy your own software, or third party charts you're using to deploy off the shelf software.

Holos - https://holos.run/docs/v1alpha5/tutorial/overview/

Holos is a configuration management tool for Kubernetes. It provides the building blocks needed for implementing the rendered manifests pattern. It's a new project we built from our experience managing our own and our client's infrastructure.

We're looking for design partners to help us identity and define use cases. If you need to configure services for multiple environments, customers, regions, projects, and teams your input would be valuable.

Tech Stack: Go, CUE, Helm, Kustomize. Roadmap: Jsonnet, KCL, PKL, etc... as needed.

Thanks for the kind words and encouragement!

Agreed, this is one of the major reasons we sought out something else and found CUE.

We had a massive umbrella chart with a top level globals key for awhile but it was very difficult for us to maintain.

https://buf.build/ is this, no?