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

add support for optional sync flag to block on async ops till completion #70

Open
wants to merge 14 commits into
base: main
Choose a base branch
from

Conversation

anekkanti
Copy link
Member

No description provided.

app/request.go Outdated Show resolved Hide resolved
app/request.go Outdated Show resolved Hide resolved
app/request.go Outdated Show resolved Hide resolved
app/request.go Outdated Show resolved Hide resolved
app/request.go Outdated
if err := PrintProto(status); err != nil {
return err
}
fmt.Sprintf("started %s operation with requestId='%s', to monitor its progress use command: `%s request get -r '%s'`", operation, status.RequestId, AppName, status.RequestId)
Copy link
Member

Choose a reason for hiding this comment

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

[Nit] is this going to break anybody who has written scripts based on the output of commands from before? That could be annoying, maybe we don't print this to standard out or we have an option to suppress this?

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 we could check if stdout isatty and also have an env flag for disabling this (non-interactive mode maybe?)

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 like the idea to use isatty, to disable such messages.
I think we can leverage such mechanism to hide other messaging we do.

Let me address these in the next PR.

}

func NewRequestCommand(getRequestClientFn GetRequestClientFn) (CommandOut, error) {

var c *RequestClient
return CommandOut{Command: &cli.Command{
Name: "request",
Usage: "Manage asynchronous requests",
Usage: "Manage requests",
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if long-running requests could more clear for the user.

Copy link
Member Author

Choose a reason for hiding this comment

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

long-running seems technically wrong, because some write operations we do will be very quick.

Copy link
Contributor

Choose a reason for hiding this comment

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

Async operation makes sense as it is inline with the new APIs

@@ -60,14 +85,108 @@ func NewRequestCommand(getRequestClientFn GetRequestClientFn) (CommandOut, error
Flags: []cli.Flag{
&cli.StringFlag{
Name: "request-id",
Usage: "The request-id of the asynchronous request",
Usage: "The request-id of the request",
Copy link
Contributor

Choose a reason for hiding this comment

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

The request's ID could be less circular, or Unique identifier of the request

Copy link
Member Author

Choose a reason for hiding this comment

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

actually we should probably change this to operation id. to keep things in consistent with the new apis
will address this in the next PR

Copy link
Contributor

Choose a reason for hiding this comment

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

That makes sense

Usage: "wait for the request complete",
Aliases: []string{"w"},
Flags: []cli.Flag{
&cli.StringFlag{
Copy link
Contributor

Choose a reason for hiding this comment

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

We could define this as a var since it is a repeated flag

Copy link
Member Author

Choose a reason for hiding this comment

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

fixed.

func (c *RequestClient) waitOnRequest(ctx *cli.Context, operation string, requestID string) error {

ticker := time.NewTicker(time.Millisecond)
timer := time.NewTimer(ctx.Duration(RequestTimeoutFlagName))
Copy link
Contributor

Choose a reason for hiding this comment

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

Defer calls for the ticker and timer are missing.

Copy link
Member Author

Choose a reason for hiding this comment

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

thanks, fixed.

app/request.go Outdated
fmt.Fprintf(writer, "waiting for request with id='%s' to finish, current state: %s\n",
requestID, request.State_name[int32(status.State)])
}
ticker.Reset(time.Second * time.Duration(status.CheckDuration.Seconds))
Copy link
Contributor

Choose a reason for hiding this comment

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

If status.CheckDuration.Seconds is 0 ticker.Reset will panic. Should we set a minimum value to ensure that this never happens and ensure that the ticker fires less often than 1ms?

Copy link
Member Author

Choose a reason for hiding this comment

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

Good catch, fixed.

app/account.go Outdated
return err
}
return r.HandleRequestStatus(ctx, "disable metrics", status)

Copy link
Contributor

Choose a reason for hiding this comment

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

nit: extra space

app/request.go Outdated
if err := PrintProto(status); err != nil {
return err
}
fmt.Sprintf("started %s operation with requestId='%s', to monitor its progress use command: `%s request get -r '%s'`", operation, status.RequestId, AppName, status.RequestId)
Copy link
Contributor

Choose a reason for hiding this comment

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

+1 we could check if stdout isatty and also have an env flag for disabling this (non-interactive mode maybe?)

@@ -10,7 +10,7 @@ import (
)

const (
AutoConfirmFlagName = "auto_confirm"
AutoConfirmFlagName = "auto-confirm"
Copy link
Contributor

Choose a reason for hiding this comment

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

I think should keep this as auto_confirm since folks are using it now. That or we could print a helpful message asking them to use auto-confirm instead - but that could break some use-cases folks have.

Copy link
Member Author

Choose a reason for hiding this comment

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

added an alias to the flag, to support both.

app/request.go Outdated
for {
select {
case <-timer.C:
return fmt.Errorf("timed out waiting for request to complete, namespace=%s, requestID=%s, timeout=%s",
Copy link
Contributor

Choose a reason for hiding this comment

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

For some requests namespace could be empty right? If so I think we should conditionally add the field.

Copy link
Member Author

Choose a reason for hiding this comment

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

yup, removed namespace.

app/request.go Outdated
return fmt.Errorf("request was cancelled: %s", status.FailureReason)
}
if operation != "" {
fmt.Fprintf(writer, "waiting for %s operation (requestId='%s') to finish, current state: %s\n",
Copy link
Contributor

Choose a reason for hiding this comment

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

id='%s' to keep it consistent with the other log statements?

Copy link
Member Author

Choose a reason for hiding this comment

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

fixed.

if err := PrintProto(status); err != nil {
return err
}
fmt.Printf(
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should allow these messages to be silenced for scripted use cases which expect JSON output on success. Perhaps isatty gets us this in the follow-up PR? Unsure if it covers all cases or not.

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 plan on addressing this comprehensively in the next PR.
In the next PR i hope to add a tcld version checker, which notifies the user to update their tcld when it gets old.

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