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

Workflow: List -> Show, and Expand Metadata #6544

Merged
merged 8 commits into from
Aug 25, 2020

Conversation

PrismaPhonic
Copy link
Contributor

This PR renames the List subcommand to Show and expands the metadata to also return TabletControls and whether the master of each shard is currently serving write traffic. This PR also changed the listStreams method to be named ShowWorkflow to fit the new subcommand nomenclature, and makes it public so vitess-operator can use this wrangler method, and expose replication status information in a k8s friendly way.

@PrismaPhonic PrismaPhonic marked this pull request as draft August 6, 2020 07:05
@PrismaPhonic PrismaPhonic marked this pull request as ready for review August 6, 2020 18:36
Copy link
Contributor

@sougou sougou left a comment

Choose a reason for hiding this comment

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

This is forward progress. We still need to get the routing rules. But that can be a separate PR. I'm slightly hesitant about the MasterReplicationStatuses, but understand why, and can't think of something better. I'll let @rohit-nayak-ps also take a look to make sure there are no better alternatives.

@@ -331,8 +361,12 @@ func (wr *Wrangler) getStreams(ctx context.Context, workflow, keyspace string) (
if err != nil {
return nil, err
}

// We set a topo timeout since we contact topo for the shard record.
ctx, cancel := context.WithTimeout(ctx, 10*time.Second)
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd recommend using an existing flag. *topo.RemoteOperationTimeout looks appropriate.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good call, I'll swap it out.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Swapped.

@PrismaPhonic
Copy link
Contributor Author

I've included an expanded ReplicationLocation so we also return source shards and target shards.

go/vt/wrangler/vexec.go Show resolved Hide resolved
go/vt/vtctl/vtctl.go Show resolved Hide resolved
Copy link
Member

@deepthi deepthi left a comment

Choose a reason for hiding this comment

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

Looks good. The only remaining concern is whether we are allowed to change the command name options like this or we should be marking List as deprecated and allowing it as a synonym for Show.
@rohit-nayak-ps we did not explicitly mark VExec and Workflow as experimental in 7.0. What are your thoughts on rename vs deprecation?

…mmand, and changed the command from List to Show.

Signed-off-by: Peter Farr <Peter@PrismaPhonic.com>
Signed-off-by: Peter Farr <Peter@PrismaPhonic.com>
Signed-off-by: Peter Farr <Peter@PrismaPhonic.com>
Signed-off-by: Peter Farr <Peter@PrismaPhonic.com>
Signed-off-by: Peter Farr <Peter@PrismaPhonic.com>
Signed-off-by: Peter Farr <Peter@PrismaPhonic.com>
Signed-off-by: Peter Farr <Peter@PrismaPhonic.com>
… it's a subcommand.

Signed-off-by: Peter Farr <Peter@PrismaPhonic.com>
@PrismaPhonic
Copy link
Contributor Author

I built in accepting list silently. The deprecation examples I found were for full commands. Since these are subcommands I'm not sure if there's a way to formally deprecate as we did with other standalone commands.

Copy link
Member

@enisoc enisoc left a comment

Choose a reason for hiding this comment

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

I don't know this code well enough to approve, but the comments I made earlier are now resolved so I have no objections.

go/vt/vtctl/vtctl.go Show resolved Hide resolved
go/vt/wrangler/vexec.go Show resolved Hide resolved
@@ -2967,7 +2971,7 @@ func commandWorkflow(ctx context.Context, wr *wrangler.Wrangler, subFlags *flag.
if err != nil {
return err
}
if action == "list" || action == "listall" {
if action == "show" || action == "listall" {
Copy link
Member

Choose a reason for hiding this comment

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

Do we not print anything out for show / listall?

Copy link
Member

Choose a reason for hiding this comment

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

@rohit-nayak-ps this doesn't look right. However, it is unrelated to the changes in this PR so I'm going to move this forward.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The printing happens internally actually. From what I can tell this is a way of handling split code paths from subcommands.

Copy link
Contributor

Choose a reason for hiding this comment

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

As Peter replied, show/listall follows a separate path and outputs a json doc. Otherwise we just return rows affected (result of vexec for stop/start/delete workflow)

@deepthi deepthi merged commit 6f1402d into vitessio:master Aug 25, 2020
@askdba askdba added this to the v8.0 milestone Oct 5, 2020
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.

6 participants