On 18/07/2019 19:14, Luis Gomez wrote: > Am I understanding we are introducing a non-compatible change in a Service > Release?
If you define non-compatible as 'you cannot just downgrade software', yes. I do not believe we have an in-place downgrade story -- and daexim remains a valid option. > If so what is the reason for this? Scalability, as detailed below. > I hope there is good one because otherwise this is not a good practice. We have done this multiple times already, probably most well documented are He -> He SR1 and He SR1 -> He SR2. Regards, Robert > > BR/Luis > > >> On Jul 18, 2019, at 8:01 AM, Robert Varga <n...@hq.sk> wrote: >> >> Hello everyone, >> >> this is a notice that CDS/sal-distributed-datastore will ship an >> upgraded data streaming format in Neon SR2 -- something we have not done >> since Lithium. >> >> This change impacts interoperability with previous versions (up to and >> including Neon SR1): >> >> 1) each node will upgrade its local data replica to the new format as >> soon as it performs recovery with Neon SR2 software. The only way to >> undo this upgrade is to restore the node, using mechanisms like daexim. >> >> 2) mixed-version shards will remain operational for as long as no Neon >> SR2 becomes the leader. Once this happens, Neon SR1-and-older slaves >> will not be able to join. >> >> 3) Neon SR2 shards can still service old clients, i.e. applications >> running on Neon SR1-or-older nodes. >> >> 4) Neon SR1 shards can service new clients, i.e. applications running on >> Neon SR2 nodes. >> >> 5) Unversioned users, like netconf-topology-singleton request routing >> and cluster-wide RPCs, are not affected by this change >> >> This break in compatibility is redeemed by the new streaming format >> being both faster and smaller -- as detailed here: >> https://pantheon.tech/opendaylight-neon-sr1-sr2/ >> >> Sodium release train also has these changes, with the notable difference >> that unversioned endpoints use the new streaming format. >> >> Regards, >> Robert >> >> >> _______________________________________________ >> release mailing list >> rele...@lists.opendaylight.org >> https://lists.opendaylight.org/mailman/listinfo/release >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev