elek commented on pull request #1973:
URL: https://github.com/apache/ozone/pull/1973#issuecomment-801749647
>> Can you please help with more specific, technical questions?
> Upgrades. Not just client->server compat, also downgrade concerns. E.g. if
the new ReplicationConfig message is in the OM ratis log, will the old software
fail after downgrades? Secondly if the new configuration introduces new
functionality, we must ensure it is not used until upgrade is finalized. We
either bring it through the upgrade framework or think of some other way.
Thanks for the question, it's a very good and important one. I think we
should differentiate between backward-compatibility on RPC and
backward-compatibility related to persistence.
On RPC we don't have any issue, as t's the question of the
serialization/de-serialization code. That code can read information from both
of the fields (old replicationFactor and new RatisReplicationConfig) as I am
pretty sure that we can't remove any field we can just start the deprecate
process. We should support the existing replicationFactor until Ozone 2.0.
The persistence side is slightly more tricky as we should be sure that we
persist the old field, at least until the metadata version is upgraded. That
can be handled by the upgrade framework when it's ready to use (or we can just
always fill the legacy field until a while)
>> Was there a design note about these details of this index based approach?
Perhaps I missed it. I am okay to have this be part of the jira description
also.
Please note that this PR doesn't include anything related to the index based
approach. Please continue the discussion about indexes in #2055. This PR is
purely about `ReplicationConfig`.
(Note: you can find the design docs about both topics on the parent EC Jira)
> Will the clients send the old ReplicationFactor message in perpetuity?
Just the old clients. Server-side can check both the fields to support both
old and actual field. This should be done until Ozone 2.0.
>> I think sharing some initial POC code can help this discussion.
> It is very hard to tell from just the proto changes what direction we are
going in. This is one instance in which a more complete patch with a short
design note will help give reviewers a more complete picture.
Totally agree, and providing more code is already suggested by @swagle. And
as I wrote in the earlier comments, you can find some example code in #2010
where you can find the details of serialization/de-serialization (full SCM is
not refactor as it's blocked by this discussion, but it has code for all the
important parts...)
Design thoughts can be found in EC v3 design doc.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
