> On Jul 18, 2019, at 10:53 AM, Robert Varga <n...@hq.sk> wrote:
>
> 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.
What about the upgrade itself, can Neon SR1 upgrade to Neon SR2 seamlessly?
>
>> If so what is the reason for this?
>
> Scalability, as detailed below.
Well yes, I like scalability but not at any price :)
>
>> 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.
Those were the old times where ODL was a playground, at this moment we have
multiple customers using ODL in production so I do not think we can afford a
complicated/risky SR upgrade.
>
> 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
>>
>
_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
