Apache Geode board report (DRAFT FOR YOUR REVIEW)

[Dave Barnes]

Please respond with changes & additions by COB Friday, May 8.
See the "bragging points" at the bottom.  Publish and Prevail, y'all!
Thanks,
Dave

## Description:
The mission of Apache Geode is the creation and maintenance of software
related
to a data management platform that provides real-time, consistent access to
data-intensive applications throughout widely distributed cloud
architectures.

## Issues:
296 issues opened in JIRA, past quarter (-16% decrease)
226 issues closed in JIRA, past quarter (-26% decrease)

Given the worldwide impact of the Covid-19 pandemic
disruption to our community's work routines, we feel these figures,
though lower than those of the previous reporting period, reveal
an engaged and productive development community.

## Membership Data:
Apache Geode was founded 2016-11-15 (3 years ago)
There are currently 109 committers and 54 PMC members in this project.
The Committer-to-PMC ratio is roughly 7:4.

Community changes, past quarter:
- Alexander Murmann was added to the PMC on 2020-03-26
- Joris Melchior was added to the PMC on 2020-03-22
- Mark Hanson was added to the PMC on 2020-03-26
- Joris Melchior was added as committer on 2020-03-19
- Mario Kevo was added as committer on 2020-03-23

## Project Activity:
- version 1.12.0 was released on 2020-03-31
 This release included improvements to the management REST API,
 .NET and C++ native clients, client/server security, and error recovery.
- version 1.13 release is under way

## Community Health:
The Apache Geode dev and issues mailing lists both experienced
 upticks in discussion traffic, up 15% and 44%, respectively, in Q1.

The number of JIRA tickets opened and closed remained robust, though
 down 16% and 26%, respectively, from the previous quarter. Points of
 emphasis included error recovery improvements, API extensions, and
 compatibility to accommodate containers such as Kubernetes and BOSH.

In February, community member Jason Huynh posted an article
entitled "Apache Geode as a remote Gradle Build Cache"
(
https://jasonhuynh.blogspot.com/2020/02/apache-geode-as-remote-gradle-build.html
).
In March, Jason posted "Publishing Apache Geode Metrics to Wavefront"
(https://medium.com/@huynhja/
publishing-apache-geode-metrics-to-wavefront-6e9a6cf5992b)
along with an accompanying video (https://youtu.be/BDZh-FLkDTg).

Community member Juan Jose Ramos posted an article in March
entitled "Geode Distributed Sequences"
(https://medium.com/@jujoramos/geode-distributed-sequences-12626251d5e3),
and another in April, "The Command Region Pattern"
(https://medium.com/@jujoramos/the-command-region-pattern-14bc49594eca).

In April, community member Barry Oglesby published "Remove Unused
PdxTypes from an Apache Geode Distributed System"
(
https://medium.com/@boglesby_2508/remove-unused-pdxtypes-from-an-apache-geode-distributed-system-5a4f0e199e34
).

Re: [DISCUSS] Geode Redis API Improvements

[Darrel Schneider]

Experimental features are subject to change or removal. No guarantees are
made of backwards compatibility.

On Thu, May 7, 2020 at 2:53 PM Donal Evans  wrote:

> Looks good to me. Fixing broken implementation and providing reliable HA
> can only be a good thing. My only concern is the backwards compatibility
> issue, but I don't know if we make any guarantees regarding that for
> experimental features, so it may be a non-issue.
>
> On Thu, May 7, 2020 at 8:35 AM Raymond Ingles  wrote:
>
> > Just a quick nudge - we set a deadline for comments for tomorrow. Anyone
> > had a chance to look this over yet? Thanks!
> >
> > On Thu, Apr 30, 2020 at 2:09 PM Raymond Ingles 
> wrote:
> >
> > > Hi all,
> > >
> > > The current Redis API support in Geode has been marked experimental
> for a
> > > couple years and has several bugs and inconsistencies compared to
> native
> > > Redis. We created a RFC for updating the Geode Redis API support, to
> > > address issues in the implementation, improve performance and add High
> > > Availability support.
> > >
> > > Please review and comment by 5/8/2020.
> > >
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Geode+Redis+API+Improvements
> > >
> > > Thanks!
> > >
> >
>

Re: [DISCUSS] Geode Redis API Improvements

[Donal Evans]

Looks good to me. Fixing broken implementation and providing reliable HA
can only be a good thing. My only concern is the backwards compatibility
issue, but I don't know if we make any guarantees regarding that for
experimental features, so it may be a non-issue.

On Thu, May 7, 2020 at 8:35 AM Raymond Ingles  wrote:

> Just a quick nudge - we set a deadline for comments for tomorrow. Anyone
> had a chance to look this over yet? Thanks!
>
> On Thu, Apr 30, 2020 at 2:09 PM Raymond Ingles  wrote:
>
> > Hi all,
> >
> > The current Redis API support in Geode has been marked experimental for a
> > couple years and has several bugs and inconsistencies compared to native
> > Redis. We created a RFC for updating the Geode Redis API support, to
> > address issues in the implementation, improve performance and add High
> > Availability support.
> >
> > Please review and comment by 5/8/2020.
> >
> >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Geode+Redis+API+Improvements
> >
> > Thanks!
> >
>

Re: [PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13

[Ju@N]

Thanks all for the replies.
The fix has been back ported to support/1.12 [1] and support/1.13 [2]
already.
Best regards.

[1]:
https://github.com/apache/geode/commit/5a3a24e4724ba7278bc2f9482d25302ede964319
[2]:
https://github.com/apache/geode/commit/193a98a1975a2df417e50755d7badd320c7cb8af


On Thu, 7 May 2020 at 19:13, Dave Barnes  wrote:

> Looks like you have the votes, Juan.
> Go ahead and contribute this fix to support/1.13 and support/1.12.
> Thanks,
> Dave
> Geode 1.13 release manager
>
> On Thu, May 7, 2020 at 10:44 AM Eric Shu  wrote:
>
> > +1
> >
> >
> > On Thu, May 7, 2020 at 10:22 AM Jianxia Chen  wrote:
> >
> > > +1
> > >
> > > On Thu, May 7, 2020 at 7:47 AM Ju@N  wrote:
> > >
> > > > Hello devs,
> > > >
> > > > I'd like to propose bringing GEODE-8071 [1] to the *support/1.12* and
> > > > *support/1.13* branches.
> > > > The bug was introduced in Geode 1.8.0 and, long story short, prevents
> > > > locators from gracefully shutting down whenever a rebalance operation
> > is
> > > > launched from gfsh (doesn't matter whether the rebalance is
> successful
> > or
> > > > not).
> > > > The fix has been merged into develop through commit
> > > > d8e86cb720c054b154a16cc88fee88e73db709f3 [2].
> > > > Best regards.
> > > >
> > > > [1]: https://issues.apache.org/jira/browse/GEODE-8071
> > > > [2:]
> > > >
> > > >
> > >
> >
> https://github.com/apache/geode/commit/d8e86cb720c054b154a16cc88fee88e73db709f3
> > > >
> > > > --
> > > > Ju@N
> > > >
> > >
> >
>


-- 
Ju@N

Re: [PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13

[Dave Barnes]

Looks like you have the votes, Juan.
Go ahead and contribute this fix to support/1.13 and support/1.12.
Thanks,
Dave
Geode 1.13 release manager

On Thu, May 7, 2020 at 10:44 AM Eric Shu  wrote:

> +1
>
>
> On Thu, May 7, 2020 at 10:22 AM Jianxia Chen  wrote:
>
> > +1
> >
> > On Thu, May 7, 2020 at 7:47 AM Ju@N  wrote:
> >
> > > Hello devs,
> > >
> > > I'd like to propose bringing GEODE-8071 [1] to the *support/1.12* and
> > > *support/1.13* branches.
> > > The bug was introduced in Geode 1.8.0 and, long story short, prevents
> > > locators from gracefully shutting down whenever a rebalance operation
> is
> > > launched from gfsh (doesn't matter whether the rebalance is successful
> or
> > > not).
> > > The fix has been merged into develop through commit
> > > d8e86cb720c054b154a16cc88fee88e73db709f3 [2].
> > > Best regards.
> > >
> > > [1]: https://issues.apache.org/jira/browse/GEODE-8071
> > > [2:]
> > >
> > >
> >
> https://github.com/apache/geode/commit/d8e86cb720c054b154a16cc88fee88e73db709f3
> > >
> > > --
> > > Ju@N
> > >
> >
>

Re: [PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13

[Eric Shu]

+1


On Thu, May 7, 2020 at 10:22 AM Jianxia Chen  wrote:

> +1
>
> On Thu, May 7, 2020 at 7:47 AM Ju@N  wrote:
>
> > Hello devs,
> >
> > I'd like to propose bringing GEODE-8071 [1] to the *support/1.12* and
> > *support/1.13* branches.
> > The bug was introduced in Geode 1.8.0 and, long story short, prevents
> > locators from gracefully shutting down whenever a rebalance operation is
> > launched from gfsh (doesn't matter whether the rebalance is successful or
> > not).
> > The fix has been merged into develop through commit
> > d8e86cb720c054b154a16cc88fee88e73db709f3 [2].
> > Best regards.
> >
> > [1]: https://issues.apache.org/jira/browse/GEODE-8071
> > [2:]
> >
> >
> https://github.com/apache/geode/commit/d8e86cb720c054b154a16cc88fee88e73db709f3
> >
> > --
> > Ju@N
> >
>

Re: [PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13

[Jianxia Chen]

+1

On Thu, May 7, 2020 at 7:47 AM Ju@N  wrote:

> Hello devs,
>
> I'd like to propose bringing GEODE-8071 [1] to the *support/1.12* and
> *support/1.13* branches.
> The bug was introduced in Geode 1.8.0 and, long story short, prevents
> locators from gracefully shutting down whenever a rebalance operation is
> launched from gfsh (doesn't matter whether the rebalance is successful or
> not).
> The fix has been merged into develop through commit
> d8e86cb720c054b154a16cc88fee88e73db709f3 [2].
> Best regards.
>
> [1]: https://issues.apache.org/jira/browse/GEODE-8071
> [2:]
>
> https://github.com/apache/geode/commit/d8e86cb720c054b154a16cc88fee88e73db709f3
>
> --
> Ju@N
>

Re: [PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13

[Owen Nichols]

+1

> On May 7, 2020, at 10:11 AM, Jinmei Liao  wrote:
> 
> +1
> 
> On Thu, May 7, 2020 at 9:26 AM Donal Evans  wrote:
> 
>> +1
>> 
>> From: Dick Cavender 
>> Sent: Thursday, May 7, 2020 8:52 AM
>> To: dev@geode.apache.org 
>> Subject: Re: [PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13
>> 
>> +1
>> 
>> On Thu, May 7, 2020 at 7:47 AM Ju@N  wrote:
>> 
>>> Hello devs,
>>> 
>>> I'd like to propose bringing GEODE-8071 [1] to the *support/1.12* and
>>> *support/1.13* branches.
>>> The bug was introduced in Geode 1.8.0 and, long story short, prevents
>>> locators from gracefully shutting down whenever a rebalance operation is
>>> launched from gfsh (doesn't matter whether the rebalance is successful or
>>> not).
>>> The fix has been merged into develop through commit
>>> d8e86cb720c054b154a16cc88fee88e73db709f3 [2].
>>> Best regards.
>>> 
>>> [1]:
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8071data=02%7C01%7Cdoevans%40vmware.com%7Cf6695e01cedc47f5fb5308d7f29eae55%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244635652121432sdata=pc%2BpNBYlK6M1QP%2BTBH4GLRO2JYwhuDp%2BdbY1UVS4BHo%3Dreserved=0
>>> [2:]
>>> 
>>> 
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fcommit%2Fd8e86cb720c054b154a16cc88fee88e73db709f3data=02%7C01%7Cdoevans%40vmware.com%7Cf6695e01cedc47f5fb5308d7f29eae55%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244635652121432sdata=f008tzyxlF7X%2FDwPhoMg4Z6n%2Foc6BtkkMo8ea5T2Xjk%3Dreserved=0
>>> 
>>> --
>>> Ju@N
>>> 
>> 
> 
> 
> -- 
> Cheers
> 
> Jinmei

Re: [PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13

[Jinmei Liao]

+1

On Thu, May 7, 2020 at 9:26 AM Donal Evans  wrote:

> +1
> 
> From: Dick Cavender 
> Sent: Thursday, May 7, 2020 8:52 AM
> To: dev@geode.apache.org 
> Subject: Re: [PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13
>
> +1
>
> On Thu, May 7, 2020 at 7:47 AM Ju@N  wrote:
>
> > Hello devs,
> >
> > I'd like to propose bringing GEODE-8071 [1] to the *support/1.12* and
> > *support/1.13* branches.
> > The bug was introduced in Geode 1.8.0 and, long story short, prevents
> > locators from gracefully shutting down whenever a rebalance operation is
> > launched from gfsh (doesn't matter whether the rebalance is successful or
> > not).
> > The fix has been merged into develop through commit
> > d8e86cb720c054b154a16cc88fee88e73db709f3 [2].
> > Best regards.
> >
> > [1]:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8071data=02%7C01%7Cdoevans%40vmware.com%7Cf6695e01cedc47f5fb5308d7f29eae55%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244635652121432sdata=pc%2BpNBYlK6M1QP%2BTBH4GLRO2JYwhuDp%2BdbY1UVS4BHo%3Dreserved=0
> > [2:]
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fcommit%2Fd8e86cb720c054b154a16cc88fee88e73db709f3data=02%7C01%7Cdoevans%40vmware.com%7Cf6695e01cedc47f5fb5308d7f29eae55%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244635652121432sdata=f008tzyxlF7X%2FDwPhoMg4Z6n%2Foc6BtkkMo8ea5T2Xjk%3Dreserved=0
> >
> > --
> > Ju@N
> >
>


-- 
Cheers

Jinmei

Re: [PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13

[Donal Evans]

+1

From: Dick Cavender 
Sent: Thursday, May 7, 2020 8:52 AM
To: dev@geode.apache.org 
Subject: Re: [PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13

+1

On Thu, May 7, 2020 at 7:47 AM Ju@N  wrote:

> Hello devs,
>
> I'd like to propose bringing GEODE-8071 [1] to the *support/1.12* and
> *support/1.13* branches.
> The bug was introduced in Geode 1.8.0 and, long story short, prevents
> locators from gracefully shutting down whenever a rebalance operation is
> launched from gfsh (doesn't matter whether the rebalance is successful or
> not).
> The fix has been merged into develop through commit
> d8e86cb720c054b154a16cc88fee88e73db709f3 [2].
> Best regards.
>
> [1]: 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8071data=02%7C01%7Cdoevans%40vmware.com%7Cf6695e01cedc47f5fb5308d7f29eae55%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244635652121432sdata=pc%2BpNBYlK6M1QP%2BTBH4GLRO2JYwhuDp%2BdbY1UVS4BHo%3Dreserved=0
> [2:]
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fcommit%2Fd8e86cb720c054b154a16cc88fee88e73db709f3data=02%7C01%7Cdoevans%40vmware.com%7Cf6695e01cedc47f5fb5308d7f29eae55%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244635652121432sdata=f008tzyxlF7X%2FDwPhoMg4Z6n%2Foc6BtkkMo8ea5T2Xjk%3Dreserved=0
>
> --
> Ju@N
>

Re: [PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13

[Dick Cavender]

+1

On Thu, May 7, 2020 at 7:47 AM Ju@N  wrote:

> Hello devs,
>
> I'd like to propose bringing GEODE-8071 [1] to the *support/1.12* and
> *support/1.13* branches.
> The bug was introduced in Geode 1.8.0 and, long story short, prevents
> locators from gracefully shutting down whenever a rebalance operation is
> launched from gfsh (doesn't matter whether the rebalance is successful or
> not).
> The fix has been merged into develop through commit
> d8e86cb720c054b154a16cc88fee88e73db709f3 [2].
> Best regards.
>
> [1]: https://issues.apache.org/jira/browse/GEODE-8071
> [2:]
>
> https://github.com/apache/geode/commit/d8e86cb720c054b154a16cc88fee88e73db709f3
>
> --
> Ju@N
>

Re: Update of SSLParameterExtension interface

[Jacob Barrett]

I have some concerns with using Properties in public APIs. The use of 
Properties is not strongly typed. I can’ tell from one property to the next 
what the type is. I can’t get compile time errors is the type is wrong. I don’t 
know what goes into a Property based on the interface or any magic and IDE 
could produce. I can’t get compile time failures because I am missing or using 
an invalid property. The Property object is synchronized, so I am using this 
object to get values frequently I am not serializing all threads through this 
object. 

Let’s take this time, where we are already fixing a broken API to do it right. 
Build into the API a configuration class that has what we think we need right 
now. We can add to that class over time as needed.

-Jake


> On May 4, 2020, at 12:00 PM, Bruce Schuchardt  wrote:
> 
> I guess that would have to go into the 1.13 branch as well.  This changes the 
> public API but I think we should do it.  The current API isn't usable since 
> it refers to a non-public interface.
> 
> On 5/4/20, 9:31 AM, "Mario Ivanac"  wrote:
> 
>Hi all,
> 
>after comments that SSLParameterExtension interface has an init() method 
> that takes a DistributionConfig as an argument (which is internal class),
>new solution is proposed to replace DistributionConfig with Properties.
> 
> 
>New PR is created with new proposal 
> https://github.com/apache/geode/pull/5040,
>and also RFC is updated with new proposal 
> https://cwiki.apache.org/confluence/display/GEODE/Introduction+of+SSL+Parameter+Extension
>Introduction of SSL Parameter Extension - Geode - Apache Software 
> Foundation
>Hit enter to search. Help. Online Help Keyboard Shortcuts Feed Builder 
> What’s new
>cwiki.apache.org
> 
>Should we cherry-picked this PR into the support/1.12 branch?
> 
>Regards,
>Mario
> 
> 
> 

Pull Requests

[Jacob Barrett]

Hey All,

While it appears to be common practice for us to all pay attention to and burn 
down pull requests on the primary apache/geode repository. It would be really 
great if you all could take time to look at some of our other repositories and 
help out with PRs. The apache/geode-native repository has a small number of 
people that tend to watch and comment on PRs. If you have any C++ skills at all 
your help would be nice. Even if you don’t have the C++ skills at least 
commenting on things you can comment on would be helpful. Regardless of 
language, things like variable naming, readability, testings, etc., all need to 
remain consistent across all our repositories.

Thanks,
Jake

Re: RFC - Logging to Standard Out

[Jacob Barrett]

Done!

> On May 5, 2020, at 4:35 PM, Aaron Lindsey  wrote:
> 
> I think this could be moved to "In Development" since there is consensus. I
> created a JIRA for it: https://issues.apache.org/jira/browse/GEODE-8077

Re: [DISCUSS] Geode Redis API Improvements

[Raymond Ingles]

Just a quick nudge - we set a deadline for comments for tomorrow. Anyone
had a chance to look this over yet? Thanks!

On Thu, Apr 30, 2020 at 2:09 PM Raymond Ingles  wrote:

> Hi all,
>
> The current Redis API support in Geode has been marked experimental for a
> couple years and has several bugs and inconsistencies compared to native
> Redis. We created a RFC for updating the Geode Redis API support, to
> address issues in the implementation, improve performance and add High
> Availability support.
>
> Please review and comment by 5/8/2020.
>
>
> https://cwiki.apache.org/confluence/display/GEODE/Geode+Redis+API+Improvements
>
> Thanks!
>

[PROPOSAL]: GEODE-8071 to support/1.12 and support/1.13

[Ju@N]

Hello devs,

I'd like to propose bringing GEODE-8071 [1] to the *support/1.12* and
*support/1.13* branches.
The bug was introduced in Geode 1.8.0 and, long story short, prevents
locators from gracefully shutting down whenever a rebalance operation is
launched from gfsh (doesn't matter whether the rebalance is successful or
not).
The fix has been merged into develop through commit
d8e86cb720c054b154a16cc88fee88e73db709f3 [2].
Best regards.

[1]: https://issues.apache.org/jira/browse/GEODE-8071
[2:]
https://github.com/apache/geode/commit/d8e86cb720c054b154a16cc88fee88e73db709f3

-- 
Ju@N

Re: About Geode rolling downgrade

[Alberto Gomez]

Hi again,


Considering Geode does not support online rollback for the time being and since 
we have the need to rollback even a standalone system, we were thinking on a 
procedure to downgrade Geode cluster tolerating downtime, but without a need to:

  *   spin another cluster to sync from,
  *   do a restore or
  *   import data snapshot.



The procedure we came up with is:

  1.  First step - downgrade locators:

 *   While still on the newer version, export cluster configuration.
 *   Shutdown all locators. Existing clients will continue using their 
server connections. New clients/connections are not possible.
 *   Start new locators using the old SW version and import cluster 
configuration. They will form a new cluster. Existing client connections should 
still work, but new client connections are not yet possible (no servers 
connected to locators).

  1.  Second step – downgrade servers:

 *   First shutdown all servers in parallel. This marks the beginning of 
total downtime.
 *   Now start all servers in parallel but still on the new software 
version. Servers connect to the cluster formed by the downgraded locators. When 
servers are up, downtime ends. New client connections are possible. The rest of 
the rollback should be fully online.
 *   Now per server:

   i.  Shutdown 
it, revoke its disk-stores and delete its file system.

 ii.  Start 
server using old SW version. When up, server will take over cluster 
configuration and pick up replicated data and partitioned regions buckets 
satisfying region redundancy (essentially will hold exactly the same data 
previous server had).



The above has some important prerequisites:

  1.  Partitioned regions have redundancy and region configuration allows 
recovery as described above.
  2.  Clients version allows connection to new and old clusters - i.e. clients 
must not use newer version at the moment the procedure starts.
  3.  Geode guarantees cluster configuration exported from newer system can be 
imported into older system. In case of incompatibility I expect we could even 
manually edit the configuration to adapt it to the older system but it is a 
question how new servers will react when they connect (in step 2b).
  4.  Geode guarantees communication between peers with different SW version 
works and recovery of region data works.



Could we have opinions on this offline procedure? It seems to work well but 
probably has caveats we do not see at the moment.



What about prerequisites 3 and 4? It is valid in upgrade case but not sure if 
it holds in this rollback case.


Best regards,


-Alberto G.


From: Anilkumar Gingade 
Sent: Thursday, April 23, 2020 12:59 AM
To: geode 
Subject: Re: About Geode rolling downgrade

That's right, most/always no down-time requirement is managed by having
replicated cluster setups (Disaster-recovery/backup site). The data is
either pushed to both systems through the data ingesters or by using WAN
setup.
The clusters are upgraded one at a time. If there is a failure during
upgrade or needs to be rolled back; one system will be always up
and running.

-Anil.





On Wed, Apr 22, 2020 at 1:51 PM Anthony Baker  wrote:

> Anil, let me see if I understand your perspective by stating it this way:
>
> If cases where 100% uptime is a requirement, users are almost always
> running a disaster recovery site.  It could be active/active or
> active/standby but there are already at least 2 clusters with current
> copies of the data.  If an upgrade goes badly, the clusters can be
> downgraded one at a time without loss of availability.  This is because we
> ensure compatibility across the wan protocol.
>
> Is that correct?
>
>
> Anthony
>
>
>
> > On Apr 22, 2020, at 10:43 AM, Anilkumar Gingade 
> wrote:
> >
> >>> Rolling downgrade is a pretty important requirement for our customers
> >>> I'd love to hear what others think about whether this feature is worth
> > the overhead of making sure downgrades can always work.
> >
> > I/We haven't seen users/customers requesting rolling downgrade as a
> > critical requirement for them; most of the time they had both an old and
> > new setup to upgrade or switch back to an older setup.
> > Considering the amount of work involved, and code complexity it brings
> in;
> > while there are ways to downgrade, it is hard to justify supporting this
> > feature.
> >
> > -Anil.
>
>