Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: create cli commands for ApplicationSet #9584

Merged
merged 20 commits into from
Sep 14, 2022
Merged

feat: create cli commands for ApplicationSet #9584

merged 20 commits into from
Sep 14, 2022

Conversation

ishitasequeira
Copy link
Member

@ishitasequeira ishitasequeira commented Jun 5, 2022

Note on DCO:

If the DCO action in the integration test fails, one or more of your commits are not signed off. Please click on the Details link next to the DCO action for instructions on how to resolve this.

Checklist:

  • Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this does not need to be in the release notes.
  • The title of the PR states what changed and the related issues number (used for the release note).
  • I've included "Closes [ISSUE #]" or "Fixes [ISSUE #]" in the description to automatically close the associated issue.
  • I've updated both the CLI and UI to expose my feature, or I plan to submit a second PR with them.
  • Does this PR require documentation updates?
  • I've updated documentation as required by this PR.
  • Optional. My organization is added to USERS.md.
  • I have signed off all my commits as required by DCO
  • I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
  • My build is green (troubleshooting builds).

@ishitasequeira ishitasequeira changed the title feat: create cli commands for ApplicationSet [NOT READY FOR REVIEW] feat: create cli commands for ApplicationSet Jun 5, 2022
@ishitasequeira ishitasequeira changed the title [NOT READY FOR REVIEW] feat: create cli commands for ApplicationSet feat: create cli commands for ApplicationSet Jun 5, 2022
@ishitasequeira ishitasequeira changed the title feat: create cli commands for ApplicationSet feat: create cli commands for ApplicationSet [WIP] Jun 7, 2022
@ishitasequeira ishitasequeira changed the title feat: create cli commands for ApplicationSet [WIP] [WIP] feat: create cli commands for ApplicationSet Jun 7, 2022
@codecov
Copy link

codecov bot commented Jun 7, 2022

Codecov Report

Merging #9584 (b329e4d) into master (9fac0f6) will decrease coverage by 0.38%.
The diff coverage is 17.30%.

@@            Coverage Diff             @@
##           master    #9584      +/-   ##
==========================================
- Coverage   45.69%   45.31%   -0.39%     
==========================================
  Files         234      236       +2     
  Lines       28508    28827     +319     
==========================================
+ Hits        13027    13063      +36     
- Misses      13694    13973     +279     
- Partials     1787     1791       +4     
Impacted Files Coverage Δ
applicationset/controllers/clustereventhandler.go 69.56% <ø> (ø)
applicationset/generators/cluster.go 77.90% <ø> (ø)
applicationset/generators/duck_type.go 68.62% <ø> (ø)
...licationset/generators/generator_spec_processor.go 61.64% <ø> (ø)
applicationset/generators/git.go 85.96% <ø> (ø)
applicationset/generators/list.go 62.50% <ø> (ø)
applicationset/generators/matrix.go 70.73% <ø> (ø)
applicationset/generators/merge.go 59.04% <ø> (ø)
applicationset/generators/pull_request.go 42.85% <ø> (ø)
applicationset/generators/scm_provider.go 35.23% <ø> (ø)
... and 19 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@ishitasequeira ishitasequeira changed the title [WIP] feat: create cli commands for ApplicationSet feat: create cli commands for ApplicationSet Jul 22, 2022
@ishitasequeira ishitasequeira marked this pull request as ready for review July 22, 2022 12:59
@ishitasequeira ishitasequeira requested review from alexmt and jannfis July 25, 2022 06:40
Copy link
Member

@crenshaw-dev crenshaw-dev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I think the big question we have to answer is: should we require all write-type ApplicationSet API requests to have an un-templated spec.template.spec.project field, or can we accept templated Project fields?

I think when @leoluz and @ishitasequeira and @jgwest and I discussed it last, we had settled on disallowing write-type API requests when the AppSet Project field was templated. But I think we can eliminate that requirement.

My proposal:

  1. Before each RBAC check, run fasttemplate over the Project field and replace each template with an asterisk.
  2. Perform the RBAC check for the now-templated project fields.

For example, suppose I have RBAC like this:

p, appset-dev-maintainers, applicationsets, update, *-dev/*, allow

If a user tries to update an AppSet like this:

metadata:
  name: apis-appset
spec:
  template:
    spec:
      project: "{{path[0]}}-dev"

Then the following RBAC check would happen:

*-dev/apis-appset # passes because it matches the first rule

I don't think this would be too much additional code, and I think it would make the API support for ApplicationSets much more powerful. Thoughts?

@crenshaw-dev
Copy link
Member

After chatting with Leo... ignore my last comment, I think that can be introduced in a later PR. For now, let's just reject AppSet API requests where the project field is templated.

@crenshaw-dev
Copy link
Member

The other comment I had was that maybe we should just skip the Application RBAC checks and instead document very thoroughly that granting write capabilities on applicationsets grants the ability to do a bunch of things with applications by proxy.

Copy link
Member

@crenshaw-dev crenshaw-dev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ran into a few issues while testing the CLI.

@crenshaw-dev crenshaw-dev dismissed their stale review August 19, 2022 19:07

Going on vacation

@ishitasequeira ishitasequeira added this to the v2.5 milestone Aug 25, 2022
Copy link
Member

@jannfis jannfis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First round of code review, just looking at the code. I have not checked this out and tested locally.

}

func readAppset(yml []byte, appsets *[]*argoprojiov1alpha1.ApplicationSet) error {
yamls, _ := kube.SplitYAMLToString(yml)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if the second return value is of type error, but if it is, is there any reason we ignore it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I was checking if the yaml has been sent or not and sending an error before it reaches here would suffice the check. But I guess after re-evaluating I feel return an error makes sense. I will update this.

Comment on lines 152 to 146
project, err := s.validateAppSet(ctx, appset)
if err != nil {
return nil, fmt.Errorf("error validating ApplicationSets: %w", err)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be slightly modified, because in it's current form, it would allow enumeration of AppProjects without proper permissions.

In s.validateAppSet(), it is tried to retrieve the AppProject from the K8s API referenced in the ApplicationSet resource. If this is not found, it will be returned to the caller without having checked proper privileges before.

I think it would make sense to:

  • Refactor validateAppSet to return the project name instead of the project
  • Perform the permissions check using this string, instead of the AppProject resource
  • After this has been validated, get the AppProject from the API in this function

return fmt.Sprintf("%s/%s", appSet.Spec.Template.Spec.GetProject(), appSet.ObjectMeta.Name)
}

func RunCommand(command v1alpha1.Command) (string, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this used for? And where?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was using this for my prior approach. I missed removing this part of the code. Will remove it, thanks.

@@ -90,6 +109,21 @@ func FilterByName(apps []argoappv1.Application, name string) ([]argoappv1.Applic
return items, status.Errorf(codes.NotFound, "application '%s' not found", name)
}

// FilterAppSetsByName returns an applicationset
func FilterAppSetsByName(appsets []argoappv1.ApplicationSet, name string) ([]argoappv1.ApplicationSet, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at this function, I'm wondering why it returns a slice, when there can be either one or none results?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am using the same object newItems everywhere. First in FilterAppSetsByName and then for FilterAppSetsByProjects. FilterAppSetsByName would give one, but if q.name is empty, it would not enter that condition and directly move to FilterAppSetsByProjects

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, using a list here is convenient... but I think the List method shouldn't even accept a name "filter" (since the user should probably just use the Get endpoint).

Copy link
Member

@crenshaw-dev crenshaw-dev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're introducing a new resource, we should add a note to the 2.4->2.5 upgrade notes warning people that the meaning of * in the resource column of their RBAC CSV is being expanded. The note can follow the model of the one for the new exec resource in 2.4: https://github.com/argoproj/argo-cd/blob/master/docs/operator-manual/upgrading/2.3-2.4.md#configure-rbac-to-account-for-new-exec-resource

@crenshaw-dev
Copy link
Member

Conditions are pretty verbose for applicationsets. I wonder if we should trim down what we report in the wide format.

$ dist/argocd appset list
NAME       NAMESPACE  PROJECT  SYNCPOLICY  CONDITIONS                                                                                                                                                                                                                                                                                                                                                                       REPO                                     PATH                                                          TARGET
guestbook  argocd     default  nil         [{ErrorOccurred Successfully generated parameters for all Applications 2022-09-08 20:05:18 -0400 EDT False ApplicationSetUpToDate} {ParametersGenerated Successfully generated parameters for all Applications 2022-09-08 20:05:18 -0400 EDT True ParametersGenerated} {ResourcesUpToDate ApplicationSet up to date 2022-09-08 20:05:18 -0400 EDT True ApplicationSetUpToDate}]  https://github.com/argoproj/argo-cd.git  applicationset/examples/list-generator/guestbook/{{cluster}}  HEAD

@crenshaw-dev
Copy link
Member

The get output is a bit misleading, without the true/false field. Makes it look like an error occurred, when it did not:

$ dist/argocd appset get guestbook
Name:               guestbook
Project:            default
Server:             {{url}}
Namespace:          guestbook
Repo:               https://github.com/argoproj/argo-cd.git
Target:             HEAD
Path:               applicationset/examples/list-generator/guestbook/{{cluster}}
SyncPolicy:         <none>

CONDITION            MESSAGE                                                 LAST TRANSITION
ErrorOccurred        Successfully generated parameters for all Applications  2022-09-08 20:05:18 -0400 EDT
ParametersGenerated  Successfully generated parameters for all Applications  2022-09-08 20:05:18 -0400 EDT
ResourcesUpToDate    ApplicationSet up to date                               2022-09-08 20:05:18 -0400 EDT

@crenshaw-dev
Copy link
Member

crenshaw-dev commented Sep 9, 2022

@ishitasequeira I opened a PR with some of the small issues I noticed while testing today. Overall, things are looking very good.

Main thing is adding k8s RBAC so the server deployment can manage appsets on behalf of the user.

https://github.com/ishitasequeira/argo-cd/pull/3

@ishitasequeira
Copy link
Member Author

The get output is a bit misleading, without the true/false field. Makes it look like an error occurred, when it did not:

$ dist/argocd appset get guestbook
Name:               guestbook
Project:            default
Server:             {{url}}
Namespace:          guestbook
Repo:               https://github.com/argoproj/argo-cd.git
Target:             HEAD
Path:               applicationset/examples/list-generator/guestbook/{{cluster}}
SyncPolicy:         <none>

CONDITION            MESSAGE                                                 LAST TRANSITION
ErrorOccurred        Successfully generated parameters for all Applications  2022-09-08 20:05:18 -0400 EDT
ParametersGenerated  Successfully generated parameters for all Applications  2022-09-08 20:05:18 -0400 EDT
ResourcesUpToDate    ApplicationSet up to date                               2022-09-08 20:05:18 -0400 EDT

I agree. I think we should add true/false fields as well here. I will add them.

@ishitasequeira
Copy link
Member Author

Conditions are pretty verbose for applicationsets. I wonder if we should trim down what we report in the wide format.

$ dist/argocd appset list
NAME       NAMESPACE  PROJECT  SYNCPOLICY  CONDITIONS                                                                                                                                                                                                                                                                                                                                                                       REPO                                     PATH                                                          TARGET
guestbook  argocd     default  nil         [{ErrorOccurred Successfully generated parameters for all Applications 2022-09-08 20:05:18 -0400 EDT False ApplicationSetUpToDate} {ParametersGenerated Successfully generated parameters for all Applications 2022-09-08 20:05:18 -0400 EDT True ParametersGenerated} {ResourcesUpToDate ApplicationSet up to date 2022-09-08 20:05:18 -0400 EDT True ApplicationSetUpToDate}]  https://github.com/argoproj/argo-cd.git  applicationset/examples/list-generator/guestbook/{{cluster}}  HEAD

I was wondering if we could show only conditions having true as value. WDYT?

@ishitasequeira
Copy link
Member Author

@ishitasequeira I opened a PR with some of the small issues I noticed while testing today. Overall, things are looking very good.

Main thing is adding k8s RBAC so the server deployment can manage appsets on behalf of the user.

ishitasequeira#3

Thanks @crenshaw-dev for the PR. I will go through it and merge the changes.

ishitasequeira and others added 19 commits September 9, 2022 14:17
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: CI <michael@crenshaw.dev>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: CI <michael@crenshaw.dev>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Copy link
Member

@crenshaw-dev crenshaw-dev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, thanks @ishitasequeira for putting so much work into this!

@jannfis do you want to give it another pass before merging?

@renperez-cpi
Copy link

@ishitasequeira thank you for this. do you know when this pr will be merged? would love to give this a spin :)

Copy link
Member

@jannfis jannfis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks @ishitasequeira!

And thanks @crenshaw-dev for giving me opportunity to look over it again!

@jannfis jannfis merged commit e53ab49 into argoproj:master Sep 14, 2022
ashutosh16 pushed a commit to ashutosh16/argo-cd that referenced this pull request Oct 7, 2022
* feat: add applicationset cli commands

Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

* squashed commits and rebased with master

Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

* addressed comments

Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

* fix lint errors

Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

* Retrigger CI pipeline

Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

* Retrigger CI pipeline

Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

* feat: add applicationset cli commands

Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

* addressed comments

Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

* fix lint errors

Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

* Retrigger CI pipeline

Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

* Retrigger CI pipeline

Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

* Addressed PR comments

Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

* removed duplicate imports

Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

* fix CI errors

Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

* address PR comments

Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

* add k8s RBAC, docs tweaks

Signed-off-by: CI <michael@crenshaw.dev>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

* rebase master branch

Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

* Addressed PR coments

Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

* remove unnecessary fields, add docs

Signed-off-by: CI <michael@crenshaw.dev>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

* fix unit test

Signed-off-by: ishitasequeira <ishiseq29@gmail.com>

Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: CI <michael@crenshaw.dev>
Co-authored-by: CI <michael@crenshaw.dev>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants