On Wed, Dec 19, 2018 at 9:11 PM Ivan Kelly <iv...@apache.org> wrote: > > 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. > +1 > > -Ivan >
