pst

Cool project. Love the clean look.

I've been building a frontend with Go, Templ and Datastar for a few months now. I really like the @actions and how the page is updated with the response.

I'm on the fence about signals though. They are fine for simple things like individual text form fields or opening closing a drop-down. But my backend is a Kubernetes style API server. And storing a JSON Kubernetes style resource in a signal does not work because of how Datastar implements parsing the structure into child signals. For me it would be better to just be able to turn this off.

One example where it breaks are K8s labels. They are map[string]string and the key is often hostname prefixed. E.g. example.com/label-key. Datastar can't handle these keys at all and the resulting signals are a mess.

I'm aware that I may be using signals not as intended. But something as simple as data-signals-resource="k8sJson" and then data-bind="resource.metatdata.name" is a great way to work. And it works for metadata name. But it doesn't work if any part of the path needs to be an index in a list or a label key in hostname style.

The other thing I find painful about Datastar signals are the magic about how attributes written something-something in HTML become somethingSomething in JS and all all the snake, camel etc. __modifiers. It's just error prone to work with. Not a great experience.

But overall I still stuck with it so far and am happy with the general idea of HTMX and Alpine functionalities implemented as one and using hypermedia as a general approach. Anything so I can avoid the NodeJS ecosystem really.

When a few RCs back the wire format changed, it was quite a laborious update for me, because using Fiber I can't use the Go SDK and implemented my own. But the wire format clearly changed for the better so it was worth it.

I think the developers are on to something and should keep iterating.

This is awesome. Having a single state for all resources in an environment is critical for keeping all the moving pieces in check and a core design aspect of Kubestack. But the growing state files quickly become a bottleneck. I'm definitely giving this a good test drive. Very excited.

A lot of work that apparently is not valued enough to justify paying for.

You're not wrong. They add miniscule value. But what does that say about the people using these images who are now struggling to replace them?

Everything under internal did discourage me from trying templUI too. What's the reason for it?

I'm working on an application and use Fiber, Templ and Datastar to keep my frontend in Go, like my backend. I'm overall quite happy with this approach.

But Datastar tries to do both, AlpineJS stuff like show/hide dropdow options, as well as HTMX stuff like talk to backend and merge/replace parts of the DOM.

I came across TemplUI a few times while working on this app so far. But always felt the Vanilla JS plus HTMX approach of TemplUI conflicts with Datastar. Too much overlap in different components doing the same stuff for my taste. While at the same time, I spent way too much time converting Tailwind UI components into Tempo. Time I could spend better.

Datastar is quite on the experimental/unstable side of things. And its concept of signals doesn't quite work for my Kubernetes style API resources. So maybe I need to revisit this decision at some point.

What I really like about Datastar and what made me choose it in the first place is how easy it makes using server sent events.

So yeah, exciting times. Still some rough edges I would say. But for me personally I already prefer hypermedia over the predominant React frontends approach.

But is the icon going to be a syringe, a pill or a tombstone?

We've got some overlap on the stack part. But I am more focused on the infra side of platform engineering (including bootstrapping clusters), seems for you it's more app dependencies. Check https://www.kubestack.com and ping me if you're interested in chatting.

Giving teams more insights into their apps at runtime without requiring changes to the apps is as close as one gets to a superpower.

It's funny, as someone proposing frameworks make sense in IaC (Terraform in my case), how the framework/no-framework topic apparently never gets old.

But if you create a configmap to store that label isn't that state? It may be more lightweight than what Terraform or Helm store, but it's still state.

Yes, conditionals and loops in TF are limited and have various annoying and surprising edge cases. But if something is hard to do with the Terraform DSL it's usually a good idea to reconsider if it is really something that one should be doing.

We want infrastructure automation to be boring and just work.

The risk with general purpose programming languages is that people will always find a way to outsmart themselves. Yes, sure, you can use the testing tool chain of the language of your choosing. But it's not like we have figured out to write software without bugs, despite all the awesomeness of modern languages.

Flux, IIRC, uses labels or annotations to do purging. Helm I'd argue falls into the state category with the secrets if uses to track releases.

I do everything with Terraform so I'm not super familiar with either of them. But teams are free to choose their poison.

It's not trivial to get the labels correct to avoid collateral deletions. Also, while it makes sense, I and many teams I consulted with found it rather unintuitive that apply --purge with a label selector will also only update resources with the label. Not all resources that are in the list of resources. Last time I checked it was also still marked experimental and has been for years.

Keeping the tombstones around in the configuration I have to maintain instead of the state the tool maintains for me also increases the effort for me though. So either I have the effort of setting up the remote state and handling some edge cases. Or handling the shortcomings of stateless in my own code base.

Yes, but setting up and handling edge cases of Terraform state causes the effort. Once you have it, storing just IDs or more doesn't make a difference anymore.

This doesn't work unless your infrastructure is entirely static. As soon as you have active control loops like e.g. an autoscaler it will create resources that you don't know about and would then delete.

The delete this approach is imperative though. If you aim to be declarative you need a way for the tool to be able to determine actions necessary to go from current to new desired configuration. You need to store previous applied config somewhere, to be able to determine if something needs purging in a declarative way.

I maintain a Terraform provider for Kubernetes. And one of the main reasons for that is because the Terraform state ensures purging of deleted resources.

Something that kubectl is not capable of. The lastAppliedConfig annotation does not help for purging, because once the manifest has been deleted on disk, there is no way of knowing what to delete from the server. The unusable apply --purge flag is the best example of this issue

I think the state mainly exist to know what has been created in the past but since been deleted from manifests and therefore needs to be purged. The caching/performance argument is rather weak, because Terraform refreshes by default anyway before any operation.

It's a little unfortunate, the canonical URL was picked up. While yes, this was originally posted on thenewstack.io I updated it to the latest versions of the providers and modules and fixed the code examples, which I could not on The New Stack.

The updated version, which I originally posted can be found here: https://dev.to/kubestack/a-better-way-to-provision-kubernete...

Thanks for the kind words. I'm building Kubestack because I believe strongly that frameworks make sense for IaC too and that platform teams need a better DX if they are supposed to deliver a better DX to app teams.

I'm currently helping companies build their Kubernetes platforms using Kubestack. So that's the "business model" for now.

The modules in the catalog, like e.g. ArgoCD, differ from other modules in so far as that they are built automatically from upstream releases. I maintain the Kustomization Terraform provider, which allows integrating native K8s manifests into Terraform and have Kustomize patches, generators etc. available to customize the upstream manifests. The Kustomize overlays can be defined in Terraform through the provider/modules and as a result you can use values from Terraform to configure the K8s manifests without maintaining K8s YAMl in HCL.

More details here: https://www.kubestack.com/framework/documentation/cluster-se...

Regarding Terragrunt I'm not 100% sure. Last time I checked they maintained different environments in different directories and then the CLI copies/symlinks/whatever that into a configuration before it runs Terraform. Kubestack however does use Terraform workspaces (in the TF CLI, not TF Cloud sense) for that purpose. There is just one code base. And modules have inheritance based configuration per environment. I'm not sure how well Terragrunt works with Terraform workspaces. If it does, then it should with Kubestack too.

Edit: added the Terragrunt answer.

I'm following a similar approach with Kubestack. Although for a much smaller use-case, being exclusively focused on building Kubernetes platforms using Terraform.

Your scope sounds more like Gruntwork. How would you say you differentiate?

For me the focus is important because the wider the use-case, the broader the customizations different orgs will require. Focus on a narrow use-case means one can provide more value.

Frameworks on the software development side also are better with a narrower use-case. There's no one size fits all.

Kubestack also has a UI to design your Kubernetes platform and export that to Terraform code. Making it super easy to get started.

https://www.kubestack.com/cloud

Rancher doesn’t generate Terraform code. It further doesn’t have a platform of multiple clusters as it’s core concept. And as a result it can’t provide the same preview, validate and promote GitOps workflow.

More details here: https://www.kubestack.com/framework/documentation/gitops-pro...

Last, Kubestack is native AKS, EKS or GKE. There is no meta control plane in between, like with Rancher.

Kubestack Cloud is a low-code UI to define Kubernetes platforms and export them to production grade Terraform. Architecting a K8s platform is time-consuming and difficult. It gets easier if you've done it before, of course, but then it's little more than just another repetitive task.

A UI can provide a lower entry barrier and allows for quicker iterations. But from a long term maintenance perspective, a UI managed platform is not sustainable. I'm trying to combine the best of both worlds, by having all the benefits of a UI in the beginning, but the power and control of infrastructure as code long-term.

With the Kubestack framework I've been maintaining an open-source Terraform framework, and Kubernetes Terraform provider for ~3 years now. But while the framework provides proven, reusable modules, it still requires writing 100s of lines of Terraform code to call the modules from your root module with the correct configuration.

Kubestack Cloud allows users to define the root module in the UI. It provides guidance on a number of high level architecture decisions, like how many environments and how changes are validated and promoted between these environments. It then lets users drill down to configure cloud providers (AKS, EKS or GKE), node pools and cluster services. Once done, everything can be exported to production grade Terraform code for free.

The generated Terraform code is human-readable and easy to maintain long term, because, again, Kubestack Cloud "just" generates the root module that calls the existing open-source framework modules.

Kubestack Cloud is still in the MVP stage. But give it a try and let me know what you think.

As someone who also learns best by getting my hands dirty, I always liked the ability to pick up an application development framework and get started building a real app while I'm still learning. By accepting the frameworks opinions, I can keep going and decide where I need to diverge once I learned more about the technology and what I really need.

With my Terraform framework for AKS, EKS and GKE I'm trying to bring the same framework benefits to the DevOps world, more specifically to Terraform and Kubernetes.

Check it out: https://www.kubestack.com/

Really cool project. I'll put it on the list of things to integrate with my project Kubestack https://github.com/kbst/terraform-kubestack

Kubestack maintainer here. Happy to answer any questions HN may have.

Congratulations on the launch. This sounds like a great addition to the modern observability stack.

I maintain https://www.kubestack.com, a Terraform GitOps framework to provision managed K8s like EKS, AKS and GKE.

If you're interested to chat, email me. My HN name at the project's .com.