[Enhancement Proposal] appset list-applications and list-applications --local

[DerekTBrown]

[Enhancement] appset list-applications [--local]

Summary

• At PR-time, there is currently no way to identify the set of applications that a particular appset will generate before deployment. An issue discussing this is roughly outlined here.
• This proposal would introduce a new gRPC method to the appset service. The method would take as input an ApplicationSet and would return a limited set of metadata about the Applications that would be generated, such as the application name and namespace.

Motivation

• Users want to be able to develop CI validations for changes to appsets.
• With a list of changed applications, users can trigger app diff on changed applications.

Goals

• Provide an interface and CLI command to list all applications in a local appset.
• Provide an interface and CLI command to list all applications in a local appset that have changed since the deployed version of the appset.

Non-Goals

• Rendering and returning the full application from the appset (this poses security risks).
• Creating a diff between the rendered application in the local and deployed appsets (this can be built with existing functionality).

Proposal

Introduce a new interface:

        message ApplicationSetListApplicationsRequest {
          // the applicationsets's name
	  string name = 1;
	  // The application set namespace. Default empty is argocd control plane namespace
	  string appsetNamespace = 2;
        }
        
	message ApplicationSetListApplicationsApp {
	     // the application's name
             string name = 1;
             // the application's namespace
             string appNamespace = 2;
             // a hash of the `Application` object.
             string appHash = 3;
	}
	
	message ApplicationSetListApplicationsResponse {
	   // the generated apps
           repeated ApplicationSetListApplicationsApp applications = 1;
	}
	
	 message ApplicationSetListApplicationsLocalRequest {
          	github.com.argoproj.argo_cd.v2.pkg.apis.application.v1alpha1.ApplicationSet applicationset = 1;
         }
	
	rpc ListApps (ApplicationSetListApplicationsRequest) returns (ApplicationSetListApplicationsResponse) {
		option (google.api.http).get = "/api/v1/applicationsets/{name}/applications";
	}
	
	rpc ListAppsLocal (ApplicationSetListApplicationsLocalRequest) returns (ApplicationSetListApplicationsResponse) {
		option (google.api.http).get = "/api/v1/applicationsets/list_local";
	}

Use cases

1. A user can detect the presence of duplicate application names in a diff by listing the applications that would be generated, and comparing to live apps in ArgoCD.

2. A user could ensure that validation is performed on a per-application basis before a change to an appset is landed.

[agaudreault]

From what I understand, the ListApps would return the list of applications of a current ApplicationSet. This seems doable because the ApplicationSet has a list of the Apps in it's status, but ot's currently only ffor progressive sync. So the CLI could return results from there. Or add a new list.

The tricky part is for the local manifest. I think we would have to execute the Reconcile function in a kind of dry-run/memory mode to return the result. So the CLI would most likely need to do a call to the applicationset controller (I dont think the controller has an API) or the server would have to call a library, but then I am not sure it is guaranteed that it has enough permission/access to call the logic.

@crenshaw-dev I wanted to start implementing this. Do you have any input on the implementation? I think having an API on the applicationSet controller is maybe the best idea since it is starting to be more integrated natively in Argo.

[crenshaw-dev]

@agaudreault-jive excited you're looking at this!

I feel like I'd prefer to use libraries instead of an API, since the argocd-server already has access to all the same resources/secrets as the appset controller, and the overhead of creating and maintaining a new gRPC API is non-trivial. But I'm not super opinionated on that point, just a first reaction.

I do think that we will need careful RBAC rules in place to avoid folks using this "dry run" feature to access things they shouldn't have access to. Maybe require applicationsets, update access to do a dry run?

[agaudreault]

Closed by #16781