Add documentation for migrating from appliance(s) to pods

[bdunne]

Phase 1 of #1449

[jvlcek]

Hey @bdunne Good job getting this written down.

I realize this is just a WIP but wanted to help especially after you were so helpful with my recent documentation and blog posts. So I've posted some suggestions for you to consider.

JoeV

[bdunne]

Okay, I ran through the steps again and worked out some formatting issues. @jvlcek Want to re-review?

[Fryguy]

Phase 1 of #1449

1 out of 1449?!...you got a long way to go 🤣 🤣 🤣

[Fryguy]

This document is going to be a pain for productization... wondering how we can do that. At a minimum perhaps we can move things like manageiq specific pod namings into https://github.com/ManageIQ/manageiq-documentation/blob/master/_data/product.yml (or use what's there?)

[Fryguy]

This looks really good @bdunne ... As we move forward, I'm thinking from a deployment perspective, it's really weird to have to essentially "pause" the orchestrator right after you deploy it. I'm thinking this might be better done as a value in the CR. So when you deploy the CR, you would set something like databaseRestoreMode: true which would let the operator deploy everything but then put the orchestrator into a paused state or, even better, not launch it at all and we have a user deploy a "restore" pod/job instead. Then to "unpause" the operator you would remove that value from the CR, and the operator would reconcile that change to deploy the orchestrator.

[bdunne]

This looks really good @bdunne ... As we move forward, I'm thinking from a deployment perspective, it's really weird to have to essentially "pause" the orchestrator right after you deploy it. I'm thinking this might be better done as a value in the CR. So when you deploy the CR, you would set something like databaseRestoreMode: true which would let the operator deploy everything but then put the orchestrator into a paused state or, even better, not launch it at all and we have a user deploy a "restore" pod/job instead. Then to "unpause" the operator you would remove that value from the CR, and the operator would reconcile that change to deploy the orchestrator.

Yeah, I was thinking about something similar. I was thinking create a secret with:

applianceHost: appliance.example.com
applianceUser: root
appliancePassword: smartvm

Then put deploymentState: applianceImport in the CR and the operator can monitor/update that field and fire off an import job that would fetch everything. Once complete, switch to deploymentState: run and the Orchestrator would be deployed and app would start up.

[Fryguy]

Only comment I have left is on the productization aspects. If possible, let's remove any manageiq references, and where we can't use product.yml and {{ }} substitution instead.

[bdunne]

Only comment I have left is on the productization aspects. If possible, let's remove any manageiq references, and where we can't use product.yml and {{ }} substitution instead.

👍 Done

[miq-bot]

Some comments on commit https://github.com/bdunne/manageiq_docs/commit/f0fa5211709aba6b79740a91153e88492fef41f1

installing_on_kubernetes/_topics/migrate_from_appliance.md

• ⚠️ - 10 - Detected puts. Remove all debugging statements.
• ⚠️ - 14 - Detected puts. Remove all debugging statements.

[miq-bot]

Checked commit https://github.com/bdunne/manageiq_docs/commit/f0fa5211709aba6b79740a91153e88492fef41f1 with ruby 2.6.3, rubocop 0.69.0, haml-lint 0.28.0, and yamllint
1 file checked, 1 offense detected

**

• 💣 💥 🔥 🚒 - Linter/Yaml - missing config files

[Fryguy]

LGTM.. @jvlcek you have this marked as "Request changes"...are you good with it now?

[jvlcek]

LGTM 👍