[Hawkular-dev] Rolling upgrades (on Kubernetes)

[Matt Wringe]

For APIs, I think this is possible.

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?

----- Original Message -----
> From: "Heiko W.Rupp" <hrupp at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Friday, 3 March, 2017 4:48:41 AM
> Subject: [Hawkular-dev] Rolling upgrades (on Kubernetes)
> 
> Hey,
> 
> on Kubernetes a common use case (that has been demonstrated by Thomas
> and Juca recently) are rolling upgrades (blue/green, canary, ...) where a
> new version of a service comes into play, gets scaled up and when this
> is scaled up, the old version of the service gets scaled down and eventually
> disappears.

I believe this only one type of scenario, there are other options depending on how your application should behave.

For Cassandra, we want to bring down all the instances and bring up all new versions (which is what we currently do in origin-metrics). The reason being that we want to use the persistent storage from the previous versions. Otherwise we would need to bring up new versions with empty volumes and then wait for the data to transfer from the old versions to the new ones, which is really not what we want.

> It can also happen though that the new version is buggy and the previous
> version gets scaled up again to take the full load until a fix is available.
> 
> We need to make sure to support those rolling upgrades and also the
> rollback to the previous version of a service.
> 
> E.g. if a (No)Sql schema update happens in version N+1, a still
> running instance of version N must not break by it, when N+1
> is rolling out while N is still active. Similarly when N+1 has upgraded
> the schema and the application gets rolled back to version N, it must
> still be able to cope with the upgraded schema version.
> 
> Same applies to APIs, but this is something we have discussed and
> mastered in the past.
> 
> We should perhaps investigate how we can automatically test
> this scenario in our Travis testing.
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>