Mini Content Journey (RHOSO team)

Technical writer: Roger Heslop

Reviewers:

• Technical: Alfredo Moralejo Alonso
• Peer: `Writer name`
• QE: `name`

Is this feature fully supported or technical preview?

• The process of removing the technical preview watcher operator before updating to FR4. The technical preview of watcher was not officially supported and there is no upgrade path other than an uninstall of watcher operator, and upgrade to FR4 (and enabling the watcher service in the OpenStackControlPlane CR file)

Does the procedural content need to be tested by QE?

• Yes

Does the documentation epic need a release note in addition to the feature?

• No: The engineering feature or epic might still need a release note. Engineers need to follow the guidance set in[ How-to Jira with the docs team](https://spaces.redhat.com/display/RHOSPDOC/How-to-Jira+with+the+RHOS+docs+team).

What stage of the user journey are you targeting?

• • Adopt: Adoption or Greenfield feature (Early stage customer use)*

Who is your target persona?

• RHOSO admin:  Platform Engineer

What type of information does the user need to know in order to use the feature?

• Procedures to implement or enable the feature
• Procedures or considerations for upgrades, adoption, or minor updates

Are there any existing upstream or internal resources that the writer can use for planning and drafting the content? Consider the situational context of the existing content. Do a Google search for any possible resources that might help.

• None

Does the content require input from multiple DFGs?

• Contact the upgrade technical writer for input

Does the content need to be included in any of the following guides?

• Adoption/minor updates guide: Are there any considerations or impact of this feature on adoption from pre-18 environments or from earlier 18z versions?

(Optional) Documentation outline If applicable, the writer can start brainstorming about the information design for the content. This is understood to only be a draft placeholder and subject to change as the content is authored and reviewed.

• Module Title (Concept)
• Overview of content required
• Module Title (Concept)
• Overview of content required
• Module Title (Procedure)
• Prerequisites
• Outline of steps
• Module Title (Procedure)
• Prerequisites
• Outline of steps
• Module Title (Reference)
• Outline of parameters/options/data to be included
• Module Title (Reference)
• Outline of parameters/options/data to be included

TODO: update for openstack-operator integration

Goal:

The goal is to document the process to update the watcher-operator and watcher deployment while being an standalone operator in Technology Preview.

While this is not a requirement for a component in TP, it can be convenient to provide a documented procedure to update watcher operator and watcher to a newer bug release. The process should be:

1. Update the operator. That should be managed by OLM automatically or requiring manual approval https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/operators/administrator-tasks#olm-approving-pending-upgrade_olm-upgrading-operators
2. Get the versions of the watcher service containers we want to update to.
3. Update the Images URLs in the Watcher CR to the desired tags.

That should be it.

So far, there are not strong versions dependencies between openstack-operator and watcher-operator versions, although it'd be recommended to deploy the same versions of the operators, and at some points the dependency may exist (i.e. a change in openstack-operators which require a change in watcher-operator or watcher services). We may also specify it in the docs.

Note that we don't plan to provide an in-place update from TP to Fully supported operator and the update when we are integrated in the openstack-operator will be managed by the openstack-operator, so this process will be only valid while being standalone.

Acceptance Criteria:

IMO there is no need to create a CI job to test the process (although it may be good if possible with a reasonable effort), but to test the process manually.