Document strategy for operator-based upgrades #39
Conversation
JohnStrunk
force-pushed
the
upgrade-design
branch
from
0a60434
to
fba1dc0
Compare
JohnStrunk
changed the title
| updates, however, must be mindful of version compatibility between the | ||
| components. Particularly when upgrading across a series of releases, it may be | ||
| necessary to take intermediate upgrade steps to ensure client (CSI driver) | ||
| versions remain compatible with server (Gluster container) versions. |
There was a problem hiding this comment.
The client update has some limitation. The disturbance of fuse mounts could be an issue.
There was a problem hiding this comment.
Interesting point; thanks for bringing that up.
I suspect we'll see transport endpoint not connected when the CSI pod gets restarted on a node. I wonder if this means we need to drain nodes before upgrading the clients (and the implications for doing that in a rolling fashion w/ a DaemonSet).
| # The components that go into the GCS "system" | ||
| components: | ||
| - name: gluster-csi-file | ||
| # Template is probably a Deployment or DaemonSet, etc. |
There was a problem hiding this comment.
what we need is below
Object/object group : ds or dc or statefulset
Object name: glusterfs
upgrade/desired Version: GCS 2.0
There was a problem hiding this comment.
I don't think I understand your comment. My intent is to have the yaml for the kube object embedded here (DaemonSet, Deployment, etc). That would include everything such as the image:tag and resource limits. It would also probably have some sort of templatization like jinja2. The components list would exist for each "version" of GCS, and the operator would always move to the highest (my semver rules) version in the file.
I'm not following the "upgrade/desired" part of your comment.
|
I need to rework this design. It does not account for changes to reconcile logic between versions. |
JohnStrunk
force-pushed
the
upgrade-design
branch
from
fba1dc0
to
03c1c21
Compare
Signed-off-by: John Strunk <jstrunk@redhat.com>
Signed-off-by: John Strunk <jstrunk@redhat.com>
JohnStrunk
force-pushed
the
upgrade-design
branch
from
4663239
to
535e2e4
Compare
Describe what this PR does
This document describes how we plan to handle upgrades of the operator and lower-level components in a way that is compatible with OLM
Is there anything that requires special attention?
no
Related issues:
Fixes #38