Are you planning to add any UI in the toolkit ?

[Jojoooo1]

Hi,

I am wondering if you guys are planning to add any UI to the toolkit ?

Thanks a lot for the amazing work.

Jonathan.

[stefanprodan]

We are considering https://backstage.io but none of the FluxCD maintainers have front-end skills.

[torjue]

I'm wondering what people would like to see in a UI? If it's to see the deployment status, you could use something like Statusbay, maybe?

If anyone have some thoughts about what they want to see in a UI, I might make some wireframes, and we can take it from there. Interested in helping out.

[phillebaba]

I feel like the biggest issue with a UI is not the content itself but how authorization is implemented for the UI. Flux enforces access to the cluster through who can access the git repository that is reconciled. It would be nice if the web UI could use the git provider as a source for authorization.

[brpaz]

I can see two main use cases for the UI:

• See the state of the applications deployed in the cluster (Ex: the current deployed version/git commit)
• Be able to deploy a specific build to a particular environment. (Ex: QA team deploying a specific version to staging)

ArgoCD have something similar.

I believe a good first step would be to provide a good API for toolkit. With that, even if the UI is not a priority for the flux team, maybe the community can build something on top.

[brpaz]

ah, you are right ;)

so, imagine the feature that I want be able to deploy a specific build/commit of a particular app via an ui.

I could query the Docker registry to get all the available images for the app and then have the user select one.

That action will do a commit in the flux repository with the updated manifests, referencing the new image. that will trigger the flux reconciliation on the cluster. Then the UI can check the status of the deployment also by using the Kubernetes API directly.

Make sense?

Sounds like a fun side project ;)

[shanesveller]

(Just a rando with their $0.02.) Their imperative, GUI-biased design/documenation ("ClickOps") is actually one of the things that turned me off of ArgoCD as a cluster operator, though I generally appreciated it with my appdev hat on. Conversely, I like this GUI-less facet of (the current design of) Flux 2 / gitops-toolkit, where the only imperative workflows are through kubectl. That's something I appreciated about Concourse as well - it flies in the face of what many IT departments are asking for, but it also serves as a boundary against what I would mostly consider anti-practices. If I could shut off the AWS web console for my whole org, admins included, I would 😁

[brpaz]

@shanesveller Dont Argo CD ui actions, results in updates of the declarative manifests stored in Git?
I understand your points and kind of agree with from a dev point of view, but still, there are valid use cases for a GUI, like, for example, QA Team deploying a specific version of an application to a specific environment for testing purposes.

We could argue that these use cases could be better handled by a third party tool, built on top of Kubernetes API like @hiddeco pointed out, which would then update the Flux manifests in the Git repo and not something built in the flux core.

[shanesveller]

As far as I know ArgoCD is and was incapable of writing back to Git to persist the changes anyone makes through the GUI. IIRC it's just a Kube API client manipulating the CRDs imperatively and that desired state is not captured anywhere else. Last I saw adding Git commits were unique to Flux v1 automation.

[brpaz]

Ok. I thought their UI, worked like a "frontend" to Git/K8s and all operations would result in updates on Git stored manifests. Doesn't make much sense otherwise for a GitOps tool.

My ideas for any Flux GUI would always result in updates to Git manifests which then would trigger Flux workflows. It would work just as a frontend to Git/K8s.

[jpellizzari]

Work has begun on a web UI: #503

[squaremo]

Shall we mark this one as the answer @Jojoooo1? :-)