Extending argo-rollout HTTP RESTful capabilities

[fblgit]

It would be nice to have several features in place within the HTTP API:

• More endpoints to fetch structured data
• More abstractions for changes (change replicas, change labels, change annotations... the typical settings that usually are part of a regular lifecycle within operations).
• API Documentation...

If we look into a way to unify how the CLI works and empower its composition/features/etc from the API muscle, that may be a way to focus on the API and at the same time have those features/benefits within the CLI ? wdyt

[jessesuen]

The dashboard wasn't intended to be a full-fledged stable API, but a way to present what the CLI was showing but in UI format. I think we want to reserve the right to break the API over releases to iterate faster on what the dashboard can do. Also, dashboard provides no auth mechanism, and to make it a real API server we would need to consider building in auth.

Is there a reason you prefer Rollout Dashboard API server over say Kubernetes API which could get the same data but with real RBAC?

[fblgit]

scenarios where, for example, each of ur clusters is on an independent network (as well as the k8s API), and only the ingress is exposed to the public.
So if u want to manage a fleet from a single point, u must have connectivity to all the clusters K8s plane which is doable but definitively more messy, extending capabilities on the API looks reasonable for elements like replicas, labels, images, etc.