OK what about this: 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.
During a cluster upgrade where you upgrade members one-by-one, how can we control the leader does not move to a Neon SR2 member? > On Jul 18, 2019, at 2:29 PM, Robert Varga <n...@hq.sk> wrote: > > On 18/07/2019 20:52, Luis Gomez wrote: >> >> >>> 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? > > No special steps, local state replica is upgraded on first boot, just as > with any other upgrade in the past. > >>>> 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. > > I would disagree about the playground bit, it certainly did not feel > that way in these parts :) > > I do not believe the upgrade is any riskier than any other upgrade. > > Regards, > Robert > _______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
