Migrate vtctlclient InitShardMaster => vtctldclient InitShardPrimary

[ajm188]

Description

This implements the InitShardMaster command in the VtctldServer, renamed as InitShardPrimary to take advantage of the easy opportunity to rename without backwards compatibility considerations.

Some other decisions made in this PR to call out:

• I did no refactor or variable renames on the function, because I didn't want to add complications to the initial migration.
• The old version had no tests, including endtoend tests, so I added a couple simple cases. Any further advice on testing is welcome.
• Important - I included the well-known Duration type to handle the --wait-replicas-timeout flag, which requires inclusion of the standard proto definitions that ship with protoc. These usually (and by default I think) end up in /usr/local/include, so I've taken the (possibly naive!) simple step of updating make proto to add that include path. I'd like to talk about ideas about how to ensure this doesn't break existing developer's workflows, and whether this is portable enough. Like, we could, for example, call this good enough and add a note to the proto readme to ensure you have these files in the right path, or we could make the tooling more dynamic.

Related Issue(s)

• RFC: Vtctld Service #7058
• Migrate local examples to vtctldclient #7219

Checklist

• Should this PR be backported?
• Tests were added or are not required
• Documentation was added or is not required

Deployment Notes

None

Impacted Areas in Vitess

Components that this PR will affect:

• Query Serving
• VReplication
• Cluster Management
• Build

[ajm188]

I'm genuinely unsure what the right API here is. Is all we want the stream of updates? Maybe this is a case where we actually want just a stream logutil.Event response 🤔

[deepthi]

I don't know either :) What you have is fine for now and we can fix forward if we decide otherwise.

[doeg]

The golang parts look good to me! Thank you for doing the rename (and adding tests too, so nice!)

You'll fur sure want Planetscale signoff on the rest, of course. 🎉

[deepthi]

I included the well-known Duration type to handle the --wait-replicas-timeout flag, which requires inclusion of the standard proto definitions that ship with protoc. These usually (and by default I think) end up in /usr/local/include, so I've taken the (possibly naive!) simple step of updating make proto to add that include path. I'd like to talk about ideas about how to ensure this doesn't break existing developer's workflows, and whether this is portable enough. Like, we could, for example, call this good enough and add a note to the proto readme to ensure you have these files in the right path, or we could make the tooling more dynamic.

In my local environment, the standard protos are under vitess.io/vitess/dist/vt-protoc-3.6.1/include. That is where bootstrap installs them.

[ajm188]

Working updated make proto:

❯ make proto
Tue Jan 5 19:44:17 EST 2021: Installing minimal dependencies
skipping protoc install. remove /Users/amason/work/vitess/dist/vt-protoc-3.6.1 to force re-install.
/usr/local/bin/etcd
etcd already installed
skipping k3s install. remove /Users/amason/work/vitess/dist/k3s to force re-install.

bootstrap finished - run 'make build' to compile
Tue Jan 5 19:44:57 EST 2021: Compiling proto definitions

[deepthi]

LGTM

[ajm188]

it looks like the new goimports style conflicts with how protoc-gen-go generates files

[ajm188]

Fixes for this in 602dd69 (git hook) and 67ae893 (linter config)

[rohit-nayak-ps]

@ajm188, I reran a flaky test that had failed and now all tests are passing. Is this ready to be merged?

[ajm188]

Yep should be good to go!