avoid attempting to migrate old configs #17004
Conversation
harshavardhana
changed the title
harshavardhana
changed the title
|
I think maybe we should start with adding MinIO version in format.json. It may be useful to prevent direct upgrade from very old versions when we do very old code clean up. |
There was a problem hiding this comment.
@harshavardhana LGTM, but maybe if we want to just drop support of older config versions to clean up existing code, we can error out after testing on config version (<=33) and tell that the user needs to upgrade to 'RELEASE.2023-04-07T05-28-58Z' first.
We can but it's a bunch of stuff to document @vadmeste and confusing. I would like to avoid that completely. @klauspost I did I will test more, there is one more change missing here. I am removing migration code for credentials based encryption to KMS based. |
harshavardhana
force-pushed
the
do-not-migrate
branch
from
fff95c2
to
f13fabe
Compare
|
re-did the decryption migration as well, we will never need to migrate any old content, we simply read them always as their original entity. But let the WRITEs make sure that we write back in the new format, so we do not need to hold |
harshavardhana
force-pushed
the
do-not-migrate
branch
3 times, most recently
from
352f9b4
to
42028a1
Compare
instead of migration, move them in-memory to a local representation of new config. In all other cases re-initialize if config's missing.
harshavardhana
force-pushed
the
do-not-migrate
branch
from
42028a1
to
fad4edc
Compare
the amount of listing calls this can start can easily overwhelm the server and add to latencies upon startup on a large setup. With the change in the PR minio#17004 - we have no reason to heal or migrate old formats. We can always read and let them be overwritten in time.
The number of listing calls this can start can easily overwhelm the server and add to latencies upon startup on a large setup. With the change in PR minio#17004 - we have no reason to heal or migrate old formats. We can always read and let them be overwritten in time.
The number of listing calls this can start can easily overwhelm the server and add to latencies upon startup on a large setup. With the change in PR minio#17004 - we have no reason to heal or migrate old formats. We can always read and let them be overwritten in time.
The number of listing calls this can start can easily overwhelm the server and add to latencies upon startup on a large setup. With the change in PR minio#17004 - we have no reason to heal or migrate old formats. We can always read and let them be overwritten in time.
The number of listing calls this can start can easily overwhelm the server and add to latencies upon startup on a large setup. With the change in PR minio#17004 - we have no reason to heal or migrate old formats. We can always read and let them be overwritten in time.
The number of listing calls this can start can easily overwhelm the server and add to latencies upon startup on a large setup. With the change in PR minio#17004 - we have no reason to heal or migrate old formats. We can always read and let them be overwritten in time.
Description
avoid attempting to migrate old configs
Motivation and Context
instead of migration, move them in memory to a
local representation of new config.
In all other cases re-initialize if config's
missing.
How to test this PR?
Types of changes
Checklist:
commit-idorPR #here)