rctl / kubefront Goto Github PK

Add Ingress implementation for dashboard and its own view.

Workers are now user-wide, so that a user can only see their own workers. The benefit of having this system wide is that users don't risk concurrency issues between different users. That would be nice to have.

This should be made after #3, since it may apply to workers as well. User should only see workers that are operating on objects that they can access.

Permissions are controlled on an endpoint level, which is convenient at first (no extra mechanisms has to be written for each new endpoint to allow for fine-tuned permissions). But k8s is highly focused on per namespace permissions and RBAC. Can both be implemented to replace the endpoint level permissions?

Maybe we can have namespace level roles instead?

Allow user to create new users if they have the appropriate permission to do so. Add visibility properties to UI components to hide components that use routes that the user is not authorised to use.

At the current moment, collections are updated whenever a view that requirers them is loaded. So when you go into /pods the pods collection is reloaded. This means that clicking around in the menu can cause some unnecessary full refreshes. This beats the purpose of having a good Pub/Sub solution.

One idea is to have the state be loaded when the frontend in initialised in the browser and then track changes for all collections, even if they are not rendered on screen. This will put higher traffic load on the upstream and when initialising the frontend but less traffic when someone navigates in the UI. Which is better?

Can we remove the database? Is there a possibility for us to use the k8s API to store accounts (such as in secrets). Requiring a database is a bit stupid, it creates unnecessary overhead for system.

Make sure that removing the database does not remove future flexibility.

Pod deletion worker does not use the new fully qualified ID, to better and faster allow for identification of entity it should have a fully qualified ID. Also, this removes the risk of a pods being accidentally mixed with other resources. The FQID would be pods/:namespace/:name.

Investigate if there is a possibility to run multiple instances of kubefront. This would require us to setup a sync of workers (which is the only stateful part of kubefront instances).

When events are triggered in submodules routes.go (where the watcher lives for each resource type) it seems like the resource sometimes returns as nil which causes the WebSocket upstream to crash.

The better solution to this is to also add a recover to WebSocket handling, a crash in upstream should never cause panic in the entire backend.