refact(upgrade): scale down jiva target deploy before replica patch #1626
Conversation
Signed-off-by: shubham <shubham.bajpai@mayadata.io>
Signed-off-by: shubham <shubham.bajpai@mayadata.io>
| } | ||
| }, | ||
| "spec": { | ||
| "replicas": 1, |
There was a problem hiding this comment.
[doubt] replicas: 1 Is this where we scale down the target?, setting replica to 1.
It would be better if the indentation changes were excluded, since it is generating a huge diff.
There was a problem hiding this comment.
Scale down is performed via update before patching. the replica deployment
This is where scale up the target back again while patching the new image and labels.
Signed-off-by: shubham <shubham.bajpai@mayadata.io>
Signed-off-by: shubham <shubham.bajpai@mayadata.io>
…penebs-archive#1626) Avoid the replica's from getting connected to the older version of the controller and triggering a snapshot delete and so forth code. Signed-off-by: shubham <shubham.bajpai@mayadata.io>
…1626) Avoid the replica's from getting connected to the older version of the controller and triggering a snapshot delete and so forth code. Signed-off-by: shubham <shubham.bajpai@mayadata.io>
| @@ -429,6 +469,18 @@ func (j *jivaVolumeOptions) replicaUpgrade(openebsNamespace string) error { | |||
| } | |||
|
|
|||
| statusObj.Phase = utask.StepErrored | |||
|
|
|||
| err = scaleDownTargetDeploy(j.controllerObj.name, j.ns) | |||
There was a problem hiding this comment.
is j.controllerObj be NULL here? it seems to be populated in next step
There was a problem hiding this comment.
It is populated before the patching is done in the preuprade step. https://github.com/openebs/maya/blob/4104241e9966c87bc3153d7dab9aedaba9f503ac/pkg/upgrade/upgrader/jiva_upgrade.go#L599
| if err != nil { | ||
| return err | ||
| } | ||
| pvLabelKey := "openebs.io/persistent-volume" |
There was a problem hiding this comment.
can we use existing variables here instead of new ones?
There was a problem hiding this comment.
Sure. Will fix this in upcoming PRs.
Signed-off-by: shubham shubham.bajpai@mayadata.io
What this PR does / why we need it:
This PR adds a step to scale down jiva target deploy before upgrading replica deploy.
Sample logs:
mayadata:upgrade$ k logs -f jiva-vol-170180-pvc-4c3f661f-4cdc-4244-9916-1983c43c87b9-b5fjq I0310 16:41:56.788304 1 jiva_volume.go:80] Started upgrading jivaVolume{pvc-4c3f661f-4cdc-4244-9916-1983c43c87b9} from 1.7.0 to 1.8.0-RC1 I0310 16:41:56.788348 1 jiva_volume.go:87] Upgrading to 1.8.0-RC1 I0310 16:41:57.087781 1 jiva_upgrade.go:424] Scaling down target deploy pvc-4c3f661f-4cdc-4244-9916-1983c43c87b9-ctrl in default namespace I0310 16:42:07.280325 1 helper.go:68] Patching deployment pvc-4c3f661f-4cdc-4244-9916-1983c43c87b9-rep I0310 16:42:32.595875 1 helper.go:95] Deployment pvc-4c3f661f-4cdc-4244-9916-1983c43c87b9-rep rolled out successfully I0310 16:42:32.595892 1 jiva_upgrade.go:205] pvc-4c3f661f-4cdc-4244-9916-1983c43c87b9-rep patched I0310 16:42:32.676854 1 helper.go:68] Patching deployment pvc-4c3f661f-4cdc-4244-9916-1983c43c87b9-ctrl I0310 16:42:47.924426 1 helper.go:95] Deployment pvc-4c3f661f-4cdc-4244-9916-1983c43c87b9-ctrl rolled out successfully I0310 16:42:47.924455 1 jiva_upgrade.go:234] pvc-4c3f661f-4cdc-4244-9916-1983c43c87b9-ctrl patched I0310 16:42:47.940554 1 helper.go:184] targetservice pvc-4c3f661f-4cdc-4244-9916-1983c43c87b9-ctrl-svc patched I0310 16:42:48.040311 1 jiva_upgrade.go:319] Verifying replica sync I0310 16:43:05.077518 1 jiva_upgrade.go:351] Synced replica quorum is reached I0310 16:43:05.077536 1 jiva_upgrade.go:355] Replica syncing complete I0310 16:43:05.120480 1 jiva_upgrade.go:620] Upgrade Successful forpvc-4c3f661f-4cdc-4244-9916-1983c43c87b9 I0310 16:43:05.229610 1 jiva_volume.go:103] Upgraded successfullyWhich issue this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close that issue when PR gets merged): fixes #Special notes for your reviewer:
Checklist:
documentationtagbreaking-changestagrequires-upgradetag