[Hawkular-dev] Rolling upgrades (on Kubernetes)

[Matt Wringe]

----- Original Message -----
> From: "John Sanda" <jsanda at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Friday, 3 March, 2017 2:18:39 PM
> Subject: Re: [Hawkular-dev] Rolling upgrades (on Kubernetes)
> 
> 
> 
> 
> 
> On Mar 3, 2017, at 11:54 AM, Heiko W.Rupp < hrupp at redhat.com > wrote:
> 
> On 3 Mar 2017, at 16:54, Matt Wringe wrote:
> 
> 
> 
> But how do we handle the situations where we want to go from Cassandra
> 3.x to Cassandra 4.x? Or what happens when we need to update
> components when those components themselves don't support this type of
> rollback?
> 
> I did not say this is easy :)
> 
> Let me construct a case to illustrate this.
> 
> In version N we have a column that stores a string in the form
> "tenantId:metricid". Now we decide for N+1 that this is not
> good and we need to split that in two separate columns.
> 
> In a traditional way we would do the split and also remove the
> old single column. Here a rollback is not possible.
> 
> If we change this to keep the old column around and the two
> new ones we are safe for version N+1, but as there may be
> still version N containers around we may end up with inconsistencies
> when version N updates an item and N+1 already has split that row.
> 
> Here version N+1 would potentially need to read/write from both
> scenarios and also update both (if the old one still exists, see below).
> This allows rolling back.
> 
> Version N+2 could then drop the old "tenantId:metricid" column
> and only operate on the split columns.
> 
> Heavier updates like C* version 3.x to 4.x can probably really not
> be done without downtime - especially when they require massive
> migrations of Gigabytes of data.
> But still in this case the Metrics frontend code could work against
> both versions of C* and redundantly store data in both while slowly
> migrating data over. Reads could then still go to the old code by
> default until the migration is complete.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> As far as I know rolling upgrades of Cassandra with a major version change is
> well supported, and rolling upgrades is pretty common among Cassandra users.
> Here is the scenario I am not sure we could handle without downtime. We want
> to make make a schema change that involves something introduced in the new
> version of Cassandra, e.g., SASI index.

Yeah, its not the rolling upgrades I think we will run into problems with, its the downgrade when someone wants to revert back to the previous version that might cause problems.

> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>