-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
*: Split etcd into 3 modules: server, client (c), integration #12204
Conversation
afd2e89
to
bbcfb34
Compare
f30a5f4
to
9e2fcaf
Compare
More about motivation and considerations in modularization of etcd doc |
@ptabor Can we have separate commits? It's hard to review :) |
@gyuho I will split when I'm back from vacations in a week. Interesting changes. go to:
I would appreciate if could take a look at: ./test file and the overall directory layout structure in the meantime. |
/ - will contain server code /c - will contain client code /integration - will contain integration tests code
The commit is moving files needed for the client code. The files are having only imports changed.
The files got moved and the imports got changed.
This logic is solelly used by etcdctl and depends on implementation details (files layout) of server so connot be kept in the client module.
pkg/logutil is in general dependency of client code, but zap_raft has dependencies on server code and is used solelly within the server.
@gyuho I splitted the change as requested. PTAL |
@gyuho @jpbetz @jingyih @wenjiaswe - please review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've done a first pass review.
Re: Naming the client module c
. For the casual observer, or anyone reading go.mod files, it won't be obvious what this is. If there is good rationale on why we can't just call it client
? If this was already discussed somewhere can we link to the discussion in description? Else can summarize alternatives and naming decision somewhere for posterity? The community will ask why we chose the name we did since this is a high visibility change that impacts users for the long term.
@@ -0,0 +1,2 @@ | |||
# git mod vendor will regenerate the directory | |||
vendor/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should be consistent with how we vendor across the etcd project.
Historically we've checked in the /vendor directory so that the project can be built after a git clone without requiring a go mod fetch. Kubernetes does the same thing. My rough understanding is that it offers some advantages in build time (no go mod pulls). If we do decide to change how we vendor, we should probably do it separate from this PR.
Also, If we're going to have multiple vendor directories, this is going to get more complicated. Can we have one vendor directory that all the modules share? Also, we might need tooling like kubernetes has to manage multiple go.mod files sanely (update-vendor.sh, verify-vendor.sh, pin-dependency.sh)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved the cleanup of vendor directory to a separate PR: #12279
I performed there multiple tests and:
- neither "go mod fetch" nor "go mod vendor" is needed. "go build ..." or "./build" works of fresh clients (no $GOPATH)
- Performance is highly improved. Even if we wipe $GOPATH/pkg, the "./build" takes <10s without vendor and
~34s with vendor. I think that go mod must download pre-built or pre-analyzed artifacts to have such great improvement. - Multiple modules within etcd or in different repositories would share the same pre-loaded modules.
Please let me know in the PR whether I'm missed any benefits / scenarios to keep the ./vendor dir.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very promising. By removing vendor we are adding a build dependency on proxy.golang.org (and requiring a network connection to pull from it). This seems acceptable to me given that the proxy is quite mature at this point. I've added a comment about this on #12279 and nudged a couple maintainers. We can continue the conversation over there.
echo "could not find protoc 3.7.1, is it installed + in PATH?" | ||
exit 255 | ||
fi | ||
#if [[ $(protoc --version | cut -f2 -d' ') != "3.7.1" ]]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re-enable or add comment explaining why we don't need this any more?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re-enabled. Good catch.
Would be happy to add a comment why we need this.
Lookled over changes 3.7..3.12, and there seems nothing go related: https://github.com/protocolbuffers/protobuf/releases?before=v3.7.1.
I assume its to guarantee better repeatability for patch releases.
@@ -50,8 +50,8 @@ USERPKG=${PKG:-} | |||
COVER=${COVER:-"-cover"} | |||
|
|||
# Hack: gofmt ./ will recursively check the .git directory. So use *.go for gofmt. | |||
IGNORE_PKGS="(vendor/|etcdserverpb|rafttest|gopath.proto|v3lockpb|v3electionpb)" | |||
INTEGRATION_PKGS="(integration|tests/e2e|contrib|functional)" | |||
IGNORE_PKGS="(^|/)(vendor|etcdserverpb|rafttest|gopath.proto|v3lockpb|v3electionpb|c)(/|$)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think really want to exclude the entire c
module from gofmt.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixing...
"${REPO_PATH}/contrib/raftexample") | ||
INTEGTESTPKG=("${REPO_PATH}/contrib/raftexample") | ||
go test -mod=mod -timeout "${USERTIMEOUT}" -v -cpu "${TEST_CPUS}" "${RUN_ARG}" "$@" "${INTEGTESTPKG[@]}" | ||
( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: indentation of this line is odd, doesn't match 195
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixing...
@@ -27,7 +27,7 @@ github.com/dustin/go-humanize | |||
github.com/etcd-io/gofail/runtime | |||
# github.com/fatih/color v1.7.0 | |||
## explicit | |||
# github.com/gogo/protobuf v1.2.1 | |||
# github.com/gogo/protobuf v1.2.1 => github.com/gogo/protobuf v1.2.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems unnecessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixing...
@@ -228,3 +256,6 @@ gopkg.in/yaml.v2 | |||
# sigs.k8s.io/yaml v1.1.0 | |||
## explicit | |||
sigs.k8s.io/yaml | |||
# github.com/gogo/protobuf => github.com/gogo/protobuf v1.2.1 | |||
# go.etcd.io/etcd/c/v3 => ./c | |||
# go.etcd.io/etcd/integration/v3 => ./SHOULD_NOT_BE_DEPENDENCY |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting. How does this line get added to modules.txt? Is it added manually or do we have some way to make sure it gets added automatically?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a consequence of: 053201d#diff-37aff102a57d3d7b797f152915a6dc16R54 in go.mod
replace (
go.etcd.io/etcd/integration/v3 => ./SHOULD_NOT_BE_DEPENDENCY
)
A little bit a hack, but very explicit when the error happens.
I wrote ideas and motivation for different naming options in this section of the doc: Happy to change them - agree that current choice might be sub-optimal. @gyuho @jpbetz @jingyih @cfc4n et al. - please comment (here or in the doc) |
|
+1 Thanks for cleaning this up @ptabor |
/cc @philips |
Thank you. I will let you know when its ready for another pass. I'm creating smaller PRs like:
That are preparing this refactoring, so having them merged is a dependency. |
@ptabor what's the status of this PR? Can I help? |
Cool, thanks for the update! |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions. |
I'm considering this effort done. |
*: Split etcd into 3 modules:
This was discussed an community meeting on 2020/07/30. The goal is to
minimize number of dependencies that our network customers needs to
carry and clearly define packets that needs to stay backward compatible.
Main files moves into ./c
Clients:
./{client,clientv3}
API protos:
./etcdserver/api/membership/membershippb
./etcdserver/api/v3rpc/rpctypes
./auth/authpb
./mvcc/mvccpb
./etcdserver/etcdserverpb
Integration tests:
./client{v3}/{integration,concurrency} -> ./integration/client{v3}/{integration,concurrency}
Tested using:
Futher steps to consider:
Please see/comment the attached doc