Dashboard: [Proposal] Remove Dashboard Extensions

[vtereso]

NOTE The following proposal discusses potentially removing our past work. This can be a sensitive subject, so please read through the entire proposal before forming an opinion

For background, it was mentioned in a previous meeting that extensions might be the wrong vehicle to accomplish the "additional" functionality we have been looking to "inject" into the dashboard (specifically GitHub webhooks at the moment). While working on the Triggers repository, I realized this same role is filled by Triggers. In short:

• TriggerTemplate - Templates resources to be created (e.g. Create PipelineResources and PipelineRun that uses them)
• TriggerBinding - Instantiates resources in TriggerTemplate using event fields
• EventListener - Wraps TriggerBinding(s) into an addressable endpoint (the event sink)

Using tektoncd/triggers in conjunction with tektoncd/pipeline enables you to easily create full-fledged CI/CD systems where the execution is defined entirely through Kubernetes resources.

Currently, the webhooks extension is utilizing Knative Eventing to handle the addressable bits for webhooks, and in this way, it does quite a bit. In much the same manner, EventListeners will specify an addressable endpoint (that will not require Knative). This ties into the idea that Pipeline+Triggers enable everything to be defined as a resource, which forms a full-fledged CI/CD system. Following this thinking, generating webhooks/events is the only remaining piece of the puzzle. I contend, the best solution, is no solution.

With the benefit of having previously worked on similar products, it seems that extensions in their current form (and likely going forward as well) attempt to recreate the functionality for creating webhooks. I argue, that recreate is the appropriate wording since this functionality already exists elsewhere e.g., GitHub, GitLab, DockerHub, etc. Should someone be familiar with these platforms, there are views that enable them to create webhooks already. With dashboard extensions, we are very much porting the work of others and reskinning it. So, if there is a bug, we are liable to fix it. Worse yet, if full functionality is not ported (not enabling webhooks to all possible events i.e., GitHub/GitLab), we actually have net negative functionality to doing nothing at all. Since we are proposing things be done with extensions, we are in a way revoking the idea that they should be done using the native mechanisms.

Removing extensions is not a matter of laziness, but a realization that an extensions approach is flawed. This approach is forever incomplete because it doesn't have support for X and it introduces more pieces that can potentially fail, which add weight to the dashboard. The main draw of the extensions approach is that it gives the dashboard the perception of being an "all-in-one" solution, but _fundamentally_, it will never include everything. At the same time, using extensions indicates that functionality is lacking. Perhaps there is another potential use case for extensions (not a webhook reskin), but since we do not currently have one (to my knowledge), we should acknowledge the collective baggage extensions are entangled with. It is the responsibility of someone who wants to use tool Y to leverage that tool properly. CodeWind takes this same perspective and empowers people to use the tools they are familiar with.

There is already some discussion on what should be provided to the "core" dashboard and what the role of extensions are. I think we should focus on improving the "core" dashboard and integrating Triggers. At some point, we will refactor the code base to accommodate Triggers; doing so sooner rather than later is to our benefit. With plenty of work to be done in tektoncd/triggers as well as tektoncd/dashboard, forgoing the extension work frees us up to do other valuable work. This will also gives us time to think over some of the questions we still haven't answered. Whatever it may be, it can and should live in the "core" dashboard.

We could very realistically "complete" the dashboard by recognizing the tools around us and leveraging them just as we have done recently by proxying to the Kube API. Since EventListeners provide addressable endpoints, setting up webhooks using Triggers is rightfully free for any vendor versus the current piecemeal extension approach. This approach also gives us the guiding principle that the dashboard should not provide new functionality, but simply act as a gateway.

It goes without saying that removing extensions would remove a lot of hard work done by the team. A lot of people have a stake in what has been done and what is to be delivered and this is not a simple pivot. However, I still believe that long term (maybe even within a months time) removing extensions will be the right move. Ultimately, this all presides over a few assumptions:

• Triggers is delivered as specified
• We discard the current notion of the dashboard as an "all-in-one" solution and transition to a dashboard without extensions
• We adjust our priorities to address this pivot

Regarding the first point, I don't believe anyone has ever questioned the "deliverability" of the Triggers project. If we didn't think it could be done, we wouldn't have invested time into it. Moreover, we contributed much to the design/architecture behind the project so we should be proud to stand by it and believe in it. These other two points are very much in the hands of the team to decide.

[mnuttall]

This proposal is blocked behind https://github.com/tektoncd/experimental/issues/40.

[AlanGreene]

From recent meeting on this topic, this proposal relates to removal of the webhook extension specifically, not the entire extension mechanism.

[a-roberts]

Closing this, we're moving to Triggers as per Vincent's comments in the original post and excellent contributions in that area, no point in leaving this open any more as we've come to a conclusion and there's nothing actionable really

For posterity, we plan that our 0.3.0 release of the Tekton Dashboard/Webhooks Extension will include usage of Triggers instead of our sink written in Go, and we won't be requiring Knative/istio.

There's no intention to remove our generic extension support (as @AlanGreene suggests above, that wasn't really the intention of this issue anyway), and as for removing the webhooks extension in favour of Triggers and perhaps a TriggersUI repository idea, that's a discussion we've not really had/fleshed out yet.