I have installed the Dragonfly Operator version v1.1.3
, which supports Dragonfly version v1.19.0
, on a Kubernetes cluster and created a dragonfly cluster with two replicas.
Now I am going to upgrade the Operator version to v1.1.6
, which supports Dragonfly version v1.20.1
.
My question is simple.
Will the operator automatically upgrade the existing dragonfly instances or do I need to set an annotation or something on the CRD?
I can’t seem to find any documentation on the upgrade process supported by the operator…
I tested it and it seems that the operator will upgrade the dragonfly instances in the case where no tag is defined in CRD for the dragonfly instance and the operator is upgraded which has support for a newer version.
E.g. Upgrade operator to v1.1.6
and the Dragonfly instance(s) are upgraded to v1.20.1
.
I haven’t tested defining a tag on the Dragonfly CRD.
Thanks for trying it out! The Dragonfly Operator supports configuring a specific version. See more details here.
Hi, everyone, I have just upgraded to operator 1.1.7.
I have also explicitly set the image version tag on my instance to 1.21.3 (it was previously 1.20.1) and then called kubectl apply, but the pods do not restart automatically. I would like to upgrade each instance individually one at a time in order to prevent service disruption, how can I accomplish that?
apiVersion: dragonflydb.io/v1alpha1
kind: Dragonfly
...
spec:
image: "docker.dragonflydb.io/dragonflydb/dragonfly:v1.21.3"
replicas: 2
snapshot:
...
thx
@lsamaciel_70556
When you change the image tag, and apply it (and kubectl shows as updated), We should automatically trigger a rollout of the Dragonfly Instance which is done one by one by default.
Can you share the logs of the Operator (on why this did not happen), alogn with what kubectl shows the resource as kubectl describe dragonfly/<name>
1 Like
Also check if underlying sts (with the same name) is updated with the image (check pods also). I couldn’t reproduce it.
1 Like
I would like to apologize. It worked. but it took several minutes for the update to happen. Is this expected behaviour?
Obter o Outlook para Android
I think so. When I tried the operator, it behaved this way. I don’t exactly know the reason, but I am guessing the operator has a few things to check or do, such as rolling updates: replica upgrades first, and then primary. So overall, it takes longer for the control loop to kick in.