docs(upgrade): document LogFileMetricExporter delete/recreate step for v5-to-v6 migration #3356
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -91,6 +91,54 @@ namespace before removing the **ClusterLogging** resource named '**instance**' i | |||||
| oc patch -n openshift-logging Kibana kibana --type=merge -p '{"metadata": {"ownerReferences": [], "labels": {"pod-template-hash":null}}}' | ||||||
| ---- | ||||||
|
|
||||||
| === Log File Metric Exporter | ||||||
| If you had a **LogFileMetricExporter** deployed in Logging 5, the existing `logfilesmetricexporter` DaemonSet must be deleted and recreated during the upgrade. Logging 6 updated the DaemonSet label selectors, and because Kubernetes does not allow changes to the `spec.selector` field of a DaemonSet, the operator cannot update it in place. | ||||||
|
|
||||||
| ==== Before Upgrading | ||||||
| Delete the **LogFileMetricExporter** CR before upgrading the operator. After deleting the CR, verify that the `logfilesmetricexporter` DaemonSet has also been removed. If the DaemonSet remains, delete it manually before proceeding. | ||||||
|
|
||||||
| .Backup the existing CR | ||||||
| [source] | ||||||
| ---- | ||||||
| oc get logfilesmetricexporter instance -n openshift-logging -o yaml > logfilesmetricexporter-instance.yaml | ||||||
|
Contributor
There was a problem hiding this comment.
Suggested change
Contributor
Author
There was a problem hiding this comment. Actually, |
||||||
| ---- | ||||||
|
|
||||||
| .Delete the CR | ||||||
| [source] | ||||||
| ---- | ||||||
| oc delete logfilemetricexporters instance -n openshift-logging | ||||||
| ---- | ||||||
|
|
||||||
| .Verify the DaemonSet is absent | ||||||
|
Contributor
There was a problem hiding this comment. I'd change the steps for being:
Contributor
Author
There was a problem hiding this comment. The point of doing the second command is IF the daemonset still exists, then delete it. If both these steps are combined then there is no need to verify first, just delete instead. I am inclined to leave it as is.
Contributor
There was a problem hiding this comment. Hello @Clee2691 , I'm not combinating any step, in fact, I'm adding the backup step, the 2 before deleting it
Contributor
Author
There was a problem hiding this comment. @r2d2rnd Oh I was seeing the original comment. I see the edited one now. Instead of backing up the
Contributor
There was a problem hiding this comment.
I agree, we should backup the CR and not the |
||||||
| [source] | ||||||
| ---- | ||||||
| oc get daemonset logfilesmetricexporter -n openshift-logging | ||||||
| ---- | ||||||
|
|
||||||
| .If the DaemonSet still exists, delete it: | ||||||
|
|
||||||
| [source] | ||||||
| ---- | ||||||
| oc delete daemonset logfilesmetricexporter -n openshift-logging | ||||||
| ---- | ||||||
|
|
||||||
| After the operator upgrade is complete, recreate the CR from the backup. | ||||||
|
|
||||||
| .Recreate the CR from the backup | ||||||
| [source] | ||||||
| ---- | ||||||
| oc apply -f logfilesmetricexporter-instance.yaml | ||||||
| ---- | ||||||
|
|
||||||
| ==== After Upgrading | ||||||
| If the operator is already upgraded and reporting a reconciler error for the **LogFileMetricExporter**, delete the DaemonSet directly. The operator will recreate it automatically. | ||||||
|
|
||||||
| .Delete the DaemonSet | ||||||
| [source] | ||||||
| ---- | ||||||
| oc delete daemonset logfilesmetricexporter -n openshift-logging | ||||||
|
coderabbitai[bot] marked this conversation as resolved.
|
||||||
| ---- | ||||||
|
|
||||||
| === Log Collection & Forwarding | ||||||
| Log collection and forwarding configuration is spec'd from a new link:../../reference/operator/api_observability_v1.adoc[API] | ||||||
| that is included in the API group **observability.openshift.io**. The following sections highlight the differences from the | ||||||
|
|
||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Clee2691 be aware that I should expect to have this step incorporated to the Upgrade documentation [0] as a sorted (numbered step) as it's in the KCS [1]
[0] https://docs.redhat.com/en/documentation/red_hat_openshift_logging/6.4/html/upgrading_logging/upgrading-to-logging-6
[1] https://access.redhat.com/articles/7089860
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please raise this as a documentation bug/feature in the appropriate JIRA project
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll do now, but I'd really expect that you do as part of your workflow in the future. The Technical Writer was creating the documentation following the upstream docs created by you, this is missing, then, it could make more sense that proactively in the future if similar things appear, at the same time that the Engineering ticket is opened, it's also reported and linked by Engineering to fix the Official doc as at the end, it will arrive to you once more to be reviewed before being published.