> If it is client level configuration, in theory it is possible to have latest > client create v3 ledger while bookies are still running in the older version > right?
Yes, autorecovery would likely just break in this case. > If we go with cluster level, I think using it part of LAYOUT_ZNODE is not clean. > I think we need to have a form of "cluster version number", or even better with a combination of capability/feature bit-map which can dictate the cluster behavior. I used the LAYOUT znode because that is what already exists. If we create another znode for this, /ledgers/CLUSTER for example, then, for consistency, the contents of the layout znode should really be moved into this new znode. But this creates a lot more BC issues than just using the LAYOUT znode. Old versions of the software ignore anything other than the first two lines in LAYOUT. So, it's not clean nor ideal, but it does work well within the constraints of BC. > I am assuming that the tool Ivan is talking about is used for existing > clusters to update the cluster version number. > Otherwise the maxLedgerMetadataFormat is used only for new clusters; that is > fine. The maxLedgerMetadataFormat is only written when writing a new LAYOUT node, so either during metaformat, or when using the proposed tool. When it is absent from the layout node, it defaults to version 2, which matches current behaviour. The important thing for the 4.9 release is that the client can read binary metadata, so that in 4.10 or 4.11, if we add a field to the metadata, then we are able to use it with 4.9 clients and newer. It is only that that point that maxLedgerMetadataFormat comes into play. So, for the sake of getting 4.9 out the door, I propose that we: a. Rollback the 2 changes around max metadata format version. b. Pin serde to use V2 for now. c. Continue this discussion to find the long term solution. -Ivan
