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

Expose BatchEntryDelete On CLI #4371

Merged
merged 6 commits into from
Aug 29, 2023

Conversation

JU4N98
Copy link
Contributor

@JU4N98 JU4N98 commented Jul 27, 2023

Affected functionality
This PR affects the entry delete on cli.

Description of change
This PR allows:

  • The use of entryID flag multiple times (like selector flag of entry create).
  • The use of the new flag data, which specifies the path to a JSON with the entryIDs to be deleted or just "-" in case that the JSON should be taken from stdin. Follows an example of this JSON:
{
    Ids : ["entry-0", "entry-1"]
}

In both cases, the output is similar to entry create, first the succeeded entry deletions are enumerated and then the failed ones.

Which issue this PR fixes
This PR fixes the issue #4248.

Signed-off-by: JU4N98 <juanpablocabana2@gmail.com>
Signed-off-by: JU4N98 <juanpablocabana2@gmail.com>
Copy link
Member

@evan2645 evan2645 left a comment

Choose a reason for hiding this comment

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

Thank you very much for the contribution @JU4N98! And sorry for the delay on my part

Left a handful of comments, mostly around UX. It leads me to wonder about the output we print ... if folks are providing programmatic input, should we be providing programatic output? What is the path to recovering from a batch delete call where half the requests failed? just thinking out loud ...

entryID string
env *commoncli.Env
printer cliprinter.Printer
entriesIDs StringsFlag
Copy link
Member

Choose a reason for hiding this comment

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

nit, this should probably be

Suggested change
entriesIDs StringsFlag
entryIDs StringsFlag

@@ -40,16 +43,54 @@ func (*deleteCommand) Synopsis() string {
}

func (c *deleteCommand) AppendFlags(f *flag.FlagSet) {
f.StringVar(&c.entryID, "entryID", "", "The Registration Entry ID of the record to delete")
f.Var(&c.entriesIDs, "entryID", "The Registration Entry ID of the record to delete. Can be used more than once")
f.StringVar(&c.path, "data", "", "Path to a file containing deletion JSON (optional). If set to '-', read the JSON from stdin.")
Copy link
Member

Choose a reason for hiding this comment

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

Can we change this flag name to file instead? I think it's a bit clearer that way

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 we should mention something about batch deletion here ... maybe like:

Suggested change
f.StringVar(&c.path, "data", "", "Path to a file containing deletion JSON (optional). If set to '-', read the JSON from stdin.")
f.StringVar(&c.path, "data", "", "Path to a file containing a JSON structure for batch deletion (optional). If set to '-', read from stdin.")

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, i think that file is a better description than data.

@@ -40,16 +43,54 @@ func (*deleteCommand) Synopsis() string {
}

func (c *deleteCommand) AppendFlags(f *flag.FlagSet) {
f.StringVar(&c.entryID, "entryID", "", "The Registration Entry ID of the record to delete")
f.Var(&c.entriesIDs, "entryID", "The Registration Entry ID of the record to delete. Can be used more than once")
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we should allow multiple entryID flags to be passed. It definitely feels like the natural thing to do, but there are other batch endpoints that we'll need to support on CLI (like entry create) that can't be supported in this way ... so to keep things consistent, I feel we should support file-based batch operations only

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, you are right, i didn't notice that entry create doesn't support batch create without a file. I'm going to fix that and keep the file flag.

}

for _, result := range failed {
env.ErrPrintf("Failed to delete entry with ID %s (code: %s, msg: %q)\n",
Copy link
Member

Choose a reason for hiding this comment

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

We should probably print out a newline or two between the success and error lines

codes.Code(result.Status.Code),
result.Status.Message)
}

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 we should print a newline here and another message summarizing, e.g. "Deleted X entries successfully" or "Deleted X entries successfully, but failed to delete Y entries"

}

if len(failed) > 0 {
return errors.New("failed to delete one or more entries")
Copy link
Member

Choose a reason for hiding this comment

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

The CLI command should only error if the call as a whole has errored

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I followed create.go as a guide:

if len(failed) > 0 {

Maybe I misunderstood the code of entry create, but I think that we are doing the same there.

Thanks for the comments!

Copy link
Member

Choose a reason for hiding this comment

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

Ah ok ... consistency is best 😊 thanks for pointing that out

Signed-off-by: JU4N98 <juanpablocabana2@gmail.com>
evan2645
evan2645 previously approved these changes Aug 22, 2023
Copy link
Member

@evan2645 evan2645 left a comment

Choose a reason for hiding this comment

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

Thank you @JU4N98 !!

@evan2645
Copy link
Member

Hey @JU4N98, looks like the Windows unit tests need to be fixed up following changes to help text output: https://github.com/spiffe/spire/actions/runs/5907969226/job/16186854897?pr=4371

Mind patching it so we can get this merged in for 1.8.0?

Signed-off-by: JU4N98 <juanpablocabana2@gmail.com>
Signed-off-by: JU4N98 <juanpablocabana2@gmail.com>
@JU4N98
Copy link
Contributor Author

JU4N98 commented Aug 25, 2023

Hey @JU4N98, looks like the Windows unit tests need to be fixed up following changes to help text output: https://github.com/spiffe/spire/actions/runs/5907969226/job/16186854897?pr=4371

Mind patching it so we can get this merged in for 1.8.0?

hey @evan2645 windows unit test should be fixed right now

@azdagron azdagron merged commit 7a2dcfb into spiffe:main Aug 29, 2023
31 checks passed
@azdagron azdagron added this to the 1.8.0 milestone Aug 29, 2023
@rturner3 rturner3 mentioned this pull request Sep 14, 2023
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.

3 participants