Split etcdctl into etcdctl (public API access) & etcdutl (direct surgery on files) #12971
Conversation
ptabor
force-pushed
the
20210514-split-etcdctl
branch
from
5f7cf7d
to
3cc66bf
Compare
|
In general, I like this approach (decoupling server-side dependencies for client-side operation). |
ptabor
force-pushed
the
20210514-split-etcdctl
branch
from
3cc66bf
to
fb8eaee
Compare
|
Thank you for merging in the base. I rebased the PR. |
|
I believe if we make this transition, this should be in 3.5. I am in favor of merging this, as long as @hexfusion @lilic are comfortable, since they are initial 3.5 release managers. |
ptabor
force-pushed
the
20210514-split-etcdctl
branch
from
fb8eaee
to
7f0bde7
Compare
Codecov Report
@@ Coverage Diff @@
## main #12971 +/- ##
===========================================
- Coverage 58.14% 47.06% -11.08%
===========================================
Files 400 393 -7
Lines 32769 31672 -1097
===========================================
- Hits 19053 14908 -4145
- Misses 11807 14876 +3069
+ Partials 1909 1888 -21
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
ptabor
force-pushed
the
20210514-split-etcdctl
branch
3 times, most recently
from
10d8560
to
d35ddb0
Compare
|
@hexfusion I hope that the change is complete, in particular it contains:
|
…ery on files) Motivation is as follows: - etcdctl we only depend on clientv3 APIs, no dependencies of bolt, backend, mvcc, file-layout - etcdctl can be officially supported across wide range of versions, while etcdutl is pretty specific to file format at particular version. it's step towards desired modules layout, documented in: https://etcd.io/docs/next/dev-internal/modules/
ptabor
force-pushed
the
20210514-split-etcdctl
branch
from
30d465c
to
3f7a038
Compare
Thank you for review. I don't expect any changes in the pre-existing functionality of etdctl (except v2 migrate that is gone). The functionality is covered with e2e tests. So I don't think its a risky change. |
|
Overall from a code perspective and dev perspective, this makes perfect sense. 👍 My only concern is that this would be making the user experience a bit more complex, as users would need 3 binaries/tools to run and manage etcd. But we can see how it goes and gather user feedback when end-users start using |
There was a problem hiding this comment.
The etcdctl commands keep being served as they used to, but just print additional warning with recommendation to migrate to etcdutl.
With the above messaging, I feel this change is reasonable. By separating these very admin-specific actions of backing up and restoring state to a separate binary we provider at least basic isolation. The alternative would be RBAC level controls similar to oc adm but since etcd RBAC will probably never be a part of kubernetes 1.x +1.
|
Thank you for quick review. |
|
Highlighted this in the 3.5 blog as well. |
Split etcdctl into etcdctl (public API access) & etcdutl (direct surgery on files)
Motivation is as follows:
This PR defines new binary: etcdutl with following jobs:
(V2) etcdctl backup->etcdutl backup(V3) etcdctl snapshot restore->etcdutl snapshot restore(V3) etcdctl snapshot status->etcdutl snapshot status(V3) etcdctl defrag --date-dir=/..' ->etcdutl defrag --date-dir=/..`(V3) etcdctl migrate-> I decided to decommission that tool as we support migration by 1 minor version... so continous support of V2->V3 sounds too generous (and the code is very subtle),The etcdctl commands keep being served as they used to, but just print additional warning with recommendation to migrate to etcdutl.
This PR is on top of: #12969[rebased]It fullfils one one of the goals from: #12330 (comment)