verifa / horizon Goto Github PK

Create an Account watcher that automatically provisions default Roles and RoleBindings for that account.

This could be part of some "tutorials" or something.

We can get some inspiration from Kubernetes admission webhooks:

https://book.kubebuilder.io/cronjob-tutorial/webhook-implementation

If the auth package supported a Roles(...) method to get the list of roles for a user (e.g. based on groups and role bindings) this could be attached to the UserInfo and used by a web UI to hide/show elements, for example.

Currently the store does not check whether an accounts exists or not when creating objects.

Something similar to Terraform's lifecycle prevent destroy, to add an extra layer of protection for critical objects.

https://developer.hashicorp.com/terraform/tutorials/state/resource-lifecycle#prevent-resource-deletion

Currently Account sensitive information, like NATS NKeys for creating users, is stored directly in the Account.status.

Move this to a secret, a bit like Kubernetes ServiceAccounts work.

The greetings example does not have an HTTP handler. Add one.

This is fairly straightforward to implement, but the implications on server-side apply and managed fields needs to be carefully considered.

E.g. if a user applies an object (therefore managing those fields), if the mutator then adds some fields, who owns those fields?

Right now the reconcile loop happens in a Go routine, and there is nothing to block and wait for it to finish.

Reconcile loops do important stuff, so we should sit and wait for them to finish.

Implement something like a sync.WaitGroup in the ctlr.Stop() method, or similar.

nice system architecture with Cue and NATS. Kind of perfect light system

htmx or htmz based GUI would be nice. If you have a Issue / Epic for it I can take a shot at it.

htmz is an iframe hack: https://github.com/Kalabasa/htmz

In the Greetings demo, the extension link results in 404 error because the file doesn't exist.

Return an operation result from an apply, such as: Updated, Created, NoChange, Conflict.

Objects will not just be created. They will likely be mutated afterwards.

Hence it makes a lot of sense that creating an object also uses server-side apply managed fields.

Writing reconcile logic always requires serious head scratching. In some cases, you simply want to separate the Create from the Update from the Delete.

It would be possible to provide some basic construct for doing Create/Update/Delete operations on objects, as an alternative to a Reconciler.

How this could work requires some thought.