-
Notifications
You must be signed in to change notification settings - Fork 10.1k
robustness-test: Migrate experimental-compaction-batch-limit
flag
#19506
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
Draft
kavirajk
wants to merge
1
commit into
etcd-io:main
Choose a base branch
from
kavirajk:kavirajk/migrate-experimental-compaction-batch-limit-robustness-test
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 approach will not work because rendering flags happens before we run the cluster and we never re-render them. There are tests that upgrade/downgrade binary while using same args. The proper solution would be to re-render the flags every time we start binary.
For that to work we we would want to rewrite
EtcdServerProcessConfig
to not includeArgs
field, butArgs
method, however this is pretty complicated rewrite.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.
Thanks @serathius for catching that :)
I'm assuming you are talking this code about upgrade/downgrade the etcd process with newPath/newVersion by using same args. correct?
I like your idea of making
EtcdServerProcessConfig
'sArgs
more dynamic by making it as method instead (keeping the filedargs
as private). So during actual spawning of the process, it will callep.cfg.Args()
and that will return canonical flags based on version derived from it'sep.cfg.ExecPath
. Do that sounds good to you? wdyt?Your concern here is I believe is mostly extra work needed to update it in every places. Or am I missing anything?
One more clarification. Any efficient way to run
e2e-tests
in local? Every time I runmake test-e2e
it takes for ever even to start (and I think we need approval to trigger from CI)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.
Thinking bit more about this.
On the other hand, this is only needed for specific cases in Robustness tests. Making it part of original
EtcdServerProcessConfig
seems bit irrelevant. PlusArgs()
api then need to know the version to return correct Args and in order to extract it from binary path introduce a failure case, that this api has to handle. All feel bit un-necessary to put it inEtcdServerProcessConfig
.Because by general definition of this config, once the it is created, it's Args are fixed for a single binary. It's our use case of downgrade and upgrade in robustness tests makes this problematic. So we can have a
helper(version, args) args
and use it just in robustness tests before spawning the server. Just like the way we do with newExecPath in those tests.I don't know. Just thinking out loud. curious to know what you think :)
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.
Don't think this is specific to robustness tests, but the upgrade/downgrade tests which is one of the scenarios of robustness tests. There are other dedicated upgrade/downgrade e2e tests running.
I was thinking about similar approach as a midpoint. Calling this
helper
in etcdServer.Start to fix the flags just before they are used. I think it's an acceptable midstep, but I would be worried about leaving such hacks for long.