diff --git a/.github/workflows/docs.yaml b/.github/workflows/docs.yaml index 5a2861f97..fe87b4e60 100644 --- a/.github/workflows/docs.yaml +++ b/.github/workflows/docs.yaml @@ -10,7 +10,6 @@ on: # yamllint disable-line rule:truthy paths: - .github/workflows/docs* - docs_dev/** - - docs_user/** - Gemfile - Makefile jobs: @@ -31,22 +30,9 @@ jobs: - name: Install Asciidoc run: make docs-dependencies - - name: Build upstream user docs - run: make docs-user - - name: Build downstream preview of user docs - run: BUILD=downstream make docs-user - name: Build dev docs run: make docs-dev - - name: Test user docs - run: | - INSTALL_YAMLS_REF=$(grep -o install_yamls docs_build/adoption-user/index-downstream.html | wc -l) - if [[ $INSTALL_YAMLS_REF -gt 0 ]]; then - echo user facing docs should NOT mention install_yamls - grep install_yamls docs_build/adoption-user/index-downstream.html - exit 1 - fi - - name: Prepare gh-pages branch run: | git config user.name github-actions @@ -103,12 +89,11 @@ jobs:
- User Contributor
- +
@@ -117,14 +102,10 @@ jobs: - name: Commit asciidoc docs run: | - mv -T docs_build/adoption-user user mv -T docs_build/adoption-dev dev - mv user/index-upstream.html user/index.html - mv user/index-downstream.html user/downstream.html mv dev/index-upstream.html dev/index.html - git add user git add dev git add index.html git commit -m "Rendered docs" diff --git a/AGENTS.md b/AGENTS.md index 0f1c4ddf4..e358ca41a 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -34,7 +34,6 @@ There are other adjacent procedures described or linked in the repo that are opt - There should be parity between the docs and the tests. There may be some legitimate minor differences to account for CI specifics, but in general the intent of the tests is to verify the procedure and the commands from the docs. - Tests use the `shell` Ansible module liberally, we do not strive for "beautiful Ansible that just uses Python modules". Using `shell` tends to allow verbatim correspondence of tests to the commands/snippets in the docs, which is more important than having beautiful Ansible code. -- Docs must support multiple variants (upstream/downstream/OSPDO). Do not hardcode product names like "Red Hat OpenStack Services on OpenShift". Use the AsciiDoctor attributes defined in `docs_user/adoption-attributes.adoc` (e.g. `{rhos_long}`, `{OpenStackShort}`). ## Important @@ -43,17 +42,10 @@ There are other adjacent procedures described or linked in the repo that are opt ## Repository map -- `docs_build` - Generated content. Do not read or edit files in this directory as a source of truth. Always use `docs_user` or `docs_dev`. +- `docs_build` - Generated content. Do not read or edit files in this directory as a source of truth. Always use `docs_dev`. - `docs_build/adoption-dev/index-upstream.html` - Rendered developer documentation. - - `docs_build/adoption-user/index-{upstream,downstream,downstream-ospdo}.html` - Rendered user documentation (the adoption procedure). - `docs_dev` - Sources for developer documentation. -- `docs_user` - Sources for user documentation (the adoption procedure). - - `main.adoc` is the root. - - `*-attributes.adoc` files distinguish upstream and downstream variants. - - `assemblies` are higher-level building blocks. - - `modules` are lower-level building blocks. -- `docs_user` - Sources for user documentation (the adoption procedure). -- `Makefile` - The main Makefile for docs building and running tests. For docs it calls nested `make` using `docs_dev/Makefile` and `docs_user/Makefile`. +- `Makefile` - The main Makefile for docs building and running tests. For docs it calls nested `make` using `docs_dev/Makefile`. - `scenarios` - Configuration of CI jobs doing end-to-end testing. - `tests` - Ansible test suite utilized in the end-to-end tests. - `vars.sample.yaml,secrets.sample.yaml` - Example files with variables and secrets that are typically customized before running end-to-end tests. @@ -62,7 +54,7 @@ There are other adjacent procedures described or linked in the repo that are opt ## Building docs -`make docs` is the easiest way to build both user docs in all variants and developer docs. +`make docs` is the easiest way to build developer docs. More detailed info is in `docs_dev/assemblies/documentation.adoc`. diff --git a/Makefile b/Makefile index 372ff518a..fcc6a1e99 100644 --- a/Makefile +++ b/Makefile @@ -117,21 +117,7 @@ docs-dependencies: .bundle bundle config set --local path 'local/bundle'; bundle install -docs: docs-dependencies docs-user-all-variants docs-dev ## Build documentation - -docs-user-all-variants: - cd docs_user; BUILD=upstream $(MAKE) html - cd docs_user; BUILD=downstream $(MAKE) html - cd docs_user; BUILD=downstream BUILD_VARIANT=ospdo $(MAKE) html - -docs-user: - cd docs_user; $(MAKE) html - -docs-user-open: - cd docs_user; $(MAKE) open-html - -docs-user-watch: - cd docs_user; $(MAKE) watch-html +docs: docs-dependencies docs-dev ## Build documentation docs-dev: cd docs_dev; $(MAKE) html diff --git a/docs_dev/assemblies/documentation.adoc b/docs_dev/assemblies/documentation.adoc index 878dff1ee..d76f836f2 100644 --- a/docs_dev/assemblies/documentation.adoc +++ b/docs_dev/assemblies/documentation.adoc @@ -9,13 +9,6 @@ Install docs build requirements: make docs-dependencies ---- -To render the user-facing documentation site locally: - -[,bash] ----- -make docs-user ----- - To render the contributor documentation site locally: [,bash] @@ -23,8 +16,7 @@ To render the contributor documentation site locally: make docs-dev ---- -The built HTML files are in `docs_build/adoption-user` and -`docs_build/adoption-dev` directories respectively. +The built HTML files are in `docs_build/adoption-dev` directory. There are some additional make targets for convenience. The following @@ -33,8 +25,6 @@ resulting HTML in your browser so that you don't have to look for it: [,bash] ---- -make docs-user-open -# or make docs-dev-open ---- @@ -46,22 +36,9 @@ browser page" loop when working on the docs, without having to run [,bash] ---- -make docs-user-watch -# or make docs-dev-watch ---- -=== Preview of downstream documentation - -To render a preview of what should serve as the base for downstream -docs (e.g. with downstream container image URLs), prepend -`BUILD=downstream` to your make targets. For example: - -[,bash] ----- -BUILD=downstream make docs-user ----- - == Patterns and tips for contributing to documentation * Pages concerning individual components/services should make sense in diff --git a/docs_user/.vale.ini b/docs_user/.vale.ini deleted file mode 100644 index 669dee073..000000000 --- a/docs_user/.vale.ini +++ /dev/null @@ -1,6 +0,0 @@ -StylesPath = .vale/styles -MinAlertLevel = warning -Packages = https://github.com/jhradilek/asciidoctor-dita-vale/releases/latest/download/AsciiDocDITA.zip - -[*.adoc] -BasedOnStyles = AsciiDocDITA diff --git a/docs_user/.vale/styles/AsciiDocDITA/AdmonitionTitle.yml b/docs_user/.vale/styles/AsciiDocDITA/AdmonitionTitle.yml deleted file mode 100644 index 0485a3449..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/AdmonitionTitle.yml +++ /dev/null @@ -1,70 +0,0 @@ -# Report that admonition titles are not supported. ---- -extends: script -message: "Admonition titles are not supported in DITA." -level: warning -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#warnings -scope: raw -script: | - text := import("text") - matches := [] - - r_comment_line := text.re_compile("^(//|//[^/].*)$") - r_comment_block := text.re_compile("^/{4,}\\s*$") - r_block_title := text.re_compile("^\\.{1,2}[^ \\t.].*$") - r_admonition_para := text.re_compile("^(?:NOTE|TIP|IMPORTANT|WARNING|CAUTION):[ \\t]") - r_admonition_block := text.re_compile("^\\[(?:NOTE|TIP|IMPORTANT|WARNING|CAUTION)\\][ \\t]*$") - r_empty_line := text.re_compile("^[ \\t]*$") - - document := text.split(text.trim_suffix(scope, "\n"), "\n") - - in_comment_block := false - expect_title := false - expect_admonition := false - start := 0 - end := 0 - - for line in document { - start += end - end = len(line) + 1 - - if r_comment_block.match(line) { - delimiter := text.trim_space(line) - if ! in_comment_block { - in_comment_block = delimiter - } else if in_comment_block == delimiter { - in_comment_block = false - } - continue - } - if in_comment_block { continue } - if r_comment_line.match(line) { continue } - if r_empty_line.match(line) { continue } - - if r_block_title.match(line) { - if expect_title { - matches = append(matches, {begin: start, end: start + end - 1}) - expect_title = false - expect_admonition = false - } else { - expect_admonition = {begin: start, end: start + end - 1} - } - } else if r_admonition_block.match(line) { - if expect_admonition { - matches = append(matches, expect_admonition) - expect_admonition = false - expect_title = false - } else { - expect_title = true - } - } else if r_admonition_para.match(line) { - if expect_admonition { - matches = append(matches, expect_admonition) - expect_admonition = false - } - expect_title = false - } else { - expect_title = false - expect_admonition = false - } - } diff --git a/docs_user/.vale/styles/AsciiDocDITA/AttributeReference.yml b/docs_user/.vale/styles/AsciiDocDITA/AttributeReference.yml deleted file mode 100644 index d6f33422c..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/AttributeReference.yml +++ /dev/null @@ -1,41 +0,0 @@ -# Report custom attribute references. ---- -extends: existence -message: "%s" -level: suggestion -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#suggestions -scope: raw -nonword: true -tokens: - - '(?[ \t]+.*$' diff --git a/docs_user/.vale/styles/AsciiDocDITA/ConditionalCode.yml b/docs_user/.vale/styles/AsciiDocDITA/ConditionalCode.yml deleted file mode 100644 index ddeeff66d..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/ConditionalCode.yml +++ /dev/null @@ -1,10 +0,0 @@ -# Report conditional directives. ---- -extends: existence -message: "%s" -level: suggestion -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#suggestions -scope: raw -nonword: true -tokens: - - '^(?:ifn?def|ifeval)::\S*\[.*\][ \t]*$' diff --git a/docs_user/.vale/styles/AsciiDocDITA/ContentType.yml b/docs_user/.vale/styles/AsciiDocDITA/ContentType.yml deleted file mode 100644 index acfe938b6..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/ContentType.yml +++ /dev/null @@ -1,9 +0,0 @@ -# Report a missing content type definition. ---- -extends: occurrence -message: "The '_mod-docs-content-type' attribute definition is missing." -level: warning -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#warnings -scope: raw -min: 1 -token: '(?:^|[\n\r]):_(?:mod-docs-content|content|module)-type:[ \t]+\S' diff --git a/docs_user/.vale/styles/AsciiDocDITA/DiscreteHeading.yml b/docs_user/.vale/styles/AsciiDocDITA/DiscreteHeading.yml deleted file mode 100644 index 5fe0c3e5f..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/DiscreteHeading.yml +++ /dev/null @@ -1,10 +0,0 @@ -# Report that discrete headings are not supported. ---- -extends: existence -message: "Discrete headings are not supported in DITA." -level: warning -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#warnings -scope: raw -nonword: true -tokens: - - '^\[discrete\b[^\n\]]*?\]' diff --git a/docs_user/.vale/styles/AsciiDocDITA/EntityReference.yml b/docs_user/.vale/styles/AsciiDocDITA/EntityReference.yml deleted file mode 100644 index 084b2c69a..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/EntityReference.yml +++ /dev/null @@ -1,80 +0,0 @@ -# Report unsupported character entity references. ---- -extends: script -message: "HTML character entity references are not supported in DITA." -level: error -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#errors -scope: raw -script: | - text := import("text") - matches := [] - - r_attribute_list := text.re_compile("^\\[(?:|[\\w.#%{,\"'].*)\\][ \\t]*$") - r_block_title := text.re_compile("^\\.{1,2}[^ \\t.].*$") - r_code_block := text.re_compile("^(?:\\.{4,}|-{4,})[ \\t]*$") - r_comment_line := text.re_compile("^(//|//[^/].*)$") - r_comment_block := text.re_compile("^/{4,}\\s*$") - r_empty_line := text.re_compile("^[ \\t]*$") - r_entity_reference := text.re_compile("&[a-zA-Z][a-zA-Z0-9]*;") - r_list_continue := text.re_compile("^\\+[ \\t]*$") - r_sub_disabled := text.re_compile("-replacements") - r_sub_replacements := text.re_compile("subs=['\\x22](?:[^'\\x22]*,[ \\t]*|)\\+?(?:replacements|normal)(?:[ \\t]*,[^'\\x22]*|)['\\x22]") - r_supported_entity := text.re_compile("&(?:amp|lt|gt|apos|quot);") - - document := text.split(text.trim_suffix(scope, "\n"), "\n") - - in_code_block := false - in_comment_block := false - replacements := false - start := 0 - end := 0 - - for line in document { - start += end - end = len(line) + 1 - - if r_comment_block.match(line) { - delimiter := text.trim_space(line) - if ! in_comment_block { - in_comment_block = delimiter - } else if in_comment_block == delimiter { - in_comment_block = false - } - continue - } - if in_comment_block { continue } - if r_comment_line.match(line) { continue } - - if r_code_block.match(line) { - delimiter := text.trim_space(line) - if ! in_code_block { - in_code_block = delimiter - } else if in_code_block == delimiter { - in_code_block = false - replacements = false - } - continue - } - if in_code_block && ! replacements { continue } - - if r_block_title.match(line) { continue } - if r_empty_line.match(line) { continue } - if r_list_continue.match(line) { continue } - - if r_attribute_list.match(line) { - if r_sub_replacements.match(line) && ! r_sub_disabled.match(line) { - replacements = true - } - continue - } - - if replacements && ! in_code_block { - replacements = false - } - - for i, entry in r_entity_reference.find(line, -1) { - if ! r_supported_entity.match(entry[0].text) { - matches = append(matches, {begin: start + entry[0].begin, end: start + entry[0].end - 1}) - } - } - } diff --git a/docs_user/.vale/styles/AsciiDocDITA/EquationFormula.yml b/docs_user/.vale/styles/AsciiDocDITA/EquationFormula.yml deleted file mode 100644 index 4ccd48e4d..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/EquationFormula.yml +++ /dev/null @@ -1,12 +0,0 @@ -# Report that equations and formulas are not implemented. ---- -extends: existence -message: "Equations and formulas are not implemented." -level: warning -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#warnings -scope: raw -nonword: true -tokens: - - '^:stem:(?:|[ \t]+asciimath|[ \t]latexmath)[ \t]*$' - - '^\[(?:stem|asciimath|latexmath)\][ \t]*$' - - '\b(?:stem|asciimath|latexmath):(?:[a-z,-]+)?\[.*?[^\\]\]' diff --git a/docs_user/.vale/styles/AsciiDocDITA/ExampleBlock.yml b/docs_user/.vale/styles/AsciiDocDITA/ExampleBlock.yml deleted file mode 100644 index 2742a5de7..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/ExampleBlock.yml +++ /dev/null @@ -1,143 +0,0 @@ -# Report unsupported example blocks. ---- -extends: script -message: "Examples can not be inside of other blocks in DITA." -level: error -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#errors -scope: raw -script: | - text := import("text") - matches := [] - - r_admonition_block := text.re_compile("^\\[(?:NOTE|TIP|IMPORTANT|WARNING|CAUTION)\\][ \\t]*$") - r_attribute := text.re_compile("^:!?\\S[^:]*:") - r_block_title := text.re_compile("^\\.{1,2}[^ \\t.].*$") - r_code_block := text.re_compile("^(?:\\.{4,}|-{4,})[ \\t]*$") - r_comment_block := text.re_compile("^/{4,}\\s*$") - r_comment_line := text.re_compile("^(//|//[^/].*)$") - r_conditional := text.re_compile("^(?:ifn?def|ifeval|endif)::\\S*\\[.*\\][ \\t]*$") - r_empty_line := text.re_compile("^[ \\t]*$") - r_example_block := text.re_compile("^\\[example\\][ \\t]*$") - r_example_delim := text.re_compile("^={4,}[ \\t]*$") - r_list_continue := text.re_compile("^\\+[ \\t]*$") - r_list_item := text.re_compile("^[ \\t]*[\\*-.]+[ \\t]+\\S.*$") - r_other_block := text.re_compile("^(?:\\*{4,}|-{2})[ \\t]*$") - r_section := text.re_compile("^={2,}[ \\t]\\S.*$") - - document := text.split(text.trim_suffix(scope, "\n"), "\n") - - in_comment_block := false - in_example_block := false - in_code_block := false - in_other_block := false - in_section := false - in_list := false - in_continue := false - expect_admonition := false - start := 0 - end := 0 - - for line in document { - start += end - end = len(line) + 1 - - if r_comment_block.match(line) { - delimiter := text.trim_space(line) - if ! in_comment_block { - in_comment_block = delimiter - } else if in_comment_block == delimiter { - in_comment_block = false - } - continue - } - if in_comment_block { continue } - if r_comment_line.match(line) { continue } - - if r_code_block.match(line) { - delimiter := text.trim_space(line) - if ! in_code_block { - in_code_block = delimiter - } else if in_code_block == delimiter { - in_code_block = false - } - in_continue = false - continue - } - if in_code_block { continue } - - if r_attribute.match(line) { continue } - if r_conditional.match(line) { continue } - - if r_example_delim.match(line) { - delimiter := text.trim_space(line) - if ! in_example_block { - in_example_block = delimiter - - if expect_admonition { continue } - - if in_section || in_other_block || in_list { - matches = append(matches, {begin: start, end: start + end - 1}) - } - } else if in_example_block == delimiter { - in_example_block = false - } - in_continue = false - continue - } - - if r_empty_line.match(line) { - if ! in_continue { - in_list = false - } - continue - } - - if r_list_continue.match(line) { - in_continue = true - in_list = true - continue - } else { - in_continue = false - } - - if r_block_title.match(line) && expect_admonition { - if in_continue { - in_continue = false - } - continue - } - - if r_list_item.match(line) { - in_list = true - continue - } - - if r_admonition_block.match(line) { - expect_admonition = true - continue - } - - if r_section.match(line) { - in_section = true - continue - } - - if r_example_block.match(line) { - if in_section || in_other_block || in_list { - matches = append(matches, {begin: start, end: start + end - 1}) - } - continue - } - - if r_other_block.match(line) { - delimiter := text.trim_space(line) - if ! in_other_block { - in_other_block = delimiter - } else if in_other_block == delimiter { - in_other_block = false - } - continue - } - - expect_admonition = false - } diff --git a/docs_user/.vale/styles/AsciiDocDITA/IncludeDirective.yml b/docs_user/.vale/styles/AsciiDocDITA/IncludeDirective.yml deleted file mode 100644 index 773657382..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/IncludeDirective.yml +++ /dev/null @@ -1,10 +0,0 @@ -# Report include directives. ---- -extends: existence -message: "%s" -level: suggestion -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#suggestions -scope: raw -nonword: true -tokens: - - '^include::(?:[^\s\[]|[^[]*[^\s\[])\[.*\][ \t]*$' diff --git a/docs_user/.vale/styles/AsciiDocDITA/LineBreak.yml b/docs_user/.vale/styles/AsciiDocDITA/LineBreak.yml deleted file mode 100644 index 03fc03e15..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/LineBreak.yml +++ /dev/null @@ -1,16 +0,0 @@ -# Report that hard line breaks ara not supported. ---- -extends: existence -message: "Hard line breaks are not supported in DITA." -level: warning -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#warnings -scope: raw -nonword: true -tokens: - - '^[^/]{2}.* \+[ \t]*$' - - '^. \+[ \t]*$' - - '^:hardbreaks-option:(?:|.*?)[ \t]*$' - - '^\[[^\]]*%hardbreaks[^\n\]]*?\]' - - '^\[[^\]]*options=hardbreaks\b[^\n\]]*?\]' - - '^\[[^\]]*options="[^"]*hardbreaks\b[^\n\]]*?\]' - - "^\\[[^\\]]*options='[^']*hardbreaks\\b[^\\n\\]]*?\\]" diff --git a/docs_user/.vale/styles/AsciiDocDITA/NestedSection.yml b/docs_user/.vale/styles/AsciiDocDITA/NestedSection.yml deleted file mode 100644 index eed8d9c16..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/NestedSection.yml +++ /dev/null @@ -1,10 +0,0 @@ -# Report that level 2, 3, 4, and 5 sections are not supported. ---- -extends: existence -message: "Level 2, 3, 4, and 5 sections are not supported in DITA." -level: error -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#errors -scope: raw -nonword: true -tokens: - - '^={3,6}[ \t]\S.*$' diff --git a/docs_user/.vale/styles/AsciiDocDITA/PageBreak.yml b/docs_user/.vale/styles/AsciiDocDITA/PageBreak.yml deleted file mode 100644 index 34ac27a1f..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/PageBreak.yml +++ /dev/null @@ -1,10 +0,0 @@ -# Report that page breaks are not supported. ---- -extends: existence -message: "Page breaks are not supported in DITA." -level: warning -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#warnings -scope: raw -nonword: true -tokens: - - '^<{3,}[ \t]*$' diff --git a/docs_user/.vale/styles/AsciiDocDITA/RelatedLinks.yml b/docs_user/.vale/styles/AsciiDocDITA/RelatedLinks.yml deleted file mode 100644 index be8dc46a4..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/RelatedLinks.yml +++ /dev/null @@ -1,89 +0,0 @@ -# Report text outside of links in additional resources. ---- -extends: script -message: "Content other than links cannot be mapped to DITA related-links." -level: warning -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#warnings -scope: raw -script: | - text := import("text") - matches := [] - - r_add_resources := text.re_compile("^(?:={2,}[ \\t]+|\\.{1,2})Additional resources[ \\t]*$") - r_any_title := text.re_compile("^(?:={2,}[ \\t]+|\\.{1,2})[^ \\t.].*$") - r_attribute := text.re_compile("^:!?\\S[^:]*:") - r_attribute_ref := text.re_compile("^[ \\t]*[\\*-][ \\t]+\\{(?:[0-9A-Za-z_][0-9A-Za-z_-]*|set:.+?|counter2?:.+?)\\}(?:|[^\\[\\s]*\\[.*?\\])[ \\t]*$") - r_comment_block := text.re_compile("^/{4,}\\s*$") - r_comment_line := text.re_compile("^(//|//[^/].*)$") - r_conditional := text.re_compile("^(?:ifn?def|ifeval|endif)::\\S*\\[.*\\][ \\t]*$") - r_content_type := text.re_compile("^:_(?:mod-docs-content|content|module)-type:[ \\t]+(?i:assembly)") - r_empty_line := text.re_compile("^[ \\t]*$") - r_id_attribute := text.re_compile("^\\[(?:id=['\\x22]|#|\\[)[A-Za-z_:{}][A-Za-z0-9_.:{}-]*(?:['\\x22],?[^\\]]*|,[^\\]]*\\]?|\\]?)\\][ \\t]*$") - r_include := text.re_compile("^include::(?:[^ \\t\\[]|[^[]*[^ \\t\\[])\\[.*\\][ \\t]*$") - r_inline_link := text.re_compile("^[ \\t]*[\\*-][ \\t]+(?:|link:|<)(?:|\\+\\+)(?:https?|file|ftp|irc)://[^ \\t\\[\\]]+(?:|\\+\\+)(?:|\\[.*?\\])>?[ \\t]*$") - r_inline_xref := text.re_compile("^[ \\t]*[\\*-][ \\t]+<<[A-Za-z0-9/.:{].*?>>[ \\t]*$") - r_link_macro := text.re_compile("^[ \\t]*[\\*-][ \\t]+(?:link|mailto):(?:|[^: \\t\\[][^: \\t\\[]*)\\[.*?\\][ \\t]*$") - r_role_attribute := text.re_compile("^\\[(?:role=['\\x22]|\\.)_additional-resources['\\x22]?\\][ \\t]*$") - r_xref_macro := text.re_compile("^[ \\t]*[\\*-][ \\t]+xref:[A-Za-z0-9/.:{].*?\\[.*?\\][ \\t]*$") - - document := text.split(text.trim_suffix(scope, "\n"), "\n") - - is_assembly := false - in_comment_block := false - in_add_resources := false - start := 0 - end := 0 - - for line in document { - start += end - end = len(line) + 1 - - if r_comment_block.match(line) { - delimiter := text.trim_space(line) - if ! in_comment_block { - in_comment_block = delimiter - } else if in_comment_block == delimiter { - in_comment_block = false - } - continue - } - if in_comment_block { continue } - if r_comment_line.match(line) { continue } - - if r_content_type.match(line) { - is_assembly = true - continue - } - - if r_empty_line.match(line) { continue } - if r_attribute.match(line) { continue } - if r_conditional.match(line) { continue } - - if r_role_attribute.match(line) || r_id_attribute.match(line) { - continue - } - - if r_include.match(line) && is_assembly { - continue - } - - if r_add_resources.match(line) { - in_add_resources = true - continue - } - - if ! in_add_resources { continue } - - if r_any_title.match(line) { - in_add_resources = false - continue - } - - if r_link_macro.match(line) || r_inline_link.match(line) || - r_xref_macro.match(line) || r_inline_xref.match(line) || - r_attribute_ref.match(line) { - continue - } - - matches = append(matches, {begin: start, end: start + end - 1}) - } diff --git a/docs_user/.vale/styles/AsciiDocDITA/ShortDescription.yml b/docs_user/.vale/styles/AsciiDocDITA/ShortDescription.yml deleted file mode 100644 index 7b178acdb..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/ShortDescription.yml +++ /dev/null @@ -1,10 +0,0 @@ -# Suggest assigning the [role="_abstract"] attribute list to a paragraph to -# be used as short description in DITA. ---- -extends: occurrence -message: "Assign [role=\"_abstract\"] to a paragraph to use it as in DITA." -level: warning -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#warnings -scope: raw -min: 1 -token: '(?:^|[\n\r])\[role=(["\x27]?)_abstract\1\]' diff --git a/docs_user/.vale/styles/AsciiDocDITA/SidebarBlock.yml b/docs_user/.vale/styles/AsciiDocDITA/SidebarBlock.yml deleted file mode 100644 index c2bea8f77..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/SidebarBlock.yml +++ /dev/null @@ -1,55 +0,0 @@ -# Report that sidebars are not supported. ---- -extends: script -message: "Sidebars are not supported in DITA." -level: warning -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#warnings -scope: raw -script: | - text := import("text") - matches := [] - - r_code_block := text.re_compile("^(?:\\.{4,}|-{4,})[ \\t]*$") - r_comment_block := text.re_compile("^/{4,}\\s*$") - r_comment_line := text.re_compile("^(//|//[^/].*)$") - r_sidebar_block := text.re_compile("^\\[sidebar\\b[^\\]]*?\\][ \\t]*$") - r_sidebar_delim := text.re_compile("^\\*{4,}[ \\t]*$") - - document := text.split(text.trim_suffix(scope, "\n"), "\n") - - in_code_block := false - in_comment_block := false - start := 0 - end := 0 - - for line in document { - start += end - end = len(line) + 1 - - if r_comment_block.match(line) { - delimiter := text.trim_space(line) - if ! in_comment_block { - in_comment_block = delimiter - } else if in_comment_block == delimiter { - in_comment_block = false - } - continue - } - if in_comment_block { continue } - if r_comment_line.match(line) { continue } - - if r_code_block.match(line) { - delimiter := text.trim_space(line) - if ! in_code_block { - in_code_block = delimiter - } else if in_code_block == delimiter { - in_code_block = false - } - continue - } - if in_code_block { continue } - - if r_sidebar_block.match(line) || r_sidebar_delim.match(line) { - matches = append(matches, {begin: start, end: start + end - 1}) - } - } diff --git a/docs_user/.vale/styles/AsciiDocDITA/TableFooter.yml b/docs_user/.vale/styles/AsciiDocDITA/TableFooter.yml deleted file mode 100644 index f26153cec..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/TableFooter.yml +++ /dev/null @@ -1,13 +0,0 @@ -# Report that table footers are not supported. ---- -extends: existence -message: "Table footers are not supported in DITA." -level: warning -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#warnings -scope: raw -nonword: true -tokens: - - '^\[[^\]]*%footer[^\n\]]*?\]' - - '^\[[^\]]*options=footer\b[^\n\]]*?\]' - - '^\[[^\]]*options="[^"]*footer\b[^\n\]]*?\]' - - "^\\[[^\\]]*options='[^']*footer\\b[^\\n\\]]*?\\]" diff --git a/docs_user/.vale/styles/AsciiDocDITA/TagDirective.yml b/docs_user/.vale/styles/AsciiDocDITA/TagDirective.yml deleted file mode 100644 index 01315dea5..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/TagDirective.yml +++ /dev/null @@ -1,10 +0,0 @@ -# Report tag directives. ---- -extends: existence -message: "%s" -level: suggestion -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#suggestions -scope: raw -nonword: true -tokens: - - '\btag::\S+?\[\][ \t]*$' diff --git a/docs_user/.vale/styles/AsciiDocDITA/TaskDuplicate.yml b/docs_user/.vale/styles/AsciiDocDITA/TaskDuplicate.yml deleted file mode 100644 index de25025de..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/TaskDuplicate.yml +++ /dev/null @@ -1,65 +0,0 @@ -# Report duplicate titles inside of procedure modules. ---- -extends: script -message: "Duplicate titles cannot be mapped to DITA tasks." -level: warning -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#warnings -scope: raw -script: | - text := import("text") - matches := [] - - r_comment_line := text.re_compile("^(//|//[^/].*)$") - r_comment_block := text.re_compile("^/{4,}\\s*$") - r_content_type := text.re_compile("^:_(?:mod-docs-content|content|module)-type:[ \\t]+(?i:procedure)") - - titles := {} - titles.prereq = text.re_compile("^\\.{1,2}Prerequisites?[ \\t]*$") - titles.steps = text.re_compile("^\\.{1,2}Procedure[ \\t]*$") - titles.result = text.re_compile("^\\.{1,2}(?:Verification|Results?)[ \\t]*$") - titles.trouble = text.re_compile("^\\.{1,2}(?:Troubleshooting|Troubleshooting steps?)[ \\t]*$") - titles.postreq = text.re_compile("^\\.{1,2}Next steps?[ \\t]*$") - titles.links = text.re_compile("^\\.{1,2}Additional resources[ \\t]*$") - - document := text.split(text.trim_suffix(scope, "\n"), "\n") - - in_comment_block := false - is_procedure := false - start := 0 - end := 0 - block_titles := {} - - for line in document { - start += end - end = len(line) + 1 - - if r_comment_block.match(line) { - delimiter := text.trim_space(line) - if ! in_comment_block { - in_comment_block = delimiter - } else if in_comment_block == delimiter { - in_comment_block = false - } - continue - } - if in_comment_block { continue } - if r_comment_line.match(line) { continue } - - if r_content_type.match(line) { - is_procedure = true - } - - for title, r in titles { - if ! r.match(line) { continue } - - if block_titles[title] { - matches = append(matches, {begin: start, end: start + end - 1}) - } else { - block_titles[title] = true - } - } - } - - if ! is_procedure { - matches = [] - } diff --git a/docs_user/.vale/styles/AsciiDocDITA/TaskExample.yml b/docs_user/.vale/styles/AsciiDocDITA/TaskExample.yml deleted file mode 100644 index c33fd9be4..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/TaskExample.yml +++ /dev/null @@ -1,124 +0,0 @@ -# Report extra examples inside of procedure modules. ---- -extends: script -message: "Examples are allowed only once in DITA tasks." -level: error -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#errors -scope: raw -script: | - text := import("text") - matches := [] - - r_admonition_block := text.re_compile("^\\[(?:NOTE|TIP|IMPORTANT|WARNING|CAUTION)\\][ \\t]*$") - r_block_title := text.re_compile("^\\.{1,2}[^ \\t.].*$") - r_comment_block := text.re_compile("^/{4,}\\s*$") - r_comment_line := text.re_compile("^(//|//[^/].*)$") - r_code_block := text.re_compile("^(?:\\.{4,}|-{4,})[ \\t]*$") - r_conditional := text.re_compile("^(?:ifn?def|ifeval|endif)::\\S*\\[.*\\][ \\t]*$") - r_content_type := text.re_compile("^:_(?:mod-docs-content|content|module)-type:[ \\t]+(?i:procedure)") - r_empty_line := text.re_compile("^[ \\t]*$") - r_example_block := text.re_compile("^\\[example\\][ \\t]*$") - r_example_delim := text.re_compile("^={4,}[ \\t]*$") - r_list_continue := text.re_compile("^\\+[ \\t]*$") - - document := text.split(text.trim_suffix(scope, "\n"), "\n") - - expect_admonition := false - expect_example := false - in_comment_block := false - in_code_block := false - in_example_block := false - is_procedure := false - count := 0 - start := 0 - end := 0 - - for line in document { - start += end - end = len(line) + 1 - - if r_comment_block.match(line) { - delimiter := text.trim_space(line) - if ! in_comment_block { - in_comment_block = delimiter - } else if in_comment_block == delimiter { - in_comment_block = false - } - continue - } - if in_comment_block { continue } - if r_comment_line.match(line) { continue } - - if r_code_block.match(line) { - delimiter := text.trim_space(line) - if ! in_code_block { - in_code_block = delimiter - } else if in_code_block == delimiter { - in_code_block = false - } - continue - } - if in_code_block { continue } - - if r_conditional.match(line) { continue } - if r_empty_line.match(line) { continue } - - if r_content_type.match(line) { - is_procedure = true - continue - } - - if r_admonition_block.match(line) { - expect_admonition = true - continue - } - - if expect_admonition || expect_example { - if r_block_title.match(line) || r_list_continue.match(line) { - continue - } - } - - if r_example_delim.match(line) { - delimiter := text.trim_space(line) - if ! in_example_block { - in_example_block = delimiter - - if expect_admonition { - expect_admonition = false - continue - } - if expect_example { - expect_example = false - continue - } - - count++ - - if count > 1 { - matches = append(matches, {begin: start, end: start + end - 1}) - } - } else if in_example_block == delimiter { - in_example_block = false - } - continue - } - - if r_example_block.match(line) { - count++ - - if count > 1 { - matches = append(matches, {begin: start, end: start + end - 1}) - } - - expect_example = true - continue - } - - expect_admonition = false - expect_example = false - } - - if ! is_procedure { - matches = [] - } diff --git a/docs_user/.vale/styles/AsciiDocDITA/TaskSection.yml b/docs_user/.vale/styles/AsciiDocDITA/TaskSection.yml deleted file mode 100644 index 5087c2923..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/TaskSection.yml +++ /dev/null @@ -1,49 +0,0 @@ -# Report sections inside of procedure modules. ---- -extends: script -message: "Sections are not allowed in DITA tasks." -level: error -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#errors -scope: raw -script: | - text := import("text") - matches := [] - - r_comment_line := text.re_compile("^(//|//[^/].*)$") - r_comment_block := text.re_compile("^/{4,}\\s*$") - r_content_type := text.re_compile("^:_(?:mod-docs-content|content|module)-type:[ \\t]+(?i:procedure)") - r_section := text.re_compile("^={2,}[ \\t]\\S.*$") - - document := text.split(text.trim_suffix(scope, "\n"), "\n") - - in_comment_block := false - is_procedure := false - start := 0 - end := 0 - - for line in document { - start += end - end = len(line) + 1 - - if r_comment_block.match(line) { - delimiter := text.trim_space(line) - if ! in_comment_block { - in_comment_block = delimiter - } else if in_comment_block == delimiter { - in_comment_block = false - } - continue - } - if in_comment_block { continue } - if r_comment_line.match(line) { continue } - - if r_content_type.match(line) { - is_procedure = true - } else if r_section.match(line) { - matches = append(matches, {begin: start, end: start + end - 1}) - } - } - - if ! is_procedure { - matches = [] - } diff --git a/docs_user/.vale/styles/AsciiDocDITA/TaskStep.yml b/docs_user/.vale/styles/AsciiDocDITA/TaskStep.yml deleted file mode 100644 index 252b8b93d..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/TaskStep.yml +++ /dev/null @@ -1,129 +0,0 @@ -# Report content other than steps in procedures. ---- -extends: script -message: "Content other than a single list cannot be mapped to DITA tasks." -level: warning -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#warnings -scope: raw -script: | - text := import("text") - matches := [] - - r_admonition := text.re_compile("^\\[(?:NOTE|TIP|IMPORTANT|WARNING|CAUTION)\\][ \\t]*$") - r_any_title := text.re_compile("^\\.{1,2}[^ \\t.].*$") - r_attribute_list := text.re_compile("^\\[(?:|[\\w.#%{,\"'].*)\\][ \\t]*$") - r_attribute := text.re_compile("^:!?\\S[^:]*:") - r_comment_block := text.re_compile("^/{4,}\\s*$") - r_comment_line := text.re_compile("^(//|//[^/].*)$") - r_conditional := text.re_compile("^(?:ifn?def|ifeval|endif)::\\S*\\[.*\\][ \\t]*$") - r_content_type := text.re_compile("^:_(?:mod-docs-content|content|module)-type:[ \\t]+(?i:procedure)") - r_dlist := text.re_compile("^[ \\t]*\\S.*?(?::{2,4}|;;)(?:|[ \\t]+.*)$") - r_empty_line := text.re_compile("^[ \\t]*$") - r_example_delim := text.re_compile("^={4,}[ \\t]*$") - r_list_continue := text.re_compile("^\\+[ \\t]*$") - r_other_block := text.re_compile("^(?:\\.{4,}|-{4,}|={4,}|-{2}|\\|={3,})[ \\t]*$") - r_procedure := text.re_compile("^(?:={2,}[ \\t]+|\\.{1,2})Procedure[ \\t]*$") - r_step := text.re_compile("^[ \\t]*[\\*-.]+[ \\t]+\\S.*$") - r_supported_title := text.re_compile("^\\.{1,2}(?:Prerequisites?|Procedure|Verification|Results?|Troubleshooting|Troubleshooting steps?|Next steps?|Additional resources)[ \\t]*$") - - document := text.split(text.trim_suffix(scope, "\n"), "\n") - - is_procedure_mod := false - in_comment_block := false - in_continue := false - in_list := false - in_other_block := false - in_procedure := false - in_step := false - start := 0 - end := 0 - - for line in document { - start += end - end = len(line) + 1 - - if r_comment_block.match(line) { - delimiter := text.trim_space(line) - if ! in_comment_block { - in_comment_block = delimiter - } else if in_comment_block == delimiter { - in_comment_block = false - } - continue - } - if in_comment_block { continue } - if r_comment_line.match(line) { continue } - - if r_content_type.match(line) { - is_procedure_mod = true - continue - } - - if r_conditional.match(line) { continue } - if r_attribute.match(line) { continue } - if r_attribute_list.match(line) && ! r_admonition.match(line) { - continue - } - - if r_procedure.match(line) { - in_procedure = true - continue - } - - if ! in_procedure { continue } - - if r_supported_title.match(line) { break } - if r_any_title.match(line) { continue } - - if in_step { - if r_other_block.match(line) { - delimiter := text.trim_space(line) - if ! in_other_block { - in_other_block = delimiter - } else if in_other_block == delimiter { - in_other_block = false - in_continue = false - } - continue - } - if in_other_block { continue } - } - - if r_empty_line.match(line) { - if ! in_continue { - in_step = false - } - continue - } - - if r_list_continue.match(line) { - in_continue = true - in_step = true - continue - } else { - in_continue = false - } - - if r_step.match(line) { - in_list = true - in_step = true - continue - } - - if in_list && r_dlist.match(line) { - in_step = true - continue - } - - if in_step { continue } - - if r_example_delim.match(line) { break } - - matches = append(matches, {begin: start, end: start + end - 1}) - - if in_list { break } - } - - if ! is_procedure_mod { - matches = [] - } diff --git a/docs_user/.vale/styles/AsciiDocDITA/TaskTitle.yml b/docs_user/.vale/styles/AsciiDocDITA/TaskTitle.yml deleted file mode 100644 index 0dcc75ee8..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/TaskTitle.yml +++ /dev/null @@ -1,101 +0,0 @@ -# Report unsupported titles inside of procedure modules. ---- -extends: script -message: "Unsupported titles cannot be mapped to DITA tasks." -level: warning -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#warnings -scope: raw -script: | - text := import("text") - matches := [] - - r_attribute_list := text.re_compile("^\\[(?:|[\\w.#%{,\"'].*)\\][ \\t]*$") - r_attribute := text.re_compile("^:!?\\S[^:]*:") - r_block_title := text.re_compile("^\\.{1,2}[^ \\t.].*$") - r_code_block := text.re_compile("^(?:\\.{4,}|-{4,})[ \\t]*$") - r_comment_block := text.re_compile("^/{4,}\\s*$") - r_comment_line := text.re_compile("^(//|//[^/].*)$") - r_conditional := text.re_compile("^(?:ifn?def|ifeval|endif)::\\S*\\[.*\\][ \\t]*$") - r_content_type := text.re_compile("^:_(?:mod-docs-content|content|module)-type:[ \\t]+(?i:procedure)") - r_example_block := text.re_compile("^\\[example\\][ \\t]*$") - r_example_delim := text.re_compile("^={4,}[ \\t]*$") - r_image := text.re_compile("^image::(?:\\S|\\S.*\\S)\\[.*\\][ \\t]*$") - r_list_continue := text.re_compile("^\\+[ \\t]*$") - r_supported_title := text.re_compile("^\\.{1,2}(?:Prerequisites?|Procedure|Verification|Results?|Troubleshooting|Troubleshooting steps?|Next steps?|Additional resources)[ \\t]*$") - r_table := text.re_compile("^\\|={3,}[ \\t]*$") - - document := text.split(text.trim_suffix(scope, "\n"), "\n") - - in_code_block := false - in_comment_block := false - is_procedure := false - is_list_continue := false - expect_block := false - start := 0 - end := 0 - - for line in document { - start += end - end = len(line) + 1 - - if r_comment_block.match(line) { - delimiter := text.trim_space(line) - if ! in_comment_block { - in_comment_block = delimiter - } else if in_comment_block == delimiter { - in_comment_block = false - } - continue - } - if in_comment_block { continue } - if r_comment_line.match(line) { continue } - - if r_code_block.match(line) { - delimiter := text.trim_space(line) - if ! in_code_block { - in_code_block = delimiter - } else if in_code_block == delimiter { - in_code_block = false - } - continue - } - if in_code_block { continue } - - if r_content_type.match(line) { - is_procedure = true - continue - } - - if r_attribute_list.match(line) && ! r_example_block.match(line) { continue } - if r_attribute.match(line) { continue } - if r_conditional.match(line) { continue } - - if r_list_continue.match(line) { - is_list_continue = true - continue - } - - if r_table.match(line) || r_image.match(line) || - r_example_block.match(line) || r_example_delim.match(line) { - expect_block = false - is_list_continue = false - continue - } - - if r_block_title.match(line) && ! r_supported_title.match(line) { - if ! is_list_continue { - expect_block = {begin: start, end: start + end - 1} - } - } else if expect_block { - matches = append(matches, expect_block) - expect_block = false - } - - is_list_continue = false - } - - if ! is_procedure { - matches = [] - } else if expect_block { - matches = append(matches, expect_block) - } diff --git a/docs_user/.vale/styles/AsciiDocDITA/ThematicBreak.yml b/docs_user/.vale/styles/AsciiDocDITA/ThematicBreak.yml deleted file mode 100644 index c59e76b40..000000000 --- a/docs_user/.vale/styles/AsciiDocDITA/ThematicBreak.yml +++ /dev/null @@ -1,14 +0,0 @@ -# Report that thematic breaks are not supported. ---- -extends: existence -message: "Thematic breaks are not supported in DITA." -level: warning -link: https://github.com/jhradilek/asciidoctor-dita-vale/blob/main/README.md#warnings -scope: raw -nonword: true -tokens: - - "^'{3,}[ \\t]*$" - - '^[*_]{3}[ \t]*$' - - '^\* \* \*[ \t]*$' - - '^- - -[ \t]*$' - - '^_ _ _[ \t]*$' diff --git a/docs_user/Makefile b/docs_user/Makefile deleted file mode 100644 index c330e8583..000000000 --- a/docs_user/Makefile +++ /dev/null @@ -1,64 +0,0 @@ -BUILD ?= upstream -ABUILD_VARIANT ?= -BUILD_VARIANT_WITH_SEPARATOR ?= $(if $(strip $(BUILD_VARIANT)),-$(BUILD_VARIANT),) -BUILD_DIR = ../docs_build -ROOTDIR = $(realpath .) -NAME = adoption-user -DEST_DIR = $(BUILD_DIR)/$(NAME) -DEST_HTML = $(DEST_DIR)/index-$(BUILD)$(BUILD_VARIANT_WITH_SEPARATOR).html -DEST_PDF = $(BUILD_DIR)/$(NAME)-$(BUILD)$(BUILD_VARIANT_WITH_SEPARATOR).pdf -IMAGES_DIR = $(DEST_DIR)/images -IMAGES_TS = $(DEST_DIR)/.timestamp-images -MAIN_SOURCE = main.adoc -OTHER_SOURCES = $(shell find ./assemblies ./modules -type f) -IMAGES = $(shell find ./images -type f) -ALL_SOURCES = $(MAIN_SOURCE) $(OTHER_SOURCES) $(IMAGES) -UNAME = $(shell uname) -BUNDLE_EXEC ?= bundle exec - -ifeq ($(UNAME), Linux) -BROWSER_OPEN = xdg-open -endif -ifeq ($(UNAME), Darwin) -BROWSER_OPEN = open -endif - -all: html - -html: html-latest - -html-latest: prepare $(IMAGES_TS) $(DEST_HTML) - -pdf: prepare $(DEST_PDF) - -prepare: - @if [ "$(BUILD)" != upstream -a "$(BUILD)" != downstream ]; then echo "BUILD must be 'upstream' or 'downstream'."; exit 1; fi - @mkdir -p $(BUILD_DIR) - @mkdir -p $(DEST_DIR) $(IMAGES_DIR) - -clean: - @rm -rf "$(DEST_DIR)" "$(DEST_PDF)" - -watch-html: - @which inotifywait > /dev/null || ( echo "ERROR: inotifywait not found, install inotify-tools" && exit 1 ) - while true; do \ - inotifywait -r -e modify -e create -e delete .; \ - sleep 0.5; \ - $(MAKE) html; \ - done - -open-html: html - ${BROWSER_OPEN} "file://$(realpath $(ROOTDIR)/$(DEST_HTML))" - -open-pdf: pdf - ${BROWSER_OPEN} "$(realpath $(ROOTDIR)/$(DEST_PDF))" - -$(IMAGES_TS): $(IMAGES) - cp $? $(IMAGES_DIR) - touch $(IMAGES_TS) - -$(DEST_HTML): $(ALL_SOURCES) - $(BUNDLE_EXEC) asciidoctor -a source-highlighter=highlightjs -a highlightjs-languages="yaml,bash" -a highlightjs-theme="monokai" --failure-level WARN -a build=$(BUILD) -a build_variant=$(BUILD_VARIANT) -b xhtml5 -d book -o $@ $(MAIN_SOURCE) - -$(DEST_PDF): $(ALL_SOURCES) - $(BUNDLE_EXEC) asciidoctor-pdf -a build=$(BUILD) -a build_variant=$(BUILD_VARIANT) -d book -o $@ $(MAIN_SOURCE) $(IMAGES) diff --git a/docs_user/adoption-attributes.adoc b/docs_user/adoption-attributes.adoc deleted file mode 100644 index 21d2e7093..000000000 --- a/docs_user/adoption-attributes.adoc +++ /dev/null @@ -1,242 +0,0 @@ -:ProductVersion: 18.0 -:context: assembly -:build: downstream - -ifeval::["{build}" != "downstream"] -:rhocp_long: OpenShift -:rhos_long: Red{nbsp}Hat OpenStack Services on OpenShift (RHOSO) -:rhos_long_noacro: Red{nbsp}Hat OpenStack Services on OpenShift -:rhos_acro: RHOSO -:rhos_prev_long: OpenStack -:OpenStackShort: OSP -:OpenShiftShort: OCP -:ocp_curr_ver: 4.16 -:rhos_curr_ver: Antelope -:rhos_prev_ver: -:rhos_z_stream: 0 -:rhel_curr_ver: 9.4 -:rhel_prev_ver: 9.2 -:OpenStackPreviousInstaller: TripleO -:Ceph: Ceph -:CephCluster: Ceph Storage -:CephVernum: Reef - -//Components and services - -//Identity service (keystone) -:identity_service_first_ref: Identity service (keystone) -:identity_service: Identity service - -//Shared File Systems service (manila) -:rhos_component_storage_file_first_ref: Shared File Systems service (manila) -:rhos_component_storage_file: Shared File Systems service - -//OpenStack Key Manager (barbican) -:key_manager_first_ref: Key Manager service (barbican) -:key_manager: Key Manager service - -//OpenStack Networking service (neutron) -:networking_first_ref: Networking service (neutron) -:networking_service: Networking service - -//OpenStack Loadbalancer service (octavia) -:loadbalancer_first_ref: Load-balancing service (octavia) -:loadbalancer_service: Load-balancing service - -//Openstack DNS service (designate) -:dns_first_ref: DNS service (designate) -:dns_service: DNS service - -//Object Storage service (swift) -:object_storage_first_ref: Object Storage service (swift) -:object_storage: Object Storage service - -//Image service (glance) -:image_service_first_ref: Image Service (glance) -:image_service: Image service - -//Compute service (nova) -:compute_service_first_ref: Compute service (nova) -:compute_service: Compute service - -//Block Storage (cinder) -:block_storage_first_ref: Block Storage service (cinder) -:block_storage: Block Storage service - -//Dashboard service (horizon) -:dashboard_first_ref: Dashboard service (horizon) -:dashboard_service: Dashboard service - -//Bare Metal Provisioning service (ironic) -:bare_metal_first_ref: Bare Metal Provisioning service (ironic) -:bare_metal: Bare Metal Provisioning service - -//Orchestration service (heat) -:orchestration_first_ref: Orchestration service (heat) -:orchestration: Orchestration service - -//Telemetry service -:telemetry: Telemetry service - -endif::[] - -ifeval::["{build}" == "downstream"] -:rhos_long: Red{nbsp}Hat OpenStack Services on OpenShift (RHOSO) -:rhos_long_noacro: Red{nbsp}Hat OpenStack Services on OpenShift -:rhos_acro: RHOSO -:rhos_prev_long: Red{nbsp}Hat OpenStack Platform -:OpenStackShort: RHOSP -:rhos_curr_ver: 18.0 -:rhos_prev_ver: 17.1 -:rhos_z_stream: 0 -:rhel_curr_ver: 9.4 -:rhel_prev_ver: 9.2 -:rhocp_long: Red Hat OpenShift Container Platform (RHOCP) -:OpenShiftShort: RHOCP -:ocp_curr_ver: 4.16 -:OpenStackPreviousInstaller: director -:Ceph: Red Hat Ceph Storage -:CephCluster: Red Hat Ceph Storage -:CephVernum: 7 - - -// Ceph 9 IBM PDF paths - update these when Ceph 9 minor version changes -:ceph9_pdf_path: SSEG27_9.9.1/out/91 -:ceph9_version: 9.9.1 - -//Components and services - -//Identity service (keystone) -:identity_service_first_ref: Identity service (keystone) -:identity_service: Identity service - -//Shared File Systems service (manila) -:rhos_component_storage_file_first_ref: Shared File Systems service (manila) -:rhos_component_storage_file: Shared File Systems service - -//OpenStack Key Manager (barbican) -:key_manager_first_ref: Key Manager service (barbican) -:key_manager: Key Manager service - -//OpenStack Networking service (neutron) -:networking_first_ref: Networking service (neutron) -:networking_service: Networking service - -//OpenStack Loadbalancer service (octavia) -:loadbalancer_first_ref: Load-balancing service (octavia) -:loadbalancer_service: Load-balancing service - -//Openstack DNS service (designate) -:dns_first_ref: DNS service (designate) -:dns_service: DNS service - -//Object Storage service (swift) -:object_storage_first_ref: Object Storage service (swift) -:object_storage: Object Storage service - -//Image service (glance) -:image_service_first_ref: Image Service (glance) -:image_service: Image service - -//Compute service (nova) -:compute_service_first_ref: Compute service (nova) -:compute_service: Compute service - -//Block Storage (cinder) -:block_storage_first_ref: Block Storage service (cinder) -:block_storage: Block Storage service - -//Dashboard service (horizon) -:dashboard_first_ref: Dashboard service (horizon) -:dashboard_service: Dashboard service - -//Bare Metal Provisioning service (ironic) -:bare_metal_first_ref: Bare Metal Provisioning service (ironic) -:bare_metal: Bare Metal Provisioning service - -//Orchestration service (heat) -:orchestration_first_ref: Orchestration service (heat) -:orchestration: Orchestration service - -//Telemetry service -:telemetry: Telemetry service -endif::[] - -ifeval::["{build_variant}" == "ospdo"] -:OpenStackPreviousInstaller: director Operator -endif::[] - - -// Common URLs. Do not override. Do not delete. -:base_url: https://access.redhat.com/documentation -:defaultURL: https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html -:defaultOCPURL: https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp_curr_ver}/html -:defaultCephURL: https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/{CephVernum}/html - -// books - URLs and titles -:adopting-data-plane: {defaultURL}/adopting_the_red_hat_openstack_platform_data_plane -:auto-scaling: {defaultURL}/auto-scaling_for_instances -:backing-up-volumes: {defaultURL}/backing_up_block_storage_volumes -:backing-up: {defaultURL}/backing_up_and_restoring_the_undercloud_and_control_plane_nodes -:barbican: {defaultURL}/managing_secrets_with_the_key_manager_service -:bare-metal: {defaultURL}/configuring_the_bare_metal_provisioning_service -:bgp: {defaultURL}/configuring_dynamic_routing -:bgp-t: Configuring dynamic routing -:commandline-ref: {defaultURL}/command_line_interface_reference -:commandline-ref-t: Command line interface reference -:configuration-ref: {defaultURL}/configuration_reference -:configure-compute: {defaultURL}/configuring_the_compute_service_for_instance_creation -:configure-compute-t: Configuring the Compute service for instance creation -:configuring-storage: {defaultURL}/configuring_persistent_storage -:configuring-storage-t: Configuring persistent storage -:creating-images: {defaultURL}/creating_and_managing_images -:creating-instances: {defaultURL}/creating_and_managing_instances -:creating-instances-t: Creating and managing instances -:customizing-rhoso: {defaultURL}/customizing_the_red_hat_openstack_services_on_openshift_deployment -:customizing-rhoso-t: Customizing the Red Hat OpenStack Services on OpenShift deployment -:dashboard: {defaultURL}/managing_cloud_resources_with_the_openstack_dashboard -:dcn: {defaultURL}/deploying_a_distributed_compute_node_dcn_architecture -:deploy-at-scale: {defaultURL}/deploying_red_hat_openstack_platform_at_scale -:deploy-in-rhocp: {defaultURL}/deploying_an_overcloud_in_a_red_hat_openshift_container_platform_cluster_with_director_operator -:deploying-rhoso: {defaultURL}/deploying_red_hat_openstack_services_on_openshift -:deploying-rhoso-t: Deploying Red Hat OpenStack Services on OpenShift -:designate: {defaultURL}/configuring_dns_as_a_service -:designate-t: Configuring DNS as a service -:existing-ceph: {defaultURL}/integrating_an_overcloud_with_an_existing_red_hat_ceph_storage_cluster -:external-identity: {defaultURL}/integrating_openstack_identity_with_external_user_management_services -:ffu: {defaultURL}/framework_for_upgrades_16.2_to_17.1 -:firewall-rules: {defaultURL}/firewall_rules_for_red_hat_openstack_platform -:ha-for-instances: {defaultURL}/configuring_high_availability_for_instances -:hci: {defaultURL}/deploying_a_hyperconverged_infrastructure_environment -:hci-t: Deploying a hyperconverged infrastructure environment -:identity: {defaultURL}/managing_openstack_identity_resources -:installing-director: {defaultURL}/installing_and_managing_red_hat_openstack_platform_with_director -:intro-to-containers: {defaultURL}/introduction_to_containerized_services_in_red_hat_openstack_platform -:intro-to-rhosp: {defaultURL}/introduction_to_red_hat_openstack_platform -:ipv6: {defaultURL}/configuring_ipv6_networking_for_the_overcloud -:managing-ha: {defaultURL}/managing_high_availability_services -:migrating-to-ovn: {defaultURL}/migrating_to_the_ovn_mechanism_driver -:minor-update: {defaultURL}/performing_a_minor_update_of_red_hat_openstack_platform -:network-config: {defaultURL}/configuring_networking_services -:network-config-t: Configuring networking services -:network-manage: {defaultURL}/managing_networking_resources -:network-manage-t: Managing networking resources -:nfv: {defaultURL}/deploying_a_network_functions_virtualization_environment -:nfv-t: Deploying a Network Functions Virtualization environment -:observability: {defaultURL}/managing_overcloud_observability -:oc-params: {defaultURL}/overcloud_parameters -:octavia: {defaultURL}/configuring_load_balancing_as_a_service -:octavia-t: Configuring load balancing as a service -:planning: {defaultURL}/planning_your_deployment -:planning-t: Planning your deployment -:release-notes: {defaultURL}/release_notes -:rhos-deployed-ceph: {defaultURL}/deploying_red_hat_ceph_storage_and_red_hat_openstack_platform_together_with_director -:security-guide: {defaultURL}/hardening_red_hat_openstack_platform -:spine-leaf: {defaultURL}/configuring_spine-leaf_networking -:spine-leaf-t: Configuring spine-leaf networking -:stf-release-notes: {defaultURL}/service_telemetry_framework_release_notes_1.5 -:stf: {defaultURL}/service_telemetry_framework_1.5 -:test-suite: {defaultURL}/validating_your_cloud_with_the_red_hat_openstack_platform_integration_test_suite - -// Specific links -:setup-tlse: {defaultURL}/hardening_red_hat_openstack_platform/assembly_securing-rhos-with-tls-and-pki_security_and_hardening#proc_implementing-tls-e-with-ansible_encryption-and-key-management[Implementing TLS-e with Ansible] diff --git a/docs_user/assemblies/assembly_adopting-key-manager-service-with-hsm.adoc b/docs_user/assemblies/assembly_adopting-key-manager-service-with-hsm.adoc deleted file mode 100644 index feafa9145..000000000 --- a/docs_user/assemblies/assembly_adopting-key-manager-service-with-hsm.adoc +++ /dev/null @@ -1,34 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="adopting-key-manager-service-with-hsm_{context}"] - -:context: hsm-integration - -= Adopting the {key_manager} with HSM integration - -[role="_abstract"] -Adopt the {key_manager_first_ref} with HSM integration to {rhos_long} to preserve HSM functionality and maintain access to HSM-backed secrets. - -For additional information about the {key_manager} before you start the adoption, see the following resources: - -* {key_manager} service configuration documentation -* Hardware security module vendor-specific documentation -* OpenStack Barbican PKCS#11 plugin documentation - -include::../modules/con_key-manager-service-hsm-adoption-approaches.adoc[leveloffset=+1] - -include::../modules/proc_adopting-key-manager-service-with-proteccio-hsm.adoc[leveloffset=+1] - -include::../modules/proc_adopting-key-manager-service-with-hsm-integration.adoc[leveloffset=+1] - -include::../assemblies/assembly_troubleshooting-key-manager-hsm-adoption.adoc[leveloffset=+1] - -include::../assemblies/assembly_troubleshooting-key-manager-proteccio-adoption.adoc[leveloffset=+1] - -include::../modules/proc_rolling-back-the-hsm-adoption.adoc[leveloffset=+1] - - - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_adopting-openstack-control-plane-services.adoc b/docs_user/assemblies/assembly_adopting-openstack-control-plane-services.adoc deleted file mode 100644 index e8d333688..000000000 --- a/docs_user/assemblies/assembly_adopting-openstack-control-plane-services.adoc +++ /dev/null @@ -1,60 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="adopting-openstack-control-plane-services_{context}"] - -:context: adopt-control-plane - -= Adopting {rhos_prev_long} control plane services - -[role="_abstract"] -Adopt your {rhos_prev_long} {rhos_prev_ver} control plane services to deploy them in the {rhos_long} {rhos_curr_ver} control plane. - -include::../modules/proc_adopting-the-identity-service.adoc[leveloffset=+1] - -include::../modules/proc_configuring-federation-for-keystone.adoc[leveloffset=+1] - -include::../modules/proc_configuring-ldap-with-domain-specific-drivers.adoc[leveloffset=+1] - -include::../modules/proc_adopting-key-manager-service.adoc[leveloffset=+1] - -include::../assemblies/assembly_adopting-key-manager-service-with-hsm.adoc[leveloffset=+1] - -include::../modules/proc_adopting-the-networking-service.adoc[leveloffset=+1] - -include::../modules/proc_configuring-control-plane-networking-for-spine-leaf.adoc[leveloffset=+1] - -include::../modules/proc_adopting-the-object-storage-service.adoc[leveloffset=+1] - -include::../assemblies/assembly_adopting-the-image-service.adoc[leveloffset=+1] - -include::../modules/proc_adopting-the-placement-service.adoc[leveloffset=+1] - -include::../assemblies/assembly_adopting-the-bare-metal-provisioning-service.adoc[leveloffset=+1] - -include::../modules/proc_adopting-the-compute-service.adoc[leveloffset=+1] - -include::../modules/proc_adopting-the-block-storage-service.adoc[leveloffset=+1] - -include::../modules/proc_adopting-block-storage-service-with-dcn-backend.adoc[leveloffset=+1] - -include::../modules/proc_adopting-the-openstack-dashboard.adoc[leveloffset=+1] - -include::../assemblies/assembly_adopting-the-shared-file-systems-service.adoc[leveloffset=+1] - -include::../modules/proc_adopting-the-orchestration-service.adoc[leveloffset=+1] - -include::../modules/proc_adopting-the-loadbalancer-service.adoc[leveloffset=+1] - -include::../modules/proc_adopting-telemetry-services.adoc[leveloffset=+1] - -include::../modules/proc_adopting-the-dns-service.adoc[leveloffset=+1] - -include::../modules/proc_adopting-autoscaling.adoc[leveloffset=+1] - -include::../modules/proc_pulling-configuration-from-a-tripleo-deployment.adoc[leveloffset=+1] - -include::../modules/proc_rolling-back-the-control-plane-adoption.adoc[leveloffset=+1] - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_adopting-the-bare-metal-provisioning-service.adoc b/docs_user/assemblies/assembly_adopting-the-bare-metal-provisioning-service.adoc deleted file mode 100644 index 48d1eaa50..000000000 --- a/docs_user/assemblies/assembly_adopting-the-bare-metal-provisioning-service.adoc +++ /dev/null @@ -1,18 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="adopting-the-bare-metal-provisioning-service_{context}"] - -:context: adopting-bare-metal-provisioning - -= Adopting the Bare Metal Provisioning service - -[role="_abstract"] -Review information about your {bare_metal_first_ref} configuration and then adopt the {bare_metal} to the {rhos_long_noacro} control plane. - -include::../modules/con_bare-metal-provisioning-service-configurations.adoc[leveloffset=+1] - -include::../modules/proc_deploying-the-bare-metal-provisioning-service.adoc[leveloffset=+1] - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_adopting-the-data-plane.adoc b/docs_user/assemblies/assembly_adopting-the-data-plane.adoc deleted file mode 100644 index d0ef53c54..000000000 --- a/docs_user/assemblies/assembly_adopting-the-data-plane.adoc +++ /dev/null @@ -1,40 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="adopting-data-plane_{context}"] - -:context: data-plane - -= Adopting the data plane - -[role="_abstract"] -Adopting the {rhos_long} data plane involves the following steps: - -ifeval::["{build_variant}" != "ospdo"] -. Stop any remaining services on the {rhos_prev_long} ({OpenStackShort}) {rhos_prev_ver} control plane. -endif::[] -. Deploy the required custom resources. -. Perform a fast-forward upgrade on Compute services from {OpenStackShort} {rhos_prev_ver} to {rhos_acro} {rhos_curr_ver}. -. Adopt Networker services to the {rhos_acro} data plane. - -[WARNING] -After the {rhos_acro} control plane manages the newly deployed data plane, you must not re-enable services on the {OpenStackShort} {rhos_prev_ver} control plane and data plane. If you re-enable services, workloads are managed by two control planes or two data planes, resulting in data corruption, loss of control of existing workloads, inability to start new workloads, or other issues. - -include::../modules/proc_stopping-infrastructure-management-and-compute-services.adoc[leveloffset=+1] - -include::../modules/proc_adopting-compute-services-to-the-data-plane.adoc[leveloffset=+1] - -include::../modules/proc_configuring-dcn-data-plane-nodesets.adoc[leveloffset=+1] - -include::../modules/proc_adopting-compute-services-with-dcn-backend.adoc[leveloffset=+1] - -include::../modules/proc_performing-a-fast-forward-upgrade-on-compute-services.adoc[leveloffset=+1] - -include::../modules/proc_adopting-networker-services-to-the-data-plane.adoc[leveloffset=+1] - -include::../modules/proc_enabling-high-availability-for-instances.adoc[leveloffset=+1] - -include::../modules/proc_performing-post-adoption-cleanup-of-load-balancers.adoc[leveloffset=+1] - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_adopting-the-image-service.adoc b/docs_user/assemblies/assembly_adopting-the-image-service.adoc deleted file mode 100644 index 4f79f331b..000000000 --- a/docs_user/assemblies/assembly_adopting-the-image-service.adoc +++ /dev/null @@ -1,43 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="adopting-the-image-service_{context}"] - -:context: image-service - -= Adopting the {image_service} - -[role="_abstract"] -To adopt the {image_service_first_ref} you patch an existing `OpenStackControlPlane` custom resource (CR) that has the {image_service} disabled. The patch starts the service with the configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) environment. - -The {image_service} adoption is complete if you see the following results: - -* The `GlanceAPI` service up and running. -* The {identity_service} endpoints are updated, and the same back end of the source cloud is available. - -To complete the {image_service} adoption, ensure that your environment meets the following criteria: - -* You have a running {OpenStackPreviousInstaller} environment (the source cloud). -* You have a Single Node OpenShift or OpenShift Local that is running in the {rhocp_long} cluster. -* Optional: You can reach an internal/external `Ceph` cluster by both `crc` and {OpenStackPreviousInstaller}. - -If you have image quotas in {OpenStackShort} {rhos_prev_ver}, these quotas are transferred to {rhos_long} {rhos_curr_ver} because the image quota system in {rhos_curr_ver} is disabled by default. If you enable image quotas in {rhos_acro} {rhos_curr_ver}, the new quotas replace the legacy quotas from {OpenStackShort} {rhos_prev_ver}. - -include::../modules/proc_adopting-image-service-with-object-storage-backend.adoc[leveloffset=+1] - -include::../modules/proc_adopting-image-service-with-block-storage-backend.adoc[leveloffset=+1] - -include::../modules/proc_adopting-image-service-with-nfs-backend.adoc[leveloffset=+1] - -include::../modules/proc_adopting-image-service-with-ceph-backend.adoc[leveloffset=+1] - -include::../modules/proc_adopting-image-service-with-dcn-backend.adoc[leveloffset=+1] - -include::../modules/proc_verifying-the-image-service-adoption.adoc[leveloffset=+1] - -[role="_additional-resources"] -== Additional resources -* link:{defaultURL}/customizing_persistent_storage/assembly_glance-configuring-quotas_osp[Customizing Image service (glance) quota limits] - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_adopting-the-shared-file-systems-service.adoc b/docs_user/assemblies/assembly_adopting-the-shared-file-systems-service.adoc deleted file mode 100644 index 1908d406b..000000000 --- a/docs_user/assemblies/assembly_adopting-the-shared-file-systems-service.adoc +++ /dev/null @@ -1,32 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="adopting-the-shared-file-systems-service_{context}"] - -:context: adopting-shared-file-systems - -= Adopting the {rhos_component_storage_file} - -[role="_abstract"] -The {rhos_component_storage_file_first_ref} provides a self-service API to create and manage file shares. File shares are built for concurrent read/write access from multiple clients, making the Shared File Systems service in cloud environments that require a ReadWriteMany persistent storage. - -File shares in {rhos_acro} require network access. Ensure that network plans match the {rhos_prev_long} environment to maintain tenant connectivity during adoption. The {rhos_component_storage_file} control plane services are not in the data path. Shutting down the API, scheduler, and share manager services do not impact access to existing shared file systems. - -Typically, storage and storage device management are separate networks. Shared File Systems services only need access to the storage device management network. -For example, if you used a {CephCluster} cluster in the deployment, the "storage" -network refers to the {CephCluster} cluster's public network, and the Shared File Systems service's share manager service needs to be able to reach it. - -The {rhos_component_storage_file} supports the following storage networking scenarios: - -* You can directly control the networking for your respective file shares. -* The {rhos_acro} administrator configures the storage networking. - - -include::../modules/con_preparing-the-shared-file-systems-service-configuration.adoc[leveloffset=+1] - -include::../modules/proc_deploying-file-systems-service-control-plane.adoc[leveloffset=+1] - -include::../modules/proc_decommissioning-rhosp-standalone-ceph-NFS-service.adoc[leveloffset=+1] - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_configuring-isolated-networks.adoc b/docs_user/assemblies/assembly_configuring-isolated-networks.adoc deleted file mode 100644 index 613feaa79..000000000 --- a/docs_user/assemblies/assembly_configuring-isolated-networks.adoc +++ /dev/null @@ -1,35 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="configuring-isolated-networks_{context}"] - -:context: isolated-networks - -= Configuring isolated networks - -[role="_abstract"] -Before you begin replicating your existing VLAN and IPAM configuration in the {rhos_long} environment, you must have the following IP address allocations for the new control plane services: - -* 1 IP address for each isolated network on each {rhocp_long} worker node. You configure these IP addresses in the `NodeNetworkConfigurationPolicy` custom resources (CRs) for the {OpenShiftShort} worker nodes. -* 1 IP range for each isolated network for the data plane nodes. You configure these ranges in the `NetConfig` CRs for the data plane nodes. -* 1 IP range for each isolated network for control plane services. These ranges -enable pod connectivity for isolated networks in the `NetworkAttachmentDefinition` CRs. -* 1 IP range for each isolated network for load balancer IP addresses. These IP ranges define load balancer IP addresses for MetalLB in the `IPAddressPool` CRs. - -[NOTE] -The exact list and configuration of isolated networks in the following procedures should reflect the actual {rhos_prev_long} environment. The number of isolated networks might differ from the examples used in the procedures. The IPAM scheme might also differ. Only the parts of the configuration that are relevant to configuring networks are shown. The values that are used in the following procedures are examples. Use values that are specific to your configuration. - -include::../modules/proc_configuring-openshift-worker-nodes.adoc[leveloffset=+1] - -include::../modules/proc_configuring-networking-for-control-plane-services.adoc[leveloffset=+1] - -include::../modules/proc_configuring-data-plane-nodes.adoc[leveloffset=+1] - -[role="_additional-resources"] -== Additional resources -* xref:configuring-openshift-worker-nodes_isolated-networks[Configuring {OpenShiftShort} worker nodes] -* xref:configuring-data-plane-nodes_isolated-networks[Configuring data plane nodes] -* xref:configuring-networking-for-control-plane-services_isolated-networks[Configuring the networking for control plane services] - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_configuring-network-for-RHOSO-deployment.adoc b/docs_user/assemblies/assembly_configuring-network-for-RHOSO-deployment.adoc deleted file mode 100644 index 07e6705fa..000000000 --- a/docs_user/assemblies/assembly_configuring-network-for-RHOSO-deployment.adoc +++ /dev/null @@ -1,42 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="configuring-network-for-RHOSO-deployment_{context}"] - -:context: configuring-network - -= Configuring the network for the {rhos_long_noacro} deployment - -[role="_abstract"] -When you adopt a new {rhos_long} deployment, you must align the network -configuration with the adopted cluster to maintain connectivity for existing -workloads. - -Perform the following tasks to incorporate the existing network configuration: - -* Configure {rhocp_long} worker nodes to align VLAN tags and IP Address Management (IPAM) configuration with the existing deployment. -* Configure control plane services to use compatible IP ranges for service and load-balancing IP addresses. -* Configure data plane nodes to use corresponding compatible configuration for VLAN tags and IPAM. - -When configuring nodes and services, the general approach is as follows: - -* For IPAM, you can either reuse subnet ranges from the existing deployment or, if there is a shortage of free IP addresses in existing subnets, define new ranges for the new control plane services. If you define new ranges, you configure IP routing between the old and new ranges. -* For VLAN tags, always reuse the configuration from the existing deployment. - -include::../modules/proc_retrieving-network-information-from-your-existing-deployment.adoc[leveloffset=+1] - -include::../assemblies/assembly_planning-your-ipam-configuration.adoc[leveloffset=+1] - -include::../assemblies/assembly_configuring-isolated-networks.adoc[leveloffset=+1] - -[role="_additional-resources"] -== Additional resources -ifeval::["{build_variant}" == "ospdo"] -* link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html-single/deploying_an_overcloud_in_a_red_hat_openshift_container_platform_cluster_with_director_operator/index#proc_creating-an-overcloud-network-with-the-openstacknetconfig-CRD_OSPdO-networks[Creating networks with director Operator] -endif::[] -* xref:planning-your-ipam-configuration_configuring-network[Planning your IPAM configuration] -* link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/deploying_red_hat_openstack_services_on_openshift/assembly_preparing-rhoso-networks_preparing[Preparing networks for Red Hat OpenStack Services on OpenShift] - - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_migrating-ceph-cluster.adoc b/docs_user/assemblies/assembly_migrating-ceph-cluster.adoc deleted file mode 100644 index 00431b17f..000000000 --- a/docs_user/assemblies/assembly_migrating-ceph-cluster.adoc +++ /dev/null @@ -1,55 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="ceph-migration_{context}"] - -= Migrating the {Ceph} cluster - -:context: migrating-ceph - -[role="_abstract"] -In the context of data plane adoption, where the {rhos_prev_long} -({OpenStackShort}) services are redeployed in {rhocp_long}, you migrate a -{OpenStackPreviousInstaller}-deployed {CephCluster} cluster by using a process -called “externalizing” the {CephCluster} cluster. - -There are two deployment topologies that include an internal {CephCluster} -cluster: - -* {OpenStackShort} includes dedicated {CephCluster} nodes to host object - storage daemons (OSDs) - -* Hyperconverged Infrastructure (HCI), where Compute and Storage services are - colocated on hyperconverged nodes - -In either scenario, there are some {Ceph} processes that are deployed on -{OpenStackShort} Controller nodes: {Ceph} monitors, Ceph Object Gateway (RGW), -Rados Block Device (RBD), Ceph Metadata Server (MDS), Ceph Dashboard, and NFS -Ganesha. To migrate your {CephCluster} cluster, you must decommission the -Controller nodes and move the {Ceph} daemons to a set of target nodes that are -already part of the {CephCluster} cluster. - -== Prerequisites - -* Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see "{Ceph} prerequisites" in the Adoption overview chapter. - -include::../modules/ref_ceph-migration-dcn.adoc[leveloffset=+1] - -include::../modules/ref_ceph-daemon-cardinality.adoc[leveloffset=+1] - -include::assembly_migrating-ceph-monitoring-stack.adoc[leveloffset=+1] - -include::../modules/proc_migrating-ceph-mds.adoc[leveloffset=+1] - -include::assembly_migrating-ceph-rgw.adoc[leveloffset=+1] - -include::assembly_migrating-ceph-rbd.adoc[leveloffset=+1] - -include::../modules/proc_migrating-ceph-post.adoc[leveloffset=+1] - -[role="_additional-resources"] -== Additional resources -* xref:red-hat-ceph-storage-prerequisites_configuring-network[{Ceph} prerequisites] - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_migrating-ceph-monitoring-stack.adoc b/docs_user/assemblies/assembly_migrating-ceph-monitoring-stack.adoc deleted file mode 100644 index 20978422b..000000000 --- a/docs_user/assemblies/assembly_migrating-ceph-monitoring-stack.adoc +++ /dev/null @@ -1,35 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="migrating-ceph-monitoring_{context}"] - -:context: migrating-ceph-monitoring - -= Migrating the monitoring stack component to new nodes within an existing {Ceph} cluster - -[role="_abstract"] -The {Ceph} Dashboard module adds web-based monitoring and administration to the -Ceph Manager. With {OpenStackPreviousInstaller}-deployed {Ceph}, the {Ceph} Dashboard is enabled as part of the overcloud deploy and is composed of the following components: - -* Ceph Manager module -* Grafana -* Prometheus -* Alertmanager -* Node exporter - -The {Ceph} Dashboard containers are included through `tripleo-container-image-prepare` parameters, and high availability (HA) relies -on `HAProxy` and `Pacemaker` to be deployed on the {rhos_prev_long} ({OpenStackShort}) environment. For an external {CephCluster} cluster, HA is not supported. - -== Prerequisites -You migrate and relocate the Ceph Monitoring components to free Controller nodes. Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see "{Ceph} prerequisites" in the "Adoption overview" chapter. - - -include::../assemblies/assembly_migrating-monitoring-stack-to-target-nodes.adoc[leveloffset=+1] - -[role="_additional-resources"] -== Additional resources -* xref:red-hat-ceph-storage-prerequisites_configuring-network[{Ceph} prerequisites] - - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_migrating-ceph-rbd.adoc b/docs_user/assemblies/assembly_migrating-ceph-rbd.adoc deleted file mode 100644 index 6d5790e1e..000000000 --- a/docs_user/assemblies/assembly_migrating-ceph-rbd.adoc +++ /dev/null @@ -1,28 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="migrating-ceph-rbd_{context}"] - -= Migrating Red Hat Ceph Storage RBD to external RHEL nodes - -:context: migrating-ceph-rbd - -[role="_abstract"] -For Hyperconverged Infrastructure (HCI) or dedicated Storage nodes that are -running {Ceph} {CephVernum} or later, migrate the daemons from the {rhos_prev_long} control plane into the existing external Red Hat Enterprise Linux (RHEL) nodes. - -The external RHEL nodes typically include the Compute nodes for an HCI environment or dedicated storage nodes. - -== Prerequisites -Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see the "{Ceph} prerequisites" in the "Adoption overview" chapter. - -include::../modules/proc_migrating-mgr-from-controller-nodes.adoc[leveloffset=+1] - -include::assembly_migrating-mon-from-controller-nodes.adoc[leveloffset=+1] - -[role="_additional-resources"] -== Additional resources -* xref:red-hat-ceph-storage-prerequisites_configuring-network[{Ceph} prerequisites] - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_migrating-ceph-rgw.adoc b/docs_user/assemblies/assembly_migrating-ceph-rgw.adoc deleted file mode 100644 index 8c469184c..000000000 --- a/docs_user/assemblies/assembly_migrating-ceph-rgw.adoc +++ /dev/null @@ -1,30 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="migrating-ceph-rgw_{context}"] - -:context: migrating-ceph-rgw - -= Migrating {Ceph} RGW to external RHEL nodes - -[role="_abstract"] -For Hyperconverged Infrastructure (HCI) or dedicated Storage nodes, migrate the Ceph Object Gateway (RGW) daemons from the {rhos_prev_long} Controller nodes into the existing external Red Hat Enterprise Linux (RHEL) nodes. - -The RHEL nodes include the Compute nodes for an HCI environment or {Ceph} nodes. Your environment must have {Ceph} {CephVernum} or later and be managed by `cephadm` or Ceph Orchestrator. - -== Prerequisites - -Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see the "{Ceph} prerequisites" in the "Adoption overview" chapter. - -include::../modules/proc_migrating-the-rgw-backends.adoc[leveloffset=+1] - -include::../modules/proc_deploying-a-ceph-ingress-daemon.adoc[leveloffset=+1] - -include::../modules/proc_updating-the-object-storage-endpoints.adoc[leveloffset=+1] - -[role="_additional-resources"] -== Additional resources -* xref:red-hat-ceph-storage-prerequisites_configuring-network[{Ceph} prerequisites] - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_migrating-databases-to-the-control-plane.adoc b/docs_user/assemblies/assembly_migrating-databases-to-the-control-plane.adoc deleted file mode 100644 index 7442298b5..000000000 --- a/docs_user/assemblies/assembly_migrating-databases-to-the-control-plane.adoc +++ /dev/null @@ -1,26 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="migrating-databases-to-the-control-plane_{context}"] - -:context: migrating-databases - -= Migrating databases to the control plane - -[role="_abstract"] -To begin creating the control plane, enable back-end services and import the databases from your original {rhos_prev_long} {rhos_prev_ver} deployment. - -include::../modules/proc_retrieving-topology-specific-service-configuration.adoc[leveloffset=+1] - -include::../modules/proc_deploying-backend-services.adoc[leveloffset=+1] - -include::../modules/proc_configuring-a-ceph-backend.adoc[leveloffset=+1] - -include::../modules/proc_stopping-openstack-services.adoc[leveloffset=+1] - -include::../modules/proc_migrating-databases-to-mariadb-instances.adoc[leveloffset=+1] - -include::../modules/proc_migrating-ovn-data.adoc[leveloffset=+1] - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_migrating-mon-from-controller-nodes.adoc b/docs_user/assemblies/assembly_migrating-mon-from-controller-nodes.adoc deleted file mode 100644 index d63c4962c..000000000 --- a/docs_user/assemblies/assembly_migrating-mon-from-controller-nodes.adoc +++ /dev/null @@ -1,38 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="migrating-mon-from-controller-nodes_{context}"] - -= Migrating Ceph Monitor daemons to {Ceph} nodes - -:context: migrating-ceph-mon - -[role="_abstract"] -Move Ceph Monitor daemons from the {rhos_prev_long} ({OpenStackShort}) Controller nodes to a set of existing {Ceph} nodes, or to a set of {OpenStackShort} Compute nodes if {Ceph} is deployed by {OpenStackPreviousInstaller} with a Hyperconverged Infrastructure (HCI) topology. - -Additional Ceph Monitors are deployed to the target nodes and promoted as _admin nodes to manage the {CephCluster} cluster and perform day 2 operations. - -To migrate the Ceph Monitor daemons, you must perform the following high-level steps: - -. Configure the target nodes for Ceph Monitor migration. -. Drain the source node -. Migrate your Ceph Monitor IP addresses to the target nodes -. Redeploy the Ceph Monitor on the target node -. Verify that the {Cephcluster} cluster is healthy - -Repeat these steps for any additional Controller node that hosts a Ceph Monitor until you migrate all the Ceph Monitor daemons to the target nodes. - - -include::../modules/proc_migrating-mon-from-controller-nodes-config-target-nodes.adoc[leveloffset=+1] - -include::../modules/proc_migrating-mon-from-controller-nodes-drain-host.adoc[leveloffset=+1] - -include::../modules/proc_migrating-mon-from-controller-nodes-network.adoc[leveloffset=+1] - -include::../modules/proc_migrating-mon-from-controller-nodes-redeploy-mon.adoc[leveloffset=+1] - -include::../modules/proc_migrating-mon-from-controller-nodes-verification.adoc[leveloffset=+1] - - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_migrating-monitoring-stack-to-target-nodes.adoc b/docs_user/assemblies/assembly_migrating-monitoring-stack-to-target-nodes.adoc deleted file mode 100644 index 8ac73a4b2..000000000 --- a/docs_user/assemblies/assembly_migrating-monitoring-stack-to-target-nodes.adoc +++ /dev/null @@ -1,25 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="migrating-monitoring-stack-to-target-nodes_{context}"] - -:context: migrating-monitoring-stack - -= Migrating the monitoring stack to the target nodes - -[role="_abstract"] -To migrate the monitoring stack to the target nodes, you add the monitoring label to your existing nodes and update the configuration of each daemon. You do not need to migrate node exporters. These daemons are deployed across -the nodes that are part of the {Ceph} cluster (the placement is ‘*’). - -[NOTE] -Depending on the target nodes and the number of deployed or active daemons, you can either relocate the existing containers to the target nodes, or -select a subset of nodes that host the monitoring stack daemons. High availability (HA) is not supported. Reducing the placement with `count: 1` allows you to migrate the existing daemons in a Hyperconverged Infrastructure, or hardware-limited, scenario without impacting other services. - -include::../modules/proc_migrating-existing-daemons-to-target-nodes.adoc[leveloffset=+1] - -ifeval::["{build}" != "downstream"] -include::../modules/proc_relocating-one-instance-of-a-monitoring-stack-to-migrate-daemons-to-target-nodes.adoc[leveloffset=+1] -endif::[] - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_migrating-the-object-storage-service.adoc b/docs_user/assemblies/assembly_migrating-the-object-storage-service.adoc deleted file mode 100644 index 6fbf3c3bc..000000000 --- a/docs_user/assemblies/assembly_migrating-the-object-storage-service.adoc +++ /dev/null @@ -1,39 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="migrating-the-object-storage-service_{context}"] - -:context: migrate-object-storage-service - -= Migrating the {object_storage} to {rhos_long_noacro} nodes - -[role="_abstract"] -If you are using the {rhos_prev_long} {object_storage_first_ref} as an Object Storage service, you must migrate your Object Storage service to {rhos_long} nodes. - -If you are using the Object Storage API of the Ceph Object Gateway (RGW), you can skip this chapter and migrate your Red Hat Ceph Storage cluster. For more information, see "Migrating the {Ceph} cluster". If you are not planning to migrate Ceph daemons from Controller nodes, you must perform the steps that are described in "Deploying a Ceph ingress daemon" and "Create or update the Object Storage service endpoints". - -You have two options for handling the existing {object_storage} storage nodes: - -* *Migrate data to new {rhos_acro} nodes* : Provision new storage nodes on {rhocp_long} and gradually move data by using the `swift-ring-tool`. -* *Convert existing nodes to data plane nodes*: Keep the data on the same nodes and convert them to data plane nodes that are managed by the data plane operator. - -The data migration happens replica by replica. For example, if you have 3 replicas, move them one at a time to ensure that the other 2 replicas are still operational, which enables you to continue to use the {object_storage} during the migration. - -[NOTE] -Data migration to the new deployment is a long-running process that executes mostly in the background. The {object_storage} replicators move data from old to new nodes, which might take a long time depending on the amount of storage used. To reduce downtime, you can use the old nodes if they are running and continue with adopting other services while waiting for the migration to complete. Performance might be degraded due to the amount of replication traffic in the network. - - -include::../modules/proc_migrating-object-storage-data-to-rhoso-nodes.adoc[leveloffset=+1] - -include::../modules/con_troubleshooting-object-storage-migration.adoc[leveloffset=+1] - -include::../modules/proc_converting-object-storage-nodes.adoc[leveloffset=+1] - -[role="_additional-resources"] -== Additional resources -* xref:ceph-migration_adopt-control-plane[Migrating the {Ceph} cluster] -* xref:deploying-a-ceph-ingress-daemon_migrating-ceph-rgw[Deploying a Ceph ingress daemon] -* xref:updating-the-object-storage-endpoints_migrating-ceph-rgw[Create or update the Object Storage service endpoints] - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_planning-your-ipam-configuration.adoc b/docs_user/assemblies/assembly_planning-your-ipam-configuration.adoc deleted file mode 100644 index 63cc99f70..000000000 --- a/docs_user/assemblies/assembly_planning-your-ipam-configuration.adoc +++ /dev/null @@ -1,61 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="planning-your-ipam-configuration_{context}"] - -:context: ipam-configuration - -= Planning your IPAM configuration - -[role="_abstract"] -In a {rhos_long} deployment, each service that is deployed on the {rhocp_long} -worker nodes requires an IP address from the IP Address Management (IPAM) pool. -In a {rhos_prev_long} ({OpenStackShort}) deployment, all services that are -hosted on a Controller node share the same IP address. - -The {rhos_acro} control plane has different requirements for the number of IP -addresses that are made available for services. Depending on the size of the IP -ranges that are used in the existing {rhos_acro} deployment, you might reuse -these ranges for the {rhos_acro} control plane. - -The total number of IP addresses that are required for the new control plane services in each isolated network is calculated as the sum of the following: - -* The number of {OpenShiftShort} worker nodes. Each worker node requires 1 IP address in the `NodeNetworkConfigurationPolicy` custom resource (CR). -* The number of IP addresses required for the data plane nodes. Each node requires an IP address from the `NetConfig` CRs. -* The number of IP addresses required for control plane services. Each service requires an IP address from the `NetworkAttachmentDefinition` CRs. This number depends on the number of replicas for each service. -* The number of IP addresses required for load balancer IP addresses. Each service requires a Virtual IP address from the `IPAddressPool` CRs. - -For example, a simple single worker node {OpenShiftShort} deployment -with Red Hat OpenShift Local has the following IP ranges defined for the `internalapi` network: - -* 1 IP address for the single worker node -* 1 IP address for the data plane node -* `NetworkAttachmentDefinition` CRs for control plane services: - `X.X.X.30-X.X.X.70` (41 addresses) -* `IPAllocationPool` CRs for load balancer IPs: `X.X.X.80-X.X.X.90` (11 - addresses) - -This example shows a total of 54 IP addresses allocated to the `internalapi` -allocation pools. - -// TODO: update the numbers above for a more realistic multinode cluster. - -The requirements might differ depending on the list of {OpenStackShort} services -to be deployed, their replica numbers, and the number of {OpenShiftShort} worker nodes and data plane nodes. - -Additional IP addresses might be required in future {OpenStackShort} releases, so you must plan for some extra capacity for each of the allocation pools that are used in the new environment. - -After you determine the required IP pool size for the new deployment, you can choose to define new IP address ranges or reuse your existing IP address ranges. Regardless of the scenario, the VLAN tags in the existing deployment are reused in the new deployment. Ensure that the VLAN tags are properly retained in the new configuration. - -ifeval::["{build_variant}" != "ospdo"] -include::../modules/proc_using-new-subnet-ranges.adoc[leveloffset=+1] -endif::[] - -include::../modules/proc_reusing-existing-subnet-ranges.adoc[leveloffset=+1] - -[role="_additional-resources"] -== Additional resources -* xref:configuring-isolated-networks_configuring-network[Configuring isolated networks] - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_post-adoption-tasks.adoc b/docs_user/assemblies/assembly_post-adoption-tasks.adoc deleted file mode 100644 index d67227fe5..000000000 --- a/docs_user/assemblies/assembly_post-adoption-tasks.adoc +++ /dev/null @@ -1,27 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -[id="post-adoption-tasks_{context}"] - -= Post-adoption tasks - -:context: post-adoption - -[role="_abstract"] -Perform the following post-adoption tasks to ensure that your {rhos_long} environment is functioning optimally. - -* After adoption, {rhos_acro} data plane nodes run Red Hat Enterprise Linux (RHEL) 9.2. The data plane nodes can remain on RHEL 9.2; however, you must perform a system update to use the full feature set from the release, and to align your environment with the maximum support lifecycle of {rhos_acro}. -** You can perform a system update any time after you complete the adoption procedure. -** You can defer the system update to a separate maintenance window. -** You can perform the system update on one node set at a time. For example, you can update one node set from RHEL 9.2 to RHEL 9.4 or 9.6 in one maintenance window, and then update a different node set in another maintenance window later. -* If you enabled the high availability for Compute instances (Instance HA) service, remove the Pacemaker components from your Compute nodes. -* Enable TLS Everywhere (TLS-e). -* Verify that you migrated all services from the Controller nodes, and then power off the nodes. If any services are still running in the Controller nodes, such as Open Virtual Networking (ML2/OVN), {object_storage_first_ref}, or {Ceph}, do not power off the nodes. -* Optional: Run tempest to verify that the entire adoption process is working correctly. - -[role="_additional-resources"] -.Additional resources -* link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/updating_your_environment_to_the_latest_maintenance_release/index[Updating your environment to the latest maintenance release] -* xref:enabling-high-availability-for-instances_data-plane[Enabling the high availability for Compute instances service] -* link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html-single/configuring_security_services/index#assembly_enabling-TLS-on-a-deployed-RHOSO-environment[Enabling TLS on a deployed RHOSO environment] -* link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/validating_and_troubleshooting_the_deployed_cloud/index[Validating and troubleshooting the deployed cloud] - -include::../modules/proc_updating-shiftstack-credentials.adoc[leveloffset=+1] diff --git a/docs_user/assemblies/assembly_prepare-director-operator-and-rhoso-for-adoption-process.adoc b/docs_user/assemblies/assembly_prepare-director-operator-and-rhoso-for-adoption-process.adoc deleted file mode 100644 index a37c1c036..000000000 --- a/docs_user/assemblies/assembly_prepare-director-operator-and-rhoso-for-adoption-process.adoc +++ /dev/null @@ -1,18 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="prepare-director-operator-and-rhoso-for-adoption-process_{context}"] - -:context: prepare-director-operator - -= Preparing director Operator for adoption - -[role="_abstract"] -You must prepare your existing director Operator environment and the {rhos_long} environment for adoption. - -include::../modules/proc_preparing-controller-nodes-for-director-operator-adoption.adoc[leveloffset=+1] - -include::../modules/proc_preparing-RHOSO-for-director-operator-adoption.adoc[leveloffset=+1] - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_preparing-an-instance-HA-deployment-for-adoption.adoc b/docs_user/assemblies/assembly_preparing-an-instance-HA-deployment-for-adoption.adoc deleted file mode 100644 index bb10d19e2..000000000 --- a/docs_user/assemblies/assembly_preparing-an-instance-HA-deployment-for-adoption.adoc +++ /dev/null @@ -1,21 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="preparing-an-instance-HA-deployment-for-adoption_{context}"] - -:context: preparing-instance-HA - -= Preparing an Instance HA deployment for adoption - -[role="_abstract"] -To enable the high availability for Compute instances (Instance HA) service after you adopt the {rhos_long_noacro} ({rhos_acro}) {rhos_curr_ver} data plane, perform the following preparation tasks: - -* Create a fencing configuration file to use after you adopt the {rhos_acro} data plane. -* Prevent Pacemaker from monitoring or recovering the Compute nodes. - -include::../modules/proc_maintaining-the-instance-ha-functionality-after-adoption.adoc[leveloffset=+1] - -include::../modules/proc_preventing-pacemaker-from-monitoring-compute-nodes.adoc[leveloffset=+1] - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_preparing-the-block-storage-service-for-adoption.adoc b/docs_user/assemblies/assembly_preparing-the-block-storage-service-for-adoption.adoc deleted file mode 100644 index ca575b0b6..000000000 --- a/docs_user/assemblies/assembly_preparing-the-block-storage-service-for-adoption.adoc +++ /dev/null @@ -1,55 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="preparing-the-block-storage-service_{context}"] -//kgilliga: The content in this file was integrated with "Block storage requirements" (con_block-storage-service-requirements.adoc) -:context: preparing-block-storage - -= Preparing the {block_storage} configurations for adoption - -[role="_abstract"] -The recommended way to deploy {block_storage} volume back ends is to use a {block_storage} volume service for each back end. - -For example, you have an LVM and a Ceph back end and two entries in `cinderVolume`, and you cannot set global defaults for all volume services. You must define a service for each of them: - -[source,yaml] ----- -apiVersion: core.openstack.org/v1beta1 -kind: OpenStackControlPlane -metadata: - name: openstack -spec: - cinder: - enabled: true - template: - cinderVolume: - lvm: - customServiceConfig: | - [DEFAULT] - debug = True - [lvm] -< . . . > - ceph: - customServiceConfig: | - [DEFAULT] - debug = True - [ceph] -< . . . > ----- -+ -[WARNING] -Check that all configuration options are still valid for the new {rhos_long} version. Configuration options might be deprecated, removed, or added. This applies to both back-end driver-specific configuration options and other generic options. - -ifeval::["{build}" != "downstream"] -There are two ways to prepare a {block_storage} configuration for adoption. You can customize the configuration or prepare a quick configuration. There is no difference in how {block_storage} operates with both methods, but you should customize the configuration whenever possible. -endif::[] - - -ifeval::["{build}" != "downstream"] -include::../modules/proc_preparing-block-storage-service-by-using-agnostic-config-file.adoc[leveloffset=+1] - -include::../modules/con_block-storage-service-config-generation-helper-tool.adoc[leveloffset=+1] -endif::[] - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_red-hat-ceph-storage-prerequisites.adoc b/docs_user/assemblies/assembly_red-hat-ceph-storage-prerequisites.adoc deleted file mode 100644 index 59e71a272..000000000 --- a/docs_user/assemblies/assembly_red-hat-ceph-storage-prerequisites.adoc +++ /dev/null @@ -1,37 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="red-hat-ceph-storage-prerequisites_{context}"] - -:context: ceph-prerequisites - -= {Ceph} prerequisites - -[role="_abstract"] -Before you migrate your {Ceph} cluster daemons from your Controller nodes, you must complete the following tasks in your {rhos_prev_long} {rhos_prev_ver} environment to prepare for the {rhos_long} adoption. - -* Upgrade your {Ceph} cluster to release {CephVernum}. For more information, see "Upgrading Red Hat Ceph Storage 6 to 7" in _Framework for upgrades (16.2 to 17.1)_. -* Your {Ceph} {CephVernum} deployment is managed by `cephadm`. -* The undercloud is still available, and the nodes and networks are managed by {OpenStackPreviousInstaller}. -* If you use an externally deployed {Ceph} cluster, you must recreate a `ceph-nfs` cluster in the target nodes as well as propogate the `StorageNFS` network. -* Complete the prerequisites for your specific {Ceph} environment: -** {Ceph} with monitoring stack components -** {Ceph} RGW -** {Ceph} RBD -** NFS Ganesha - - -include::../modules/proc_completing-prerequisites-for-migrating-ceph-monitoring-stack.adoc[leveloffset=+1] - -include::../modules/proc_completing-prerequisites-for-migrating-ceph-rgw.adoc[leveloffset=+1] - -include::../modules/con_completing-prerequisites-for-migrating-ceph-rbd.adoc[leveloffset=+1] - -include::../modules/proc_creating-a-ceph-nfs-cluster.adoc[leveloffset=+1] - -[role="_additional-resources"] -== Additional resources -* link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html-single/framework_for_upgrades_16.2_to_17.1/index#assembly_ceph-6-to-7_upgrade_post-upgrade-external-ceph[Upgrading Red Hat Ceph Storage 6 to 7] - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc b/docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc deleted file mode 100644 index cd34fab09..000000000 --- a/docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc +++ /dev/null @@ -1,52 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="rhoso-180-adoption-overview_{context}"] - -:context: planning - -= {rhos_long_noacro} {rhos_curr_ver} adoption overview - -[role="_abstract"] -Adoption is the process of migrating a {rhos_prev_long} {rhos_prev_ver} control plane to {rhos_long_noacro} {rhos_curr_ver} and upgrading the data plane in-place. Retain existing infrastructure investments and modernize your {OpenStackShort} deployment on a containerized {rhocp_long} foundation. - -To understand the adoption process and to prepare your {OpenStackShort} environment, review the prerequisites, adoption process, and post-adoption tasks. - -[IMPORTANT] -Read the whole adoption guide before you start -the adoption to ensure that you understand the procedure. Prepare the necessary configuration snippets for each {OpenStackShort} service in advance, and test the migration in a representative test environment before you apply it to production. - -include::../modules/con_adoption-limitations.adoc[leveloffset=+1] - -//include::../modules/con_known-issues-adoption.adoc[leveloffset=+1] - -include::../modules/ref_adoption-prerequisites.adoc[leveloffset=+1] - -include::../modules/con_adoption-guidelines.adoc[leveloffset=+1] - -include::../modules/ref_adoption-process-overview.adoc[leveloffset=+1] - -include::../modules/ref_adoption-duration-and-impact.adoc[leveloffset=+1] - -include::../modules/con_dcn-adoption-overview.adoc[leveloffset=+1] - -include::../modules/proc_installing-the-systemd-container-package-on-compute-hosts.adoc[leveloffset=+1] - -include::../modules/con_identity-service-authentication.adoc[leveloffset=+1] - -include::../assemblies/assembly_configuring-network-for-RHOSO-deployment.adoc[leveloffset=+1] - -include::../modules/con_adopting-spine-leaf-networks.adoc[leveloffset=+1] - -include::../assemblies/assembly_storage-requirements.adoc[leveloffset=+1] - -include::../assemblies/assembly_red-hat-ceph-storage-prerequisites.adoc[leveloffset=+1] - -include::../assemblies/assembly_preparing-an-instance-HA-deployment-for-adoption.adoc[leveloffset=+1] - -include::../modules/proc_comparing-configuration-files-between-deployments.adoc[leveloffset=+1] - -include::../modules/con_preventing-config-loss-when-using-oc-patch.adoc[leveloffset=+1] - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_storage-requirements.adoc b/docs_user/assemblies/assembly_storage-requirements.adoc deleted file mode 100644 index 2145cca45..000000000 --- a/docs_user/assemblies/assembly_storage-requirements.adoc +++ /dev/null @@ -1,33 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="storage-requirements_{context}"] - -:context: storage-requirements - -= Storage requirements - -[role="_abstract"] -Storage in a {rhos_prev_long} ({OpenStackShort}) deployment refers to the following types: - -* The storage that is needed for the service to run -* The storage that the service manages - -Before you can deploy the services in {rhos_long}, you must review the storage requirements, plan your {rhocp_long} node selection, prepare your {OpenShiftShort} nodes, and so on. - -//*TODO: Galera, RabbitMQ, Swift, Glance, etc.* - -include::../modules/con_storage-driver-certification.adoc[leveloffset=+1] - -include::../modules/ref_block-storage-service-requirements.adoc[leveloffset=+1] - -include::../modules/con_block-storage-service-limitations.adoc[leveloffset=+1] - -include::../modules/ref_openshift-preparation-for-block-storage-adoption.adoc[leveloffset=+1] - -include::../modules/ref_preparing-block-storage-service-by-customizing-configuration.adoc[leveloffset=+1] - -include::../modules/con_changes-to-cephFS-via-NFS.adoc[leveloffset=+1] - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_troubleshooting-key-manager-hsm-adoption.adoc b/docs_user/assemblies/assembly_troubleshooting-key-manager-hsm-adoption.adoc deleted file mode 100644 index 244f93f1d..000000000 --- a/docs_user/assemblies/assembly_troubleshooting-key-manager-hsm-adoption.adoc +++ /dev/null @@ -1,41 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="troubleshooting-key-manager-hsm-adoption_{context}"] - -= Troubleshooting Key Manager HSM adoption - -:context: troubleshooting-hsm - -[role="_abstract"] -Review troubleshooting guidance for common issues that you might encounter while you perform the HSM-enabled Key Manager (Barbican) service adoption. - -If issues persist after following the troubleshooting guide: - -* Collect adoption logs and configuration for analysis. -* Check the HSM vendor documentation for vendor-specific troubleshooting. -* Verify HSM server status and connectivity independently. -* Review the adoption summary report for additional diagnostic information. - -include::../modules/proc_resolving-config-validation-failures.adoc[leveloffset=+1] - -include::../modules/proc_resolving-missing-HSM-file-prerequisites.adoc[leveloffset=+1] - -include::../modules/proc_resolving-connectivity-issues.adoc[leveloffset=+1] - -include::../modules/proc_resolving-HSM-secret-creation-failures.adoc[leveloffset=+1] - -include::../modules/proc_resolving-custom-image-registry-issues.adoc[leveloffset=+1] - -include::../modules/proc_resolving-hsm-backend-detection-failures.adoc[leveloffset=+1] - -include::../modules/proc_resolving-database-migration-issues.adoc[leveloffset=+1] - -include::../modules/proc_resolving-service-startup-failures.adoc[leveloffset=+1] - -include::../modules/proc_resolving-performance-and-connectivity-issues.adoc[leveloffset=+1] - - - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/assemblies/assembly_troubleshooting-key-manager-proteccio-adoption.adoc b/docs_user/assemblies/assembly_troubleshooting-key-manager-proteccio-adoption.adoc deleted file mode 100644 index 4d589bc89..000000000 --- a/docs_user/assemblies/assembly_troubleshooting-key-manager-proteccio-adoption.adoc +++ /dev/null @@ -1,23 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -ifdef::context[:parent-context: {context}] - -[id="troubleshooting-key-manager-proteccio-adoption_{context}"] - -:context: troubleshooting-proteccio - -= Troubleshooting {key_manager} Proteccio HSM adoption - -[role="_abstract"] -Use this reference to troubleshoot common issues that might occur during {key_manager_first_ref} adoption with Proteccio HSM integration. If Proteccio HSM issues persist, consult the Eviden Trustway documentation and ensure that HSM server configuration matches the client settings. - -include::../modules/proc_resolving-prerequisite-validation-failures.adoc[leveloffset=+1] -include::../modules/proc_resolving-ssh-connection-failures.adoc[leveloffset=+1] -include::../modules/proc_resolving-database-import-failures.adoc[leveloffset=+1] -include::../modules/proc_resolving-custom-image-pull-failures.adoc[leveloffset=+1] -include::../modules/proc_resolving-hsm-certificate-mounting-issues.adoc[leveloffset=+1] -include::../modules/proc_resolving-service-startup-failures.adoc[leveloffset=+1] -include::../modules/proc_resolving-adoption-verification-failures.adoc[leveloffset=+1] - - -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/docs_user/images/.gitkeep b/docs_user/images/.gitkeep deleted file mode 100644 index e69de29bb..000000000 diff --git a/docs_user/main.adoc b/docs_user/main.adoc deleted file mode 100644 index 409244f32..000000000 --- a/docs_user/main.adoc +++ /dev/null @@ -1,35 +0,0 @@ -= Adopting a Red Hat OpenStack Platform 17.1 deployment -:toc: left -:toclevels: 3 -:icons: font -:compat-mode: -:doctype: book -:context: adoption-rhoso -:sectnums: - -include::adoption-attributes.adoc[] - - -include::assemblies/assembly_rhoso-180-adoption-overview.adoc[leveloffset=+1] - -ifeval::["{build_variant}" == "ospdo"] -include::assemblies/assembly_prepare-director-operator-and-rhoso-for-adoption-process.adoc[leveloffset=+1] -endif::[] - -include::modules/proc_migrating-tls-everywhere.adoc[leveloffset=+1] - -include::assemblies/assembly_migrating-databases-to-the-control-plane.adoc[leveloffset=+1] - -ifeval::["{build_variant}" == "ospdo"] -include::modules/proc_ospdo-scale-down-pre-database-adoption.adoc[leveloffset=+1] -endif::[] - -include::assemblies/assembly_adopting-openstack-control-plane-services.adoc[leveloffset=+1] - -include::assemblies/assembly_adopting-the-data-plane.adoc[leveloffset=+1] - -include::assemblies/assembly_migrating-the-object-storage-service.adoc[leveloffset=+1] - -include::assemblies/assembly_migrating-ceph-cluster.adoc[leveloffset=+1] - -include::assemblies/assembly_post-adoption-tasks.adoc[leveloffset=+1] diff --git a/docs_user/modules/cinder-cfg.py b/docs_user/modules/cinder-cfg.py deleted file mode 100644 index 2f7826ed9..000000000 --- a/docs_user/modules/cinder-cfg.py +++ /dev/null @@ -1,801 +0,0 @@ -#!/usr/bin/env python -# Helper tool for adoption of a Director deployed OpenStack. -# Conde is anything but good, though it should be somewhat useful. -# It helps create a draft patch file (cinder.patch) with the cinder -# configuration. -# It may also create a file (cinder-prereq.yaml) with manifests for secrets and -# MachineConfigs depending on the provider cinder configuruation file. -# -import argparse -import base64 -import collections -import copy -import logging -import os - -import yaml - - -LOG = logging -PATCH_FILE = 'cinder.patch' -PREREQ_FILE = 'cinder-prereq.yaml' -VERSION_FILE = 'openstackversion.yaml' - -CINDER_TEMPLATE = """ -spec: - cinder: - enabled: true - apiOverride: - route: {} - template: - databaseInstance: openstack - secret: osp-secret - cinderAPI: - replicas: 3 - override: - service: - internal: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/allow-shared-ip: internalapi - metallb.universe.tf/loadBalancerIPs: 172.17.0.80 - spec: - type: LoadBalancer - cinderScheduler: - replicas: 1 - cinderBackup: - networkAttachments: - - storage - replicas: 0 -""" - -EXTRAMOUNTS_CEPH = """ - extraMounts: - - extraVol: - - propagation: - - CinderVolume - - CinderBackup - - Glance - extraVolType: Ceph - volumes: - - name: ceph - projected: - sources: - - secret: - name: ceph-conf-files - mounts: - - name: ceph - mountPath: "/etc/ceph" - readOnly: true -""" - -MACHINECONFIGS = { - 'iscsid': '''apiVersion: machineconfiguration.openshift.io/v1 -kind: MachineConfig -metadata: - labels: - machineconfiguration.openshift.io/role: master - service: cinder - name: 99-master-cinder-enable-iscsid -spec: - config: - ignition: - version: 3.2.0 - systemd: - units: - - enabled: true - name: iscsid.service -''', - - 'multipathd': '''apiVersion: machineconfiguration.openshift.io/v1 -kind: MachineConfig -metadata: - labels: - machineconfiguration.openshift.io/role: worker - service: cinder - name: 99-master-cinder-enable-multipathd -spec: - config: - ignition: - version: 3.2.0 - storage: - files: - - path: /etc/multipath.conf - overwrite: false - # Mode must be decimal, this is 0600 - mode: 384 - user: - name: root - group: - name: root - contents: - # Source can be a http, https, tftp, s3, gs, or data as per rfc2397 - # This is the rfc2397 text/plain string format - source: data:,defaults%20%7B%0A%20%20user_friendly_names%20no%0A%20%20recheck_wwid%20yes%0A%20%20skip_kpartx%20yes%0A%20%20find_multipaths%20yes%0A%7D%0A%0Ablacklist%20%7B%0A%7D - systemd: - units: - - enabled: true - name: multipathd.service -''', - - 'nvmeof': '''apiVersion: machineconfiguration.openshift.io/v1 -kind: MachineConfig -metadata: - labels: - machineconfiguration.openshift.io/role: worker - service: cinder - name: 99-master-cinder-load-nvme-fabrics -spec: - config: - ignition: - version: 3.2.0 - storage: - files: - - path: /etc/modules-load.d/nvme_fabrics.conf - overwrite: false - # Mode must be decimal, this is 0644 - mode: 420 - user: - name: root - group: - name: root - contents: - # Source can be a http, https, tftp, s3, gs, or data as per rfc2397 - # This is the rfc2397 text/plain string format - source: data:,nvme-fabric -''' -} - -DRIVER_TO_IMAGE_NAME = {'PureISCSIDriver': 'pure', - 'PureFCDriver': 'pure', - 'PureNVMEDriver': 'pure', - 'HPE3PARFCDriver': '3par', - 'HPE3PARISCSIDriver': '3par', - 'VNXDriver': 'dellemc', - 'UnityDriver': 'dellemc', - 'FJDXFCDriver': 'fujitsu', - 'FJDXISCSIDriver': 'fujitsu'} - -# Image location and whether it's outdated or not -IMAGES = { - 'pure': ('registry.connect.redhat.com/purestorage/' - 'openstack-cinder-volume-pure-rhosp-17-0', True), - '3par': ('registry.connect.redhat.com/hpe3parcinder/' - 'openstack-cinder-volume-hpe3parcinder17-0', True), - 'dellemc': ('registry.connect.redhat.com/dellemc/', - 'openstack-cinder-volume-dellemc-rhosp16', True), - 'fujitsu': ('registry.connect.redhat.com/fujitsu/' - 'rhosp15-fujitsu-cinder-volume-161', True), -} - - -def str_presenter(dumper, data): - """Configures yaml for dumping multiline strings - - Ref: https://stackoverflow.com/questions/8640959/how-can-i-control-what-scalar-form-pyyaml-uses-for-my-data - """ - if data.count('\n') > 0: # check for multiline string - return dumper.represent_scalar('tag:yaml.org,2002:str', - data, style='|') - return dumper.represent_scalar('tag:yaml.org,2002:str', data) - - -yaml.add_representer(str, str_presenter) -yaml.representer.SafeRepresenter.add_representer(str, str_presenter) - - -class CinderTransformer(object): - # None means remove the whole section - remove_config = { - 'os_brick': None, - 'coordination': None, - 'oslo_messaging_rabbit': None, - 'oslo_concurrency': None, - 'database': ['connection'], - 'oslo_messaging_notifications': None, - 'keystone_authtoken': ['www_authenticate_uri', - 'auth_url', - 'memcached_servers', - # This should have been set in a secret - 'password', - # We'll add this to Spec.ServiceUser - 'username'], - - # "password" and "username" will probably not be like we want them - # we usually want the cinder user to have access to the nova API - 'service_user': None, - 'barbican': None, - 'DEFAULT': ['transport_url', 'api_paste_config', 'log_dir', - 'glance_api_servers', 'state_path', - 'image_conversion_dir', 'volumes_dir'], - # "password" and "username" will probably not be like we want them - # we usually want the cinder user to have access to the nova API - 'nova': None, - } - - def __init__(self, config_file, skip_machineconfig=False, - only_backends=False, name=None): - self.config_file = config_file - self.do_machineconfig = not skip_machineconfig - self.do_only_backends = only_backends - self.name = name - - self._backends = None - self.processed_data = None - self._username = None - self._secrets = {} - self._machineconfigs = [] - self._extra_volumes = [] - self._custom_images = {} - - self.parse_config() - self.sanity_checks() - - def parse_config(self): - result_cfg = {} - - section_name = '' - # Ignore anything that's out of a section at the beginning of the file - section_options = 0 - - for line in self.config_file: - line = line.strip() - # Remove comments - if not line or line.startswith('#'): - continue - if line.startswith('[') and line.endswith(']'): - section_name = line[1:-1] - # Use setdefault in case section defined multiple times - section_options = result_cfg.setdefault( - section_name, collections.OrderedDict()) - continue - - try: - name, value = line.split('=', 1) - except ValueError: - LOG.warning('Line %s is not a configuration option', line) - continue - name = name.strip() - if not name: - LOG.warning('Weird line is not a valid configuration option ' - 'skipping it', line) - continue - - # Don't use a dict because we can have multiOpt options - section_options.setdefault(name, []).append(value.strip()) - - # Remove empty sections - result = {key: value for key, value in result_cfg.items() if value} - self.config = result - - def get(self, section, option=None, default=None): - res = self.config.get(section, {}) - if option is None: - return res - return res.get(option, default) - - def remove(self, section, option=None, logmsg=False): - if option is None: - if logmsg: - LOG.info('Removing section %s', section) - self.config.pop(section, None) - else: - if logmsg: - LOG.info('Removing option %s from section %s', option, section) - self.config.get(section, {}).pop(option, None) - - @property - def username(self): - if not self._username: - self._username = self.get('keystone_authtoken', 'username') - return self._username - - def sanity_checks(self): - if not self.username: - LOG.warning('Missing keystone username, will use default\n') - - if self.get('barbican'): - LOG.warning("Barbican is configured but it won't match the new " - "deployment configuration, dropping it. Make sure " - "you update the path file include the right " - "configuration.") - - # TODO: Check ssh_hosts_key_file - # TODO: netapp_copyoffload_tool_path - # TODO: nfs_mount_point_base - # TODO: disable_by_file_path - # TODO: disable_by_file_paths - # TODO: FC fc_fabric_ssh_cert_path - - policy_path = self.get('oslo_policy', 'policy_file') - if policy_path: - LOG.warning('Cinder is configured to use %s as policy file, ' - 'please ensure this file is available for the ' - 'podified cinder services using "extraMounts" or ' - 'remove the option.\n', policy_path) - - for section in self.backends + ['backend_defaults']: - verify = self.get(section, 'driver_ssl_cert_verify') - cert_path = self.get(section, 'driver_ssl_cert_path') - if verify and cert_path: - LOG.warning('Using certs in %s from %s, ensure certs are ' - 'available for the podified cinder services using ' - '"extraMounts" or remove the option.\n', - section, cert_path) - - backends = self.get('DEFAULT', 'enabled_backends', [''])[-1].split(',') - if not backends: - LOG.warning('There are no backends configured, cinder volume will ' - 'not be configured.\n') - else: - valid_backends = self.backends - if len(valid_backends) != len(backends): - missing = ','.join(set(backends) - set(valid_backends)) - LOG.warning('Ignoring backends %s that are missing a ' - 'section.\n', missing) - - backends_custom_image = [] - outdated_images = [] - for backend in self.backends: - image, outdated = self.get_image(self.get(backend)) - if image: - backends_custom_image.append(backend) - if outdated: - outdated_images.append(backend) - - if backends_custom_image: - LOG.warning('There are backends (%s) that requires a vendor ' - 'container image, existing OpenStackVersion CR needs ' - 'to be modified, please look at %s file for the ' - 'contents.\n', - ', '.join(backends_custom_image), VERSION_FILE) - - if outdated_images: - LOG.error('Images in %s for some backends (%s) are just ' - 'templates, as there is no certified image ' - 'available yet. THEY WILL NOT WORK\n', - VERSION_FILE, ', '.join(outdated_images)) - - if any('RBDDriver' == self.get_driver(b) for b in self.backends): - LOG.warning('Deployment uses Ceph, so make sure the Ceph ' - 'credentials and configuration are present in ' - 'OpenShift as a secret and then use the extra ' - 'volumes to make them available in all the services ' - 'that would need them. A reference is included in ' - 'the .path file\n') - - if not self.do_only_backends: - username = self.username - nova_username = self.get('nova', 'username') - if nova_username and nova_username != username: - LOG.warning('You were using user %s to talk to Nova, but in ' - 'podified we prefer using the service keystone ' - 'username, in this case %s. Dropping that ' - 'configuration.\n', nova_username, username) - - if self.using_protocol('fc'): - LOG.warning('Configuration is using FC, please ensure all your ' - 'OpenShift nodes have HBAs or use labels to ensure ' - 'that Volume and Backup services are scheduled on ' - 'nodes with HBAs.\n') - - if not self.do_machineconfig: - protocols = [] - if self.using_protocol('iscsi'): - protocols.append('is running iscsid') - if self.using_protocol('nvme'): - protocols.append('have loaded nvme fabrics kernel modules') - if self.using_multipath(): - protocols.append('is running multipathd') - - if protocols: - msg = ' and '.join(protocols) - LOG.warning('Make sure your deployment %s (may require using ' - 'MachineConfig).\n', msg) - - def using_multipath(self): - if self.get('backend_defaults', 'use_multipath_for_image_xfer'): - return True - for backend in self.backends: - if self.get(backend, 'use_multipath_for_image_xfer'): - return True - return False - - def using_protocol(self, protocol): - for backend in self.backends: - method_name = f'uses_{protocol}' - if getattr(self, method_name)(backend): - return True - return False - - def get_driver(self, input): - if isinstance(input, str): - input = self.get(input) - driver = input.get('volume_driver', ['lvm.LVMVolumeDriver']) - class_name = driver[-1].rsplit('.')[-1] - return class_name - - def uses_fc(self, backend_name): - class_name = self.get_driver(backend_name) - if 'fc' in class_name.lower(): - return True - if ('NetAppDriver' == class_name - and 'fc' == self.get(backend_name, - 'netapp_storage_protocol')[-1]): - return True - if (class_name in ('VNXDriver', 'UnityDriver') - and 'FC' == self.get(backend_name, 'storage_protocol')[-1]): - return True - return False - - def uses_iscsi(self, backend_name): - class_name = self.get_driver(backend_name) - if 'iscsi' in class_name.lower(): - return True - if ('NetAppDriver' == class_name - and 'iscsi' == self.get(backend_name, - 'netapp_storage_protocol')[-1]): - return True - if (class_name in ('VNXDriver', 'UnityDriver') - and 'iSCSI' == self.get(backend_name, 'storage_protocol')[-1]): - return True - - if ('LVMVolumeDrivers' == class_name - and self.get(backend_name, 'target_protocol')[-1] - in ('lioadm', 'tgtadm', 'iscsictl')): - return True - return False - - def uses_nvme(self, backend_name): - class_name = self.get_driver(backend_name) - if 'nvme' in class_name.lower(): - return True - if ('NetAppDriver' == class_name - and 'iscsi' == self.get(backend_name, - 'netapp_storage_protocol')[-1]): - return True - - if ('LVMVolumeDrivers' == class_name - and 'nvme' in self.get(backend_name, - 'target_protocol')[-1]): - return True - return False - - @property - def processed(self): - return bool(self.processed_data) - - def _process(self): - self.username # Ensure we save the username - - # Remove sections and options defined in class's remove_config - for section, options in list(self.remove_config.items()): - for option in (options if options else [None]): - self.remove(section, option) - - if self.do_machineconfig: - if self.using_multipath(): - self._machineconfigs.append('multipathd') - if self.using_protocol('iscsi'): - self._machineconfigs.append('iscsid') - if self.using_protocol('nvme'): - self._machineconfigs.append('nvmeof') - - res = {} - res.update(self.get_backup()) - res.update(self.get_volumes()) - res.update(self.get_scheduler()) - res.update(self.get_api()) - res.update(self.get_global()) - self.processed_data = res - - def get_image(self, config): - class_name = self.get_driver(config) - image_name = DRIVER_TO_IMAGE_NAME.get(class_name) - if image_name: - return IMAGES[image_name] - return (None, None) - - def get_custom_images_manifest(self): - template = {'apiVersion': 'core.openstack.org/v1beta1', - 'kind': 'OpenStackVersion', - 'metadata': {'name': 'openstack'}, - 'spec': { 'customContainerImages': { - 'cinderVolumeImages': self._custom_images.copy()} } } - return template - - def generate_patch(self): - res = yaml.safe_load(CINDER_TEMPLATE) - template = res['spec']['cinder']['template'] - - if self.username: - template['serviceUser'] = self.username[0] - - self.svc_cfg(template, 'global_defaults') - self.svc_cfg(template['cinderAPI'], 'api') - self.svc_cfg(template['cinderScheduler'], 'scheduler') - if self.processed_data['backup']: - self.svc_cfg(template['cinderBackup'], 'backup') - template['cinderBackup']['replicas'] = 3 - - vols = template.setdefault('cinderVolumes', {}) - # TODO: Uncomment once cinder-operator supports config for all volumes - # self.svc_cfg(vols, 'volume_global') - volumes = self.processed_data['volumes'] - - if any('RBDDriver' == self.get_driver(v[k]) - for k, v in volumes.items()): - res['spec'].update(yaml.load(EXTRAMOUNTS_CEPH, - Loader=yaml.SafeLoader)) - - for backend, config in volumes.items(): - # Names cannot use _ in the operator - manifest_backend_name = backend.replace('_', '-') - backend_data = vols[manifest_backend_name] = { - 'networkAttachments': ['storage'], - } - - # TODO:Remove once cinder-operator supports config for all volumes - config.update(self.processed_data['volume_global']) - - config.setdefault('DEFAULT', {})['enabled_backends'] = [backend] - self.svc_cfg(backend_data, 'volumes', backend) - - image = self.get_image(config[backend])[0] - if image: - self._custom_images[backend] = image - return res - - def generate_manifest(self): - # Generate Secrets - template = {'apiVersion': 'v1', - 'kind': 'Secret', - 'metadata': {'name': None}, - 'data': {}} - result = [] - for secret, files in self._secrets.items(): - new_secret = copy.deepcopy(template) - new_secret['metadata']['name'] = secret - for name, contents in files.items(): - LOG.debug('Encoding %s: %s\n', name, contents) - contents = base64.b64encode(contents.encode()).decode() - new_secret['data'][name] = contents - result.append(new_secret) - - # Generate MachineConfig - for name in self._machineconfigs: - result.append(yaml.load(MACHINECONFIGS[name], - Loader=yaml.SafeLoader)) - return result - - def write_manifest(self, output_file): - if not self.processed: - self._process() - data = self.generate_manifest() - manifest = '' - for element in data: - manifest += yaml.dump(element) - manifest += '---\n' - output_file.write(manifest) - return bool(data) - - def write_version(self, filename): - if not self._custom_images: - return False - - version = self.get_custom_images_manifest() - manifest = yaml.dump(version) - with open(filename, 'wt') as f: - f.write(manifest) - return True - - def write_patch(self, output_file): - if not self.processed: - self._process() - data = self.generate_patch() - patch = yaml.dump(data) - output_file.write(patch) - - @staticmethod - def options_to_str(options): - res = '' - for key, values in options.items(): - for value in values: - res += key + '=' + value + '\n' - return res - - def merge_remove(self, remove_config): - res = copy.deepcopy(self.remove_config) - for key, value in remove_config.items(): - if key in res: - res[key].extend(value) - else: - res[key] = value - self.remove_config = res - - def _sensitive_info(self, data): - for key in data: - if 'password' in key: - return True - return False - - def svc_cfg(self, template, section, subsection=None): - name = 'cinder-' + section - data = self.processed_data[section] - if data and subsection: - name += '-' + subsection - data = data[subsection] - if not data: - return - res = '' - secret_res = '' - for key, values in data.items(): - new_section = f'[{key}]\n' + self.options_to_str(values) - if self._sensitive_info(values): - secret_res += new_section - else: - res += new_section - - if res: - template['customServiceConfig'] = res - if secret_res: - secret_name = self.name + name - self._secrets[secret_name] = {name: secret_res} - template['customServiceConfigSecrets'] = [secret_name] - - @property - def backends(self): - if self._backends is None: - value = self.get('DEFAULT', 'enabled_backends', [''])[-1] - value = value.split(',') - self._backends = [backend for backend in value - if backend in self.config] - return self._backends - - def get_global(self): - res = {} - if not self.do_only_backends: - # Assume sections have been removed as they have been used - res = {key: self.get(key) for key in self.config} - return {'global_defaults': res} - return {'global_defaults': res} - - def get_api(self): - res = {} - if not self.do_only_backends: - # compute_api_class used by API and Volume services - for key, value in list(self.get('DEFAULT').items()): - if (key != 'compute_api_class' - and (key.startswith('api_') - or key.startswith('osapi_') - or key.endswith('_api_class'))): - res[key] = value - self.remove('DEFAULT', key) - if res: - res = {'DEFAULT': res} - return {'api': res} - - def get_scheduler(self): - res = {} - if not self.do_only_backends: - for key, value in list(self.get('DEFAULT').items()): - if key.startswith('scheduler_'): - res[key] = value - self.remove('DEFAULT', key) - if res: - res = {'DEFAULT': res} - return {'scheduler': res} - - def get_volumes(self): - backend_defaults = self.get('backend_defaults') - defaults = {} - fc_zm = {} - volumes = {} - if backend_defaults: - self.remove('backend_defaults') - defaults['backend_defaults'] = backend_defaults - - if self.get('DEFAULT', 'zoning_mode') == ['fabric']: - fc_zm['DEFAULT'] = {'zoning_mode': ['fabric']} - self.remove('DEFAULT', 'zoning_mode') - - zone_manager_cfg = self.get('fc-zone-manager') - fc_zm['fc-zone-manager'] = zone_manager_cfg - self.remove('fc-zone-manager') - - fc_sections = zone_manager_cfg['fc_fabric_names'][-1].split(',') - fc_fabric_cfg = {section: self.config[section] - for section in fc_sections - if section in self.config} - fc_zm.update(fc_fabric_cfg) - for section in fc_sections: - self.remove(section) - - volumes = {backend: {backend: self.config[backend]} - for backend in self.backends} - if fc_zm: - for backend in volumes: - if self.uses_fc(backend): - volumes[backend].update(fc_zm) - - self.remove('DEFAULT', 'enabled_backends') - if volumes: - for volume in volumes: - self.remove(volume) - return {'volume_global': defaults, - 'volumes': volumes, - 'fc_zonemgr': fc_zm} - - def get_backup(self): - leave = ('backup_use_temp_snapshot', # Used by the volume service - 'backup_use_same_host') # Used by the scheduler - res = {} - for key, value in list(self.get('DEFAULT').items()): - if key.startswith('backup_') and key not in leave: - res[key] = value - self.remove('DEFAULT', key) - if res: - res = {'DEFAULT': res} - return {'backup': res} - - -WARNING_MSG = 'ALWAYS REVIEW RESULTS, OUTPUT IS JUST A ROUGH DRAFT!!\n' - - -def arg_parser(): - parser = argparse.ArgumentParser( - description=('Cinder Configuration Migration Helper: ' - 'From Director to Operator'), - epilog=WARNING_MSG) - parser.add_argument('-b', '--only-backends', action='store_true', - help=('Only keep the volume and backup related ' - 'sections and drop everything else.')) - parser.add_argument('-c', '--config', - type=argparse.FileType('rt'), default='cinder.conf', - help=('Cinder configuration to convert (defaults to ' - 'cinder.conf)')) - parser.add_argument('-o', '--out-dir', default='.', - help=('Directory to write the resulting patch and ' - 'manifest (defaults to current directory)')) - parser.add_argument('-m', '--no-machineconfig', action='store_true', - help=('Assume OpenShift has all storage related ' - 'services or kernel modules loaded so there is ' - 'no need to generate the MachineConfig objects ' - 'in the manifest')) - parser.add_argument('-n', '--name', default='openstack', - help=('Name of the OpenStackControlPlane object ' - 'deployed in OpenShift. Defaults to openstack')) - parser.add_argument('-v', '--verbose', action='count', default=0, - help=("Increase verbose level each time it's passed, " - "-v=Info, -vv=Debug")), - args = parser.parse_args() - return args - -# TODO: Do the extra mounts for all file warnings -# TODO: Support labels for Cinder services -# TODO: Support changing IPs -# TODO: Service user: Maybe don't just remove it? For director it is fine - - -LOG_LEVELS = {0: logging.WARNING, 1: logging.INFO, 2: logging.DEBUG} - - -if __name__ == '__main__': - args = arg_parser() - LOG.basicConfig(level=LOG_LEVELS[min(args.verbose, 2)]) - transformer = CinderTransformer(args.config, args.no_machineconfig, - args.only_backends, args.name) - file_names = ['cinder.patch'] - with open(os.path.join(args.out_dir, PATCH_FILE), 'wt') as f: - transformer.write_patch(f) - with open(os.path.join(args.out_dir, PREREQ_FILE), 'wt') as f: - wrote_manifests = transformer.write_manifest(f) - if wrote_manifests: - file_names.append(PREREQ_FILE) - else: - os.remove(PREREQ_FILE) - if transformer.write_version(os.path.join(args.out_dir, VERSION_FILE)): - file_names.append(VERSION_FILE) - LOG.warning(WARNING_MSG) - print(f'Output written at {args.out_dir}: {", ".join(file_names)}') diff --git a/docs_user/modules/con_adopting-spine-leaf-networks.adoc b/docs_user/modules/con_adopting-spine-leaf-networks.adoc deleted file mode 100644 index dfbdbcfc2..000000000 --- a/docs_user/modules/con_adopting-spine-leaf-networks.adoc +++ /dev/null @@ -1,123 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="adopting-spine-leaf-networks_{context}"] - -= Configuring spine-leaf networks for the {rhos_long_noacro} deployment - -[role="_abstract"] -When you adopt a {rhos_prev_long} ({OpenStackShort}) deployment with spine-leaf networking, such as a Distributed Compute Node (DCN) architecture, adopt each L2 network segment with a separate IP subnet and create routed provider networks. - -Traffic between sites is routed at L3 through spine routers or similar network infrastructure. You must configure routing for Compute nodes at edge sites to connect with control plane services, such as RabbitMQ or the database at the central site. The cloud will not function correctly without routes configured. - -[NOTE] -==== -DHCP relay is not supported in adopted {rhos_long} environments with spine-leaf topologies. This affects bare-metal provisioning scenarios that use PXE boot. - -If you need to provision bare-metal nodes at edge sites, use Redfish virtual media or similar BMC virtual media features instead of PXE boot. -==== - -.Example routes required on DCN1 Compute nodes -[options="header"] -|=== -| Destination network | Next hop | Purpose -| 172.17.0.0/24 | 172.17.10.1 | Route to central internalapi -| 172.17.20.0/24 | 172.17.10.1 | Route to DCN2 internalapi -| 172.18.0.0/24 | 172.18.10.1 | Route to central storage -| 172.18.20.0/24 | 172.18.10.1 | Route to DCN2 storage -|=== - -You configure these routes in the `edpm_network_config_template` within the `OpenStackDataPlaneNodeSet` custom resource (CR) for each site. - -.Example network topology for a three-site DCN deployment -[options="header"] -|=== -| Network | Central site | DCN1 site | DCN2 site -| Control plane | 192.168.122.0/24 | 192.168.133.0/24 | 192.168.144.0/24 -| Internal API | 172.17.0.0/24 | 172.17.10.0/24 | 172.17.20.0/24 -| Storage | 172.18.0.0/24 | 172.18.10.0/24 | 172.18.20.0/24 -| Tenant | 172.19.0.0/24 | 172.19.10.0/24 | 172.19.20.0/24 -|=== - -When you adopt a spine-leaf deployment, you configure the `NetConfig` CR with multiple subnets for each service network. Each subnet represents a different site. - -.Example NetConfig with multiple subnets per network -[source,yaml] ----- -apiVersion: network.openstack.org/v1beta1 -kind: NetConfig -metadata: - name: netconfig -spec: - networks: - - name: ctlplane - dnsDomain: ctlplane.example.com - subnets: - - name: subnet1 # Central site - allocationRanges: - - end: 192.168.122.120 - start: 192.168.122.100 - cidr: 192.168.122.0/24 - gateway: 192.168.122.1 - - name: ctlplanedcn1 # DCN1 site - allocationRanges: - - end: 192.168.133.120 - start: 192.168.133.100 - cidr: 192.168.133.0/24 - gateway: 192.168.133.1 - - name: ctlplanedcn2 # DCN2 site - allocationRanges: - - end: 192.168.144.120 - start: 192.168.144.100 - cidr: 192.168.144.0/24 - gateway: 192.168.144.1 - - name: internalapi - dnsDomain: internalapi.example.com - subnets: - - name: subnet1 # Central site - allocationRanges: - - end: 172.17.0.250 - start: 172.17.0.100 - cidr: 172.17.0.0/24 - vlan: 20 - - name: internalapidcn1 # DCN1 site - allocationRanges: - - end: 172.17.10.250 - start: 172.17.10.100 - cidr: 172.17.10.0/24 - vlan: 30 - - name: internalapidcn2 # DCN2 site - allocationRanges: - - end: 172.17.20.250 - start: 172.17.20.100 - cidr: 172.17.20.0/24 - vlan: 40 ----- - -* Each network defines multiple subnets, one for each site. -* Each site uses unique VLAN IDs. In this example, central uses VLANs 20-23, DCN1 uses VLANs 30-33, and DCN2 uses VLANs 40-43. -* The subnet naming convention typically uses `subnet1` for the central site and site-specific names like `internalapidcn1` for edge sites. - -Because the sites are geopgraphically distributed, each site requires its own provider network (physnet). The {networking_first_ref} must be configured to recognize all physnets. - -.Example Neutron ML2 configuration for multiple physnets -[source,yaml] ----- -[ml2_type_vlan] -network_vlan_ranges = leaf0:1:1000,leaf1:1:1000,leaf2:1:1000 - -[neutron] -physnets = leaf0,leaf1,leaf2 ----- - -* `leaf0` corresponds to the central site. -* `leaf1` corresponds to the DCN1 site. -* `leaf2` corresponds to the DCN2 site. - -When you create routed provider networks in {rhos_acro}, you create network segments that map to these physnets: - -* Segment for central: `physnet=leaf0`, subnet=192.168.122.0/24 -* Segment for DCN1: `physnet=leaf1`, subnet=192.168.133.0/24 -* Segment for DCN2: `physnet=leaf2`, subnet=192.168.144.0/24 - -[role="_additional-resources"] -.Additional resources -* xref:configuring-control-plane-networking-for-spine-leaf_hsm-integration[Configuring control plane networking for spine-leaf topologies] diff --git a/docs_user/modules/con_adoption-guidelines.adoc b/docs_user/modules/con_adoption-guidelines.adoc deleted file mode 100644 index 85f45bd4c..000000000 --- a/docs_user/modules/con_adoption-guidelines.adoc +++ /dev/null @@ -1,24 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="adoption-guidelines_{context}"] - -= Guidelines for planning the adoption - -[role="_abstract"] -Adoption is similar in scope to a data center upgrade. Different firmware levels, hardware vendors, hardware profiles, networking interfaces, and storage interfaces can affect the adoption process and change behavior. - -Review the following guidelines to adequately plan for the adoption and increase the chance that you complete the adoption successfully: - -[IMPORTANT] -All commands in the adoption documentation are examples. Do not copy and paste the commands without understanding what the commands do. - -* To minimize the risk of an adoption failure, reduce the number of environmental differences between the staging environment and the production sites. -* If the staging environment is not representative of the production sites or if a staging environment is not available, you must plan to include contingency time in case the adoption fails. -* Review your custom {rhos_prev_long} ({OpenStackShort}) service configuration at every major release. -** Every major release upgrades through multiple OpenStack releases. -** Each major release might deprecate configuration options or change the format of the configuration. -* Prepare a Method of Procedure (MOP) that is specific to your environment to reduce the risk of variance or omitted steps when running the adoption process. -* You can use representative hardware in a staging environment to prepare a MOP and validate any content changes. -** Include a cross-section of firmware versions, additional interface or device hardware, and any additional software in the representative staging environment to ensure that it is broadly representative of the variety that is present in the production environments. -** Ensure that you validate any Red Hat Enterprise Linux update or upgrade in the representative staging environment. -* Use Satellite for localized and version-pinned RPM content where your data plane nodes are located. -* In the production environment, use the content that you tested in the staging environment. diff --git a/docs_user/modules/con_adoption-limitations.adoc b/docs_user/modules/con_adoption-limitations.adoc deleted file mode 100644 index c96923c8e..000000000 --- a/docs_user/modules/con_adoption-limitations.adoc +++ /dev/null @@ -1,38 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="adoption-limitations_{context}"] - -= Adoption limitations - -[role="_abstract"] -Before you proceed with the adoption, check which features are Technology Previews or unsupported. - -Technology Preview:: -+ -The following features are Technology Previews and have not been tested within the context of the {rhos_long} adoption: -+ -* {key_manager_first_ref} adoption with Proteccio hardware security module (HSM) integration -* {dns_first_ref} - -{compute_service} Technology Previews:: -+ -The following {compute_service_first_ref} features are Technology Previews: -+ -* NUMA-aware vswitches -* PCI passthrough by flavor -* SR-IOV trusted virtual functions -* vGPU -* Emulated virtual Trusted Platform Module (vTPM) -* UEFI -* AMD SEV -* Direct download from Rados Block Device (RBD) -* File-backed memory -* Defining a custom inventory of resources in a YAML file, `provider.yaml` - -Unsupported features:: -+ -The adoption process does not support the following features: -+ -* Adopting Border Gateway Protocol (BGP) environments to the {rhos_acro} data plane -* Adopting a Federal Information Processing Standards (FIPS) environment - -//* When you adopt a {OpenStackShort} {rhos_prev_ver} FIPS environment to {rhos_acro} {rhos_curr_ver}, your adopted cluster remains a FIPS cluster. There is no option to change the FIPS status during adoption. If your cluster is FIPS-enabled, you must deploy a FIPS {rhocp_long} cluster to adopt your {OpenStackShort} {rhos_prev_ver} FIPS control plane. For more information about enabling FIPS in {OpenShiftShort}, see link:{defaultOCPURL}/installing/installation-overview#installing-fips[Support for FIPS cryptography] in the {OpenShiftShort} _Installing_ guide. diff --git a/docs_user/modules/con_bare-metal-provisioning-service-configurations.adoc b/docs_user/modules/con_bare-metal-provisioning-service-configurations.adoc deleted file mode 100644 index da5c228ee..000000000 --- a/docs_user/modules/con_bare-metal-provisioning-service-configurations.adoc +++ /dev/null @@ -1,44 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="con_bare-metal-provisioning-service-configurations_{context}"] - -= {bare_metal} configurations - -[role="_abstract"] -You configure the {bare_metal_first_ref} by using configuration snippets. - -Some {bare_metal} configuration is overridden in {OpenStackPreviousInstaller}, for example, PXE Loader file names are often overridden at intermediate layers. You must pay attention to the settings you apply in your {rhos_long} deployment. The `ironic-operator` applies a reasonable working default configuration, but if you override them with your prior configuration, your experience might not be ideal or your new {bare_metal} fails to operate. Similarly, additional configuration might be necessary, for example, if you enable and use additional hardware types in your `ironic.conf` file. - -The model of reasonable defaults includes commonly used hardware-types and driver interfaces. For example, the `redfish-virtual-media` boot interface and the `ramdisk` deploy interface are enabled by default. If you add new bare metal nodes after the adoption is complete, the driver interface selection occurs based on the order of precedence in the configuration if you do not explicitly set it on the node creation request or as an established default in the `ironic.conf` file. - -Some configuration parameters do not need to be set on an individual node level, for example, network UUID values, or they are centrally configured in the `ironic.conf` file, as the setting controls security behavior. - -It is critical that you maintain the following parameters that you configured and formatted as `[section]` and parameter name from the prior deployment to the new deployment. These parameters that govern the underlying behavior and values in the previous configuration would have used specific values if set. - -* [neutron]cleaning_network -* [neutron]provisioning_network -* [neutron]rescuing_network -* [neutron]inspection_network -* [conductor]automated_clean -* [deploy]erase_devices_priority -* [deploy]erase_devices_metadata_priority -* [conductor]force_power_state_during_sync - -You can set the following parameters individually on a node. However, you might choose to use embedded configuration options to avoid the need to set the parameters individually when creating or managing bare metal nodes. Check your prior `ironic.conf` file for these parameters, and if set, apply a specific override configuration. - -* [conductor]bootloader -* [conductor]rescue_ramdisk -* [conductor]rescue_kernel -* [conductor]deploy_kernel -* [conductor]deploy_ramdisk - -The instances of `kernel_append_params`, formerly `pxe_append_params` in the `[pxe]` and `[redfish]` configuration sections, are used to apply boot time options like "console" for the deployment ramdisk and as such often must be changed. - -// TODO: -// Conductor Groups?! - -[WARNING] -You cannot migrate hardware types that are set with the `ironic.conf` file `enabled_hardware_types` parameter, and hardware type driver interfaces starting with `staging-` into the adopted configuration. - -[role="_additional-resources"] -.Additional resources -* link:{customizing-rhoso}/index[{customizing-rhoso-t}] diff --git a/docs_user/modules/con_block-storage-service-config-generation-helper-tool.adoc b/docs_user/modules/con_block-storage-service-config-generation-helper-tool.adoc deleted file mode 100644 index 4e585a17e..000000000 --- a/docs_user/modules/con_block-storage-service-config-generation-helper-tool.adoc +++ /dev/null @@ -1,103 +0,0 @@ -:_mod-docs-content-type: REFERENCE -[id="block-storage-configuration-generation-helper-tool_{context}"] - -= About the {block_storage} configuration generation helper tool - -[role="_abstract"] -Creating the right {block_storage_first_ref} configuration files to deploy by using Operators can -sometimes be complex. There is a helper tool that can create a draft of the files from a `cinder.conf` file. - -This tool is not meant to be an automation tool. You can use the tool to get a general understanding of how to create the configuration files, or to point out some potential pitfalls and reminders. - -[IMPORTANT] -The tool requires the `PyYAML` Python package to be installed (`pip -install PyYAML`). - -This link:helpers/cinder-cfg.py[cinder-cfg.py script] defaults to reading the -`cinder.conf` file from the current directory (unless `--config` option is used) -and outputs files to the current directory (unless `--out-dir` option is used). - -In the output directory, you always get a `cinder.patch` file with the Cinder- -specific configuration patch to apply to the `OpenStackControlPlane` custom resource, but you might also get an additional file called `cinder-prereq.yaml` with some -`Secrets` and `MachineConfigs`, and an `openstackversion.yaml` file with the -`OpenStackVersion` sample. - -Example of an invocation setting input and output explicitly to the defaults for -a Ceph backend: - ----- -$ python cinder-cfg.py --config cinder.conf --out-dir ./ -WARNING:root:The {block_storage} is configured to use ['/etc/cinder/policy.yaml'] as policy file, please ensure this file is available for the control plane {block_storage} services using "extraMounts" or remove the option. - -WARNING:root:Deployment uses Ceph, so make sure the Ceph credentials and configuration are present in OpenShift as a secret and then use the extra volumes to make them available in all the services that would need them. - -WARNING:root:You were using user ['nova'] to talk to Nova, but in podified using the service keystone username is preferred in this case ['cinder']. Dropping that configuration. - -WARNING:root:ALWAYS REVIEW RESULTS, OUTPUT IS JUST A ROUGH DRAFT!! - -Output written at ./: cinder.patch ----- - -The script outputs some warnings to let you know that you might need to do some things -manually, such as add the custom policy or provide the Ceph configuration files, and -also let you know that the service_user was removed. - -A different example when using multiple backends, one of them being a 3PAR FC -could be: - ----- -$ python cinder-cfg.py --config cinder.conf --out-dir ./ -WARNING:root:The {block_storage} is configured to use ['/etc/cinder/policy.yaml'] as policy file, please ensure this file is available for the control plane Block Storage services using "extraMounts" or remove the option. - -ERROR:root:Backend hpe_fc requires a vendor container image, but there is no certified image available yet. Patch will use the last known image for reference, but IT WILL NOT WORK - -WARNING:root:Deployment uses Ceph, so make sure the Ceph credentials and configuration are present in OpenShift as a secret and then use the extra volumes to make them available in all the services that would need them. - -WARNING:root:You were using user ['nova'] to talk to Nova, but in podified using the service keystone username is preferred, in this case ['cinder']. Dropping that configuration. - -WARNING:root:Configuration is using FC, please ensure all your OpenShift nodes have HBAs or use labels to ensure that Volume and Backup services are scheduled on nodes with HBAs. - -WARNING:root:ALWAYS REVIEW RESULTS, OUTPUT IS JUST A ROUGH DRAFT!! - -Output written at ./: cinder.patch, cinder-prereq.yaml ----- - -In this case there are additional messages. The following list provides an explanation of each one: - -* There is one message mentioning how this backend driver needs external vendor -dependencies so the standard container image will not work. Unfortunately this -image is still not available, so an older image is used in the output patch file -for reference. You can then replace this image with one that you build or -with a Red Hat official image once the image is available. In this case you can -see in your `cinder.patch` file that has an `OpenStackVersion` object: -+ -[source,yaml] ----- -apiVersion: core.openstack.org/v1beta1 -kind: OpenStackVersion -metadata: - name: openstack -spec: - customContainerImages: - cinderVolumeImages: - hpe-fc: - containerImage: registry.connect.redhat.com/hpe3parcinder/openstack-cinder-volume-hpe3parcinder17-0 ----- -+ -The name of the `OpenStackVersion` must match the name of your `OpenStackControlPlane`, so in your case it may be other than `openstack`. - -* The FC message reminds you that this transport protocol requires specific HBA -cards to be present on the nodes where Block Storage services are running. -* In this case it has created the `cinder-prereq.yaml` file and within the file -there is one `MachineConfig` and one `Secret`. The `MachineConfig` is called `99-master-cinder-enable-multipathd` and like the name suggests enables multipathing on all the OCP worker nodes. The `Secret` is -called `openstackcinder-volumes-hpe_fc` and contains the 3PAR backend -configuration because it has sensitive information (credentials). The -`cinder.patch` file uses the following configuration: -+ -[source,yaml] ----- - cinderVolumes: - hpe-fc: - customServiceConfigSecrets: - - openstackcinder-volumes-hpe_fc ----- diff --git a/docs_user/modules/con_block-storage-service-limitations.adoc b/docs_user/modules/con_block-storage-service-limitations.adoc deleted file mode 100644 index a448549fc..000000000 --- a/docs_user/modules/con_block-storage-service-limitations.adoc +++ /dev/null @@ -1,11 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="block-storage-limitations_{context}"] - -= Limitations for adopting the {block_storage} - -[role="_abstract"] -Before you begin the {block_storage_first_ref} adoption, review the following limitations: - -* There is no global `nodeSelector` option for all {block_storage} volumes. You must specify the `nodeSelector` for each back end. -* There are no global `customServiceConfig` or `customServiceConfigSecrets` options for all {block_storage} volumes. You must specify these options for each back end. -* Support for {block_storage} back ends that require kernel modules that are not included in Red Hat Enterprise Linux is not tested in {rhos_long}. diff --git a/docs_user/modules/con_changes-to-cephFS-via-NFS.adoc b/docs_user/modules/con_changes-to-cephFS-via-NFS.adoc deleted file mode 100644 index bafd8b2c0..000000000 --- a/docs_user/modules/con_changes-to-cephFS-via-NFS.adoc +++ /dev/null @@ -1,28 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="changes-to-cephFS-through-NFS_{context}"] - -= Changes to CephFS through NFS - -[role="_abstract"] -Before you begin the adoption, review the following information to understand the changes to CephFS through NFS between {rhos_prev_long} ({OpenStackShort}) {rhos_prev_ver} and {rhos_long} {rhos_curr_ver}: - -* If the {OpenStackShort} {rhos_prev_ver} deployment uses CephFS through NFS as a back end for {rhos_component_storage_file_first_ref}, you cannot directly import the `ceph-nfs` service on the {OpenStackShort} Controller nodes into {rhos_acro} {rhos_curr_ver}. In {rhos_acro} {rhos_curr_ver}, the {rhos_component_storage_file} only supports using a clustered NFS service that is directly managed on the {Ceph} cluster. Adoption with the `ceph-nfs` service involves a data path disruption to existing NFS clients. - -* On {OpenStackShort} {rhos_prev_ver}, Pacemaker manages the high availability of the `ceph-nfs` service. This service is assigned a Virtual IP (VIP) address that is also managed by Pacemaker. The VIP is typically created on an isolated `StorageNFS` network. The Controller nodes have ordering and collocation constraints established between this VIP, `ceph-nfs`, and the {rhos_component_storage_file_first_ref} share manager service. Prior to adopting {rhos_component_storage_file}, you must adjust the Pacemaker ordering and collocation constraints to separate the share manager service. This establishes `ceph-nfs` with its VIP as an isolated, standalone NFS service that you can decommission after completing the {rhos_acro} adoption. - -* In {Ceph} {CephVernum}, a native clustered Ceph NFS service has to be deployed on the {Ceph} cluster by using the Ceph Orchestrator prior to adopting the {rhos_component_storage_file}. This NFS service eventually replaces the standalone NFS service from {OpenStackShort} {rhos_prev_ver} in your deployment. When the {rhos_component_storage_file} is adopted into the {rhos_acro} {rhos_curr_ver} environment, it establishes all the existing exports and client restrictions on the new clustered Ceph NFS service. Clients can continue to read and write data on existing NFS shares, and are not affected until the old standalone NFS service is decommissioned. After the service is decommissioned, you can re-mount the same share from the new clustered Ceph NFS service during a scheduled downtime. - -* To ensure that NFS users are not required to make any networking changes to their existing workloads, assign an IP address from the same isolated `StorageNFS` network to the clustered Ceph NFS service. NFS users only need to discover and re-mount their shares by using new export paths. When the adoption is complete, {rhos_acro} users can query the {rhos_component_storage_file} API to list the export locations on existing shares to identify the preferred paths to mount these shares. These preferred paths correspond to the new clustered Ceph NFS service in contrast to other non-preferred export paths that continue to be displayed until the old isolated, standalone NFS service is decommissioned. - -* When you migrate your workloads from the old NFS service, you must ensure that exports are not consumed from both the old NFS service and the new clustered Ceph NFS service at the same time. This simultaneous access to both services is considered dangerous and bypasses the protections for concurrent access that is ensured by the NFS protocol. When you migrate the workloads to use exports from the new NFS service, you must ensure that you migrate the use of each export entirely so that no part of the workload stays connected to the old NFS service. - -* You can no longer control the old Pacemaker-managed `ceph-nfs` service through the {rhos_prev_long} {OpenStackPreviousInstaller} after the control plane adoption is complete. This means that there is no support for updating the NFS Ganesha software, or changing any configuration. While data is protected from server crashes or restarts, high availability and data recovery is still limited, and these maintenance issues are no longer visible to {rhos_component_storage_file}. - -* Cloud administrators must ensure a reasonably short window to switch over all end-user workloads to the new NFS service. - -* While the old `ceph-nfs` service only supported NFS version 4.1 and later, the new clustered NFS service supports NFS protocols 3 and 4.1 and later. Mixing protocol versions with an export results in unintended consequences. You should mount a given share across all clients by using a consistent NFS protocol version. - - -[role="_additional-resources"] -.Additional resources -* xref:creating-a-ceph-nfs-cluster_ceph-prerequisites[Creating an NFS Ganesha cluster] diff --git a/docs_user/modules/con_completing-prerequisites-for-migrating-ceph-rbd.adoc b/docs_user/modules/con_completing-prerequisites-for-migrating-ceph-rbd.adoc deleted file mode 100644 index 3939b735b..000000000 --- a/docs_user/modules/con_completing-prerequisites-for-migrating-ceph-rbd.adoc +++ /dev/null @@ -1,65 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="completing-prerequisites-for-rbd-migration_{context}"] - -= Completing prerequisites for a {Ceph} RBD migration - -[role="_abstract"] -Complete the following prerequisites before you begin the {Ceph} Rados Block Device (RBD) migration. - -* The target CephStorage or ComputeHCI nodes are configured to have both `storage` and `storage_mgmt` networks. This ensures that you can use both {Ceph} public and cluster networks from the same node. From {rhos_prev_long} {rhos_prev_ver} and later you do not have to run a stack update. -* NFS Ganesha is migrated from a {OpenStackPreviousInstaller} deployment to `cephadm`. For more information, see "Creating an NFS Ganesha cluster". -* Ceph Metadata Server, monitoring stack, Ceph Object Gateway, and any other daemon that is deployed on Controller nodes. -ifeval::["{build}" != "upstream"] -* The daemons distribution follows the cardinality constraints that are -described in "Red Hat Ceph -Storage: Supported configurations". -endif::[] -* The {Ceph} cluster is healthy, and the `ceph -s` command returns `HEALTH_OK`. -* Run `os-net-config` on the bare metal node and configure additional networks: -.. If target nodes are `CephStorage`, ensure that the network is defined in the -bare metal file for the `CephStorage` nodes, for example, `/home/stack/composable_roles/network/baremetal_deployment.yaml`: -+ -[source,yaml] ----- -- name: CephStorage -count: 2 -instances: -- hostname: oc0-ceph-0 -name: oc0-ceph-0 -- hostname: oc0-ceph-1 -name: oc0-ceph-1 -defaults: -networks: -- network: ctlplane -vif: true -- network: storage_cloud_0 -subnet: storage_cloud_0_subnet -- network: storage_mgmt_cloud_0 -subnet: storage_mgmt_cloud_0_subnet -network_config: -template: templates/single_nic_vlans/single_nic_vlans_storage.j2 ----- -.. Add the missing network: -+ ----- -$ openstack overcloud node provision \ --o overcloud-baremetal-deployed-0.yaml --stack overcloud-0 \ -/--network-config -y --concurrency 2 /home/stack/metalsmith-0.yaml ----- - .. Verify that the storage network is configured on the target nodes: -+ ----- -(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.24.14 ip -o -4 a -1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever -5: br-storage inet 192.168.24.14/24 brd 192.168.24.255 scope global br-storage\ valid_lft forever preferred_lft forever -6: vlan1 inet 192.168.24.14/24 brd 192.168.24.255 scope global vlan1\ valid_lft forever preferred_lft forever -7: vlan11 inet 172.16.11.172/24 brd 172.16.11.255 scope global vlan11\ valid_lft forever preferred_lft forever -8: vlan12 inet 172.16.12.46/24 brd 172.16.12.255 scope global vlan12\ valid_lft forever preferred_lft forever ----- - -[role="_additional-resources"] -.Additional resources -ifeval::["{build}" != "upstream"] -* link:https://access.redhat.com/articles/1548993[Red Hat Ceph Storage: Supported configurations] -endif::[] -* xref:creating-a-ceph-nfs-cluster_ceph-prerequisites[Creating an NFS Ganesha cluster] diff --git a/docs_user/modules/con_dcn-adoption-overview.adoc b/docs_user/modules/con_dcn-adoption-overview.adoc deleted file mode 100644 index a7c02434c..000000000 --- a/docs_user/modules/con_dcn-adoption-overview.adoc +++ /dev/null @@ -1,75 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="dcn-adoption-overview_{context}"] - -= Overview of Distributed Compute Node adoption - -[role="_abstract"] -The process to adopt Distributed Compute Node (DCN) deployment from {rhos_prev_long} ({OpenStackShort}) to {rhos_long} requires additional adoption tasks: - -* You must map a multi-stack deployment to multiple node sets. -* You must map additional networking configurations. - -Multi-stack to multi-node set mapping:: In {OpenStackPreviousInstaller} deployments, DCN environments use multiple Heat stacks: -+ -** The Central stack is templating for Controllers and central Compute nodes. -** An edge stack is templating for Edge Compute nodes in a stack. There is one stack per DCN site. -+ -When you perform an adoption, map {OpenStackPreviousInstaller} stacks to `OpenStackDataPlaneNodeSet` custom resources (CRs): -+ -.Mapping {OpenStackPreviousInstaller} stacks to {rhos_acro} nodesets -[options="header"] -|=== -| {OpenStackPreviousInstaller} stack | {rhos_acro} nodeset | Availability zone -| Central stack (Compute role) | `openstack-edpm` or `openstack-cell1` | az-central -| DCN1 stack (ComputeDcn1 role) | `openstack-edpm-dcn1` or `openstack-cell1-dcn1` | az-dcn1 -| DCN2 stack (ComputeDcn2 role) | `openstack-edpm-dcn2` or `openstack-cell1-dcn2` | az-dcn2 -|=== -+ -[NOTE] -==== -Keep all node sets in the same Nova cell to maintain unified scheduling through a shared cell. The default cell is `cell1`. -==== - -Key differences from standard adoption:: The following table summarizes the differences between standard adoption and DCN adoption: -+ -.Comparison of standard and DCN adoption -[options="header"] -|=== -| Aspect | Standard adoption | DCN adoption -| Director stacks | Single stack | Multiple stacks (central + edge sites) -| Network topology | Flat L2 networks | Routed L3 networks with multiple subnets -| Data plane node sets | Single node set | Multiple node sets (one per site minimum) -| Network routes | Usually not required | Required for inter-site connectivity -| Physnets | Single physnet (e.g., `datacentre`) | Multiple physnets (e.g., `leaf0`, `leaf1`, `leaf2`) -| Availability zones | Often single AZ | Multiple AZs (one per site) -| OVN bridge mappings | Single mapping | Site-specific mappings -| Provider networks | Single segment | Multi-segment routed provider networks -|=== - -Requirements for DCN adoption:: Before adopting a DCN deployment, ensure you have: -+ -** Network topology information for all sites (IP ranges, VLANs, gateways) -** Inter-site routing configuration (routes between site subnets) -** Mapping of {OpenStackPreviousInstaller} roles to availability zones -** OVN bridge mapping configuration for each site - -[IMPORTANT] -==== -The adoption of the control plane must complete before adopting any data plane nodes. However, once the control plane is adopted, the edge site data plane adoptions can proceed in parallel with the central site data plane adoption. -==== - -DCN Adoption workflow overview:: The adoption of a Distributed Compute Node (DCN) deployment from {rhos_prev_long} ({OpenStackShort}) to {rhos_long} -+ -. **Control plane adoption**: Adopt all control plane services from the central {OpenStackPreviousInstaller} stack to the {rhos_acro} control plane. This is identical to standard adoption. -. **Network configuration**: Configure multi-subnet `NetConfig` and `NetworkAttachmentDefinition` CRs to support all site networks. -. **Data plane node set creation**: Create separate `OpenStackDataPlaneNodeSet` CRs for each site, each with site-specific network configurations: -+ -** Network subnet references -** OVN bridge mappings (physnets) -** Inter-site routing configuration -. **Data plane deployment**: Deploy all node sets. The edge site node sets can be deployed in parallel after the central site control plane is adopted. - - -[role="_additional-resources"] -.Additional resources -* xref:adopting-spine-leaf-networks_configuring-network[Configuring spine-leaf networks for the {rhos_long_noacro} deployment] diff --git a/docs_user/modules/con_fips-support.adoc b/docs_user/modules/con_fips-support.adoc deleted file mode 100644 index 831d2573c..000000000 --- a/docs_user/modules/con_fips-support.adoc +++ /dev/null @@ -1,15 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="fips-support_{context}"] - -= FIPS support - -[role="_abstract"] -If you are adopting a {rhos_prev_long} ({OpenStackShort}) {rhos_prev_ver} FIPS environment to {rhos_long} {rhos_curr_ver}, your adopted cluster remains a FIPS cluster. There is no option to change FIPS status during adoption. - -There is a major difference with how FIPS was configured in {OpenStackPreviousInstaller} and how it is enabled and enforced in operator deployments. In {OpenStackPreviousInstaller}, FIPS is enabled as part of its configuration, whereas in operator deployments, there is no specific FIPS configuration. - -If your cluster is FIPS enabled, you must deploy a FIPS {rhocp_long} cluster to adopt your {OpenStackShort} {rhos_prev_ver} FIPS control plane. - -[role="_additional-resources"] -.Additional resources -* link:https://docs.openshift.com/container-platform/latest/installing/installing-fips.html[Support for FIPS cryptography] diff --git a/docs_user/modules/con_identity-service-authentication.adoc b/docs_user/modules/con_identity-service-authentication.adoc deleted file mode 100644 index e18990e89..000000000 --- a/docs_user/modules/con_identity-service-authentication.adoc +++ /dev/null @@ -1,20 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="identity-service-authentication_{context}"] - -= {identity_service} authentication - -[role="_abstract"] -If you have custom policies enabled, complete the following steps for adoption: - -. Remove custom policies. -. Run the adoption. -. Re-add custom policies by using the new SRBAC syntax. - -[IMPORTANT] -Red Hat does not support customized roles or policies. Syntax errors or misapplied authorization can negatively impact security or usability. If you need customized roles or policies in your production environment, contact Red Hat support for a support exception before you begin the adoption. - -After you adopt a {OpenStackPreviousInstaller}-based OpenStack deployment to a {rhos_long_noacro} deployment, the {identity_service} performs user authentication and authorization by using Secure RBAC (SRBAC). If SRBAC is already enabled, then there is no change to how you perform operations. If SRBAC is disabled, then adopting a {OpenStackPreviousInstaller}-based OpenStack deployment might change how you perform operations due to changes in API access policies. - -[role="_additional-resources"] -.Additional resources -* link:{defaultURL}/performing_security_operations/assembly_srbac-in-rhoso_performing-security-services#assembly_srbac-in-rhoso_performing-security-services[Secure role based access control in Red Hat OpenStack Services on OpenShift] diff --git a/docs_user/modules/con_key-manager-service-hsm-adoption-approaches.adoc b/docs_user/modules/con_key-manager-service-hsm-adoption-approaches.adoc deleted file mode 100644 index 2434bb772..000000000 --- a/docs_user/modules/con_key-manager-service-hsm-adoption-approaches.adoc +++ /dev/null @@ -1,65 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="key-manager-service-hsm-adoption-approaches_{context}"] - -= {key_manager} HSM adoption approaches - -[role="_abstract"] -The {key_manager_first_ref} adoption approach depends on your source {OpenStackPreviousInstaller} environment configuration. - -* Use the standard adoption approach if your environment includes only the `simple_crypto` plugin for secret storage and has no HSM integration. -* Use the HSM-enabled adoption approach if your source environment has HSM integration that uses Public Key Cryptography Standard (PKCS) #11, Key Management Interoperability Protocol (KMIP), or other HSM back ends alongside `simple_crypto`. - -Standard adoption approach:: -* Uses the existing {key_manager} adoption procedure -* Migrates a simple crypto back-end configuration -* Provides a single-step adoption process -* Is suitable for development, testing, and standard production environments - -HSM-enabled adoption approach:: -* Patches the `OpenStackControlPlane` custom resource with HSM-enabled configuration -* Creates required Kubernetes secrets (`hsm-login` and `proteccio-data`) for HSM credentials and certificates -* Preserves HSM metadata during database migration -* Supports both simple crypto and HSM back ends in the target environment -* Requires custom container images with HSM client libraries that are built by using the `rhoso_proteccio_hsm` Ansible role -* Requires HSM client certificates and configuration files -* Requires proper HSM partition and key configuration that matches your source environment -* The HSM-enabled adoption approach currently supports: -** Proteccio (Eviden Trustway): Fully supported with PKCS#11 integration -** Luna (Thales): PKCS#11 support available -** nCipher (Entrust): PKCS#11 support available - -[IMPORTANT] -==== -HSM adoption requires additional configuration steps, including: - -* Custom Barbican container images with HSM client libraries that are built using the `rhoso_proteccio_hsm` Ansible role -* HSM client certificates and configuration files that are accessible from the host where you run the adoption commands -* Proper HSM partition and key configuration that matches your source environment - -These approaches are mutually exclusive. Choose an approach based on your source environment configuration. -==== - -[options="header"] -|=== -| Source environment characteristic | Approach | Rationale - -| Only `simple_crypto` back-end configured -| Standard adoption -| No HSM complexity needed - -| HSM integration present (PKCS#11, KMIP, and so on) -| HSM-enabled adoption -| Preserves HSM functionality and secrets - -| Development or testing environment -| Standard adoption -| Simpler setup and maintenance - -| Production with compliance requirements -| HSM-enabled adoption -| Maintains security compliance - -| Unknown back-end configuration -| Check source environment first -| Determine appropriate approach -|=== diff --git a/docs_user/modules/con_key-manager-service-support-for-crypto-plugins.adoc b/docs_user/modules/con_key-manager-service-support-for-crypto-plugins.adoc deleted file mode 100644 index f96b531fd..000000000 --- a/docs_user/modules/con_key-manager-service-support-for-crypto-plugins.adoc +++ /dev/null @@ -1,24 +0,0 @@ -:_mod-docs-content-type: REFERENCE -[id="key-manager-service-support-for-crypto-plug-ins_{context}"] - -= Key Manager service support for crypto plug-ins - -[role="_abstract"] -The {key_manager_first_ref} supports multiple crypto plug-ins for different security requirements and deployment scenarios. - -The following crypto plug-ins are supported in {rhos_long}: - -* Simple Crypto Plug-in: Software-based cryptographic back end suitable for development and testing environments -* Public Key Cryptography Standard (PKCS) #11 Plug-in: Hardware security module (HSM) integration for production environments that requires enhanced security - -//*TODO: Talk about Ceph Storage and Swift Storage nodes, HCI deployments, -//etc.* - -The {key_manager} supports HSM integration through the PKCS#11 plugin. This enables: - -* Enhanced security for secret storage and retrieval -* Hardware-based key management -* Compliance with security requirements for production environments -* Preservation of existing HSM-protected secrets during adoption - -For environments that require HSM integration during adoption, see xref:adopting-the-key-manager-service-with-proteccio-hsm_hsm-integration[Adopting the {key_manager} with Proteccio HSM integration]. diff --git a/docs_user/modules/con_known-issues-adoption.adoc b/docs_user/modules/con_known-issues-adoption.adoc deleted file mode 100644 index 3ca5c401c..000000000 --- a/docs_user/modules/con_known-issues-adoption.adoc +++ /dev/null @@ -1,7 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="known-issues-adoption_{context}"] - -= Known issues - -[role="_abstract"] -Review the following known issues that might affect a successful adoption: diff --git a/docs_user/modules/con_node-roles.adoc b/docs_user/modules/con_node-roles.adoc deleted file mode 100644 index 0410afb46..000000000 --- a/docs_user/modules/con_node-roles.adoc +++ /dev/null @@ -1,59 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="about-node-roles_{context}"] - -= About node roles - -[role="_abstract"] -In {OpenStackPreviousInstaller} deployments you had 5 different standard roles -for the nodes: `Controller`, `Compute`, `Networker`, `Ceph Storage`, `Swift -Storage`, but in the control plane you make a distinction based on where things -are running, in {OpenShift} ({OpenShiftShort}) or external to it. - -When adopting a {OpenStackPreviousInstaller} {rhos_prev_long} ({OpenStackShort}) your `Compute` nodes will directly become -external nodes, so there should not be much additional planning needed there. -Your `Networker` nodes will also become external nodes. -In most cases your `Controller` nodes would also become external nodes to avoid dataplane outage during adoption. This is because when there are no -dedicated `Networker` nodes in {OpenStackPreviousInstaller}, `Controller` nodes act as OVN gateway chassis i.e external SNAT and Centralized -Floating IP(if DVR disabled) traffic goes through these nodes and removing these nodes during adoption will lead to some outage and this -should be avoided. Such disruption should be planned post adoption. - -In many deployments being adopted the `Controller` nodes will require some -thought because you have many {OpenShiftShort} nodes where the Controller services -could run, and you have to decide which ones you want to use, how you are going to use them, and make sure those nodes are ready to run the services. - -In most deployments running {OpenStackShort} services on `master` nodes can have a -seriously adverse impact on the {OpenShiftShort} cluster, so it is recommended that you place {OpenStackShort} services on non `master` nodes. - -By default {OpenStackShort} Operators deploy {OpenStackShort} services on any worker node, but -that is not necessarily what's best for all deployments, and there may be even -services that won't even work deployed like that. - -When planing a deployment it's good to remember that not all the services on an -{OpenStackShort} deployments are the same as they have very different requirements. - -Looking at the Block Storage service (cinder) component you can clearly see different requirements for -its services: the cinder-scheduler is a very light service with low -memory, disk, network, and CPU usage; cinder-api service has a higher network -usage due to resource listing requests; the cinder-volume service will have a -high disk and network usage since many of its operations are in the data path -(offline volume migration, create volume from image, etc.), and then you have -the cinder-backup service which has high memory, network, and CPU (to compress -data) requirements. - -The {image_service_first_ref} and {object_storage_first_ref} components are in the data path, as well as RabbitMQ and Galera services. - -Given these requirements it may be preferable not to let these services wander -all over your {OpenShiftShort} worker nodes with the possibility of impacting other -workloads, or maybe you don't mind the light services wandering around but you -want to pin down the heavy ones to a set of infrastructure nodes. - -There are also hardware restrictions to take into consideration, because if you -are using a Fibre Channel (FC) Block Storage service backend you need the cinder-volume, -cinder-backup, and maybe even the {image_service_first_ref} (if it's using the Block Storage service as a backend) -services to run on a {OpenShiftShort} host that has an HBA. - -The {OpenStackShort} Operators allow a great deal of flexibility on where to run the -{OpenStackShort} services, as you can use node labels to define which {OpenShiftShort} nodes -are eligible to run the different {OpenStackShort} services. Refer to the xref:about-node-selector_{context}[About node -selector] to learn more about using labels to define -placement of the {OpenStackShort} services. diff --git a/docs_user/modules/con_preparing-the-shared-file-systems-service-configuration.adoc b/docs_user/modules/con_preparing-the-shared-file-systems-service-configuration.adoc deleted file mode 100644 index 474a29d13..000000000 --- a/docs_user/modules/con_preparing-the-shared-file-systems-service-configuration.adoc +++ /dev/null @@ -1,175 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="preparing-the-shared-file-systems-service-configuration_{context}"] - -= Guidelines for preparing the {rhos_component_storage_file} configuration - -[role="_abstract"] -Copy the {rhos_component_storage_file_first_ref} configuration from {rhos_prev_long} {rhos_prev_ver}, and review it to ensure that you copy the correct configuration for {rhos_long} {rhos_curr_ver}. - -Review the following guidelines for preparing your {rhos_component_storage_file} configuration file for adoption: - -* The {rhos_component_storage_file} operator sets up the following configurations and can be ignored: -** Database-related configuration (`[database]`) -** Service authentication (`auth_strategy`, `[keystone_authtoken]`) -** Message bus configuration (`transport_url`, `control_exchange`) -** The default paste config (`api_paste_config`) -** Inter-service communication configuration (`[neutron]`, `[nova]`, `[cinder]`, `[glance]` `[oslo_messaging_*]`) -* Ignore the `osapi_share_listen` configuration. In {rhos_long} {rhos_curr_ver}, you rely on {rhocp_long} routes and ingress. -* Check for policy overrides. In {rhos_acro} {rhos_curr_ver}, the {rhos_component_storage_file} ships with a secure default Role-based access control (RBAC), and overrides might not be necessary. -ifeval::["{build}" != "downstream"] -Review RBAC defaults by using the Oslo policy generator tool. -endif::[] -* If a custom policy is necessary, you must provide it as a `ConfigMap`. The following example spec illustrates how you can set up a `ConfigMap` called `manila-policy` with the contents of a file called `policy.yaml`: -+ -[source,yaml] ----- - spec: - manila: - enabled: true - template: - manilaAPI: - customServiceConfig: | - [oslo_policy] - policy_file=/etc/manila/policy.yaml - extraMounts: - - extraVol: - - extraVolType: Undefined - mounts: - - mountPath: /etc/manila/ - name: policy - readOnly: true - propagation: - - ManilaAPI - volumes: - - name: policy - projected: - sources: - - configMap: - name: manila-policy - items: - - key: policy - path: policy.yaml ----- - -* The value of the `host` option under the `[DEFAULT]` section must be `hostgroup`. -* To run the {rhos_component_storage_file} API service, you must add the `enabled_share_protocols` option to the `customServiceConfig` section in `manila: template: manilaAPI`. -* If you have scheduler overrides, add them to the `customServiceConfig` -section in `manila: template: manilaScheduler`. -* If you have multiple storage back-end drivers configured with {OpenStackShort} {rhos_prev_ver}, you need to split them up when deploying {rhos_acro} {rhos_curr_ver}. Each storage back-end driver needs to use its own instance of the `manila-share` service. -* If a storage back-end driver needs a custom container image, find it in the -Red Hat Ecosystem Catalog, and create or modify an `OpenStackVersion` custom resource (CR) to specify the custom image using the same `custom name`. -+ -The following example shows a manila spec from the `OpenStackControlPlane` CR that includes multiple storage back-end drivers, where only one is using a custom container image: -+ -[source,yaml] ----- - spec: - manila: - enabled: true - template: - manilaAPI: - customServiceConfig: | - [DEFAULT] - enabled_share_protocols = nfs - replicas: 3 - manilaScheduler: - replicas: 3 - manilaShares: - netapp: - customServiceConfig: | - [DEFAULT] - debug = true - enabled_share_backends = netapp - host = hostgroup - [netapp] - driver_handles_share_servers = False - share_backend_name = netapp - share_driver = manila.share.drivers.netapp.common.NetAppDriver - netapp_storage_family = ontap_cluster - netapp_transport_type = http - replicas: 1 - pure: - customServiceConfig: | - [DEFAULT] - debug = true - enabled_share_backends=pure-1 - host = hostgroup - [pure-1] - driver_handles_share_servers = False - share_backend_name = pure-1 - share_driver = manila.share.drivers.purestorage.flashblade.FlashBladeShareDriver - flashblade_mgmt_vip = 203.0.113.15 - flashblade_data_vip = 203.0.10.14 - replicas: 1 ----- -+ -The following example shows the `OpenStackVersion` CR that defines the custom container image: -+ -[source,yaml] ----- -apiVersion: core.openstack.org/v1beta1 -kind: OpenStackVersion -metadata: - name: openstack -spec: - customContainerImages: - cinderVolumeImages: - pure: registry.connect.redhat.com/purestorage/openstack-manila-share-pure-rhosp-18-0 ----- -+ -The name of the `OpenStackVersion` CR must match the name of your `OpenStackControlPlane` CR. -* If you are providing sensitive information, such as passwords, hostnames, and usernames, use {OpenShiftShort} secrets, and the `customServiceConfigSecrets` key. You can use `customConfigSecrets` in any service. If you use third party storage that requires credentials, create a secret that is referenced in the manila CR/patch file by using the `customServiceConfigSecrets` key. For example: - -. Create a file that includes the secrets, for example, `netapp_secrets.conf`: -+ ----- -$ cat << __EOF__ > ~/netapp_secrets.conf - -[netapp] -netapp_server_hostname = 203.0.113.10 -netapp_login = fancy_netapp_user -netapp_password = secret_netapp_password -netapp_vserver = mydatavserver -__EOF__ ----- -+ ----- -$ oc create secret generic osp-secret-manila-netapp --from-file=~/ ----- -+ -** Replace `` with the name of the file that includes your secrets, for example, `netapp_secrets.conf`. - -. Add the secret to any {rhos_component_storage_file} file in the `customServiceConfigSecrets` section. The following example adds the `osp-secret-manila-netapp` secret to the `manilaShares` service: -+ -[source,yaml] ----- - spec: - manila: - enabled: true - template: - < . . . > - manilaShares: - netapp: - customServiceConfig: | - [DEFAULT] - debug = true - enabled_share_backends = netapp - host = hostgroup - [netapp] - driver_handles_share_servers = False - share_backend_name = netapp - share_driver = manila.share.drivers.netapp.common.NetAppDriver - netapp_storage_family = ontap_cluster - netapp_transport_type = http - customServiceConfigSecrets: - - osp-secret-manila-netapp - replicas: 1 - < . . . > ----- - -[role="_additional-resources"] -.Additional resources -ifeval::["{build}" != "downstream"] -* https://docs.openstack.org/oslo.policy/latest/cli/oslopolicy-policy-generator.html[Oslo policy generator] -endif::[] -* link:https://catalog.redhat.com/software/containers/search?gs&q=manila[Red Hat Ecosystem Catalog] diff --git a/docs_user/modules/con_preventing-config-loss-when-using-oc-patch.adoc b/docs_user/modules/con_preventing-config-loss-when-using-oc-patch.adoc deleted file mode 100644 index ec66b4792..000000000 --- a/docs_user/modules/con_preventing-config-loss-when-using-oc-patch.adoc +++ /dev/null @@ -1,18 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="preventing-config-loss-when-using-oc-patch_{context}"] - -= Preventing configuration loss when using the `oc patch` command - -[role="_abstract"] -When you use `oc patch` to modify a resource, the changes are applied directly to live objects in your OpenShift cluster. If you later apply updates to the custom resource (CR) file by using `oc apply -f `, your previous patched changes are overwritten and lost from the resource. - -To prevent configuration loss, use the `--patch-file` option or export your `openstackcontrolplane` CR after the patch is applied. - ----- -$ oc get -o yaml > .yaml ----- - -For example: ----- -$ oc get OpenStackControlPlane openstack-control-plane -o yaml > openstack_control_plane.yaml ----- diff --git a/docs_user/modules/con_service-configurations.adoc b/docs_user/modules/con_service-configurations.adoc deleted file mode 100644 index bc61f3b6d..000000000 --- a/docs_user/modules/con_service-configurations.adoc +++ /dev/null @@ -1,84 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="service-configurations_{context}"] - -= Service configurations - -[role="_abstract"] -There is a fundamental difference between the {OpenStackPreviousInstaller} and operator deployments -regarding the configuration of the services. - -In {OpenStackPreviousInstaller} deployments many of the service configurations are abstracted by -{OpenStackPreviousInstaller}-specific configuration options. A single {OpenStackPreviousInstaller} option may trigger -changes for multiple services and support for drivers, for example, the Block Storage service (cinder), that -require patches to the {OpenStackPreviousInstaller} code base. - -In operator deployments this approach has changed: reduce the installer specific knowledge and leverage {OpenShift} ({OpenShiftShort}) and -{rhos_prev_long} ({OpenStackShort}) service specific knowledge whenever possible. - -To this effect {OpenStackShort} services will have sensible defaults for {OpenShiftShort} deployments and human operators will provide configuration snippets to provide -necessary configuration, such as the Block Storage service backend configuration, or to override -the defaults. - -This shortens the distance between a service specific configuration file (such -as `cinder.conf`) and what the human operator provides in the manifests. - -These configuration snippets are passed to the operators in the different -`customServiceConfig` sections available in the manifests, and then they are -layered in the services available in the following levels. To illustrate this, -if you were to set a configuration at the top Block Storage service level (`spec: cinder: -template:`) then it would be applied to all the Block Storage services; for example to -enable debug in all the Block Storage services you would do: - -[source,yaml] ----- -apiVersion: core.openstack.org/v1beta1 -kind: OpenStackControlPlane -metadata: - name: openstack -spec: - cinder: - template: - customServiceConfig: | - [DEFAULT] - debug = True -< . . . > ----- - -If you only want to set it for one of the Block Storage services, for example the -scheduler, then you use the `cinderScheduler` section instead: - -[source,yaml] ----- -apiVersion: core.openstack.org/v1beta1 -kind: OpenStackControlPlane -metadata: - name: openstack -spec: - cinder: - template: - cinderScheduler: - customServiceConfig: | - [DEFAULT] - debug = True -< . . . > ----- - -In {OpenShift} it is not recommended to store sensitive information like the -credentials to the Block Storage service storage array in the CRs, so most {OpenStackShort} operators -have a mechanism to use the {OpenShift} `Secrets` for sensitive configuration -parameters of the services and then use them by reference in the -`customServiceConfigSecrets` section which is analogous to the -`customServiceConfig`. - -The contents of the `Secret` references passed in the -`customServiceConfigSecrets` will have the same format as `customServiceConfig`: -a snippet with the section/s and configuration options. - -When there are sensitive information in the service configuration then it -becomes a matter of personal preference whether to store all the configuration -in the `Secret` or only the sensitive parts. However, if you split the -configuration between `Secret` and `customServiceConfig` you still need the -section header (eg: `[DEFAULT]`) to be present in both places. - -Attention should be paid to each service's adoption process as they may have -some particularities regarding their configuration. diff --git a/docs_user/modules/con_storage-driver-certification.adoc b/docs_user/modules/con_storage-driver-certification.adoc deleted file mode 100644 index e3ba5e5da..000000000 --- a/docs_user/modules/con_storage-driver-certification.adoc +++ /dev/null @@ -1,11 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="storage-driver-certification_{context}"] - -= Storage driver certification - -[role="_abstract"] -Confirm that your deployed storage drivers are certified for {rhos_acro} {rhos_curr_ver} before adoption. See the Red Hat Ecosystem Catalog for certified software. - -[role="_additional-resources"] -.Additional resources -* link:https://catalog.redhat.com/search?searchType=software&certified_versions=Red%20Hat%20OpenStack%20Services%20on%20OpenShift%2018&p=1[Red Hat Ecosystem Catalog] diff --git a/docs_user/modules/con_tlse-description.adoc b/docs_user/modules/con_tlse-description.adoc deleted file mode 100644 index ff6effc8a..000000000 --- a/docs_user/modules/con_tlse-description.adoc +++ /dev/null @@ -1,20 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="con_tlse-description_{context}"] - -= TLS Everywhere - -[role="_abstract"] -Note: The assumption is, that the new deployment will adopt the settings from the -old deployment, so in case TLS Everywhere is disabled, it won't be enabled on -the new deployment. - -If the Director deployment was deployed with TLS Everywhere, FreeIPA (IdM) is used -to issue certificates for the OpenStack services. Certmonger, a client process which -is installed on all hosts, interacts with FreeIPA (IdM) to request, install, track -and renew these certificates. - -The new Operator based deployment uses the cert-manager operator to issue, track -and renew the certificates. - -Because the same root CA is used to generate new certificates, the currently used chain -of trust doesn't have to be modified. diff --git a/docs_user/modules/con_troubleshooting-object-storage-migration.adoc b/docs_user/modules/con_troubleshooting-object-storage-migration.adoc deleted file mode 100644 index e51169283..000000000 --- a/docs_user/modules/con_troubleshooting-object-storage-migration.adoc +++ /dev/null @@ -1,40 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="troubleshooting-object-storage-migration_{context}"] - -= Troubleshooting the {object_storage} migration - -[role="_abstract"] -You can troubleshoot issues with the {object_storage_first_ref} migration. - -* If the replication is not working and the `swift-dispersion-report` is not back to 100% availability, check the replicator progress to help you debug: -+ ----- -$ CONTROLLER1_SSH tail /var/log/containers/swift/swift.log | grep object-server ----- -+ -The following shows an example of the output: -+ ----- -Mar 14 06:05:30 standalone object-server[652216]: cinder_dcn_patch.yaml -spec: - cinder: - enabled: true - template: - cinderAPI: - customServiceConfig: | - [DEFAULT] - default_availability_zone = az-central - cinderScheduler: - replicas: 1 - cinderVolumes: - central: - networkAttachments: - - storage - replicas: 1 - customServiceConfig: | - [DEFAULT] - enabled_backends = central - glance_api_servers = http://glance-central-internal.openstack.svc:9292 - [central] - backend_host = hostgroup - volume_backend_name = central - volume_driver = cinder.volume.drivers.rbd.RBDDriver - rbd_ceph_conf = /etc/ceph/central.conf - rbd_user = openstack - rbd_pool = volumes - rbd_flatten_volume_from_snapshot = False - report_discard_supported = True - rbd_secret_uuid = ** - rbd_cluster_name = central - backend_availability_zone = az-central - dcn1: - networkAttachments: - - storage - replicas: 1 - customServiceConfig: | - [DEFAULT] - enabled_backends = dcn1 - glance_api_servers = http://glance-dcn1-internal.openstack.svc:9292 - [dcn1] - backend_host = hostgroup - volume_backend_name = dcn1 - volume_driver = cinder.volume.drivers.rbd.RBDDriver - rbd_ceph_conf = /etc/ceph/dcn1.conf - rbd_user = openstack - rbd_pool = volumes - rbd_flatten_volume_from_snapshot = False - report_discard_supported = True - rbd_secret_uuid = ** - rbd_cluster_name = dcn1 - backend_availability_zone = az-dcn1 - dcn2: - networkAttachments: - - storage - replicas: 1 - customServiceConfig: | - [DEFAULT] - enabled_backends = dcn2 - glance_api_servers = http://glance-dcn2-internal.openstack.svc:9292 - [dcn2] - backend_host = hostgroup - volume_backend_name = dcn2 - volume_driver = cinder.volume.drivers.rbd.RBDDriver - rbd_ceph_conf = /etc/ceph/dcn2.conf - rbd_user = openstack - rbd_pool = volumes - rbd_flatten_volume_from_snapshot = False - report_discard_supported = True - rbd_secret_uuid = ** - rbd_cluster_name = dcn2 - backend_availability_zone = az-dcn2 -EOF ----- -+ -where: - -``:: -Specifies the `fsid` of the central {Ceph} cluster, used as the libvirt secret UUID. - -``:: -Specifies the `fsid` of the DCN1 edge {Ceph} cluster. - -``:: -Specifies the `fsid` of the DCN2 edge {Ceph} cluster. - -+ -[NOTE] -==== -* You must configure each `CinderVolume` with the `backend_availability_zone` value that matches your {compute_service} availability zone for that site, because `cross_az_attach = False` is set in the {compute_service} configuration. If the names do not match, instances cannot attach volumes. Replace the examples (`az-central`, `az-dcn1`, `az-dcn2`) with the names used in your {rhos_prev_long} deployment. -* Each `CinderVolume` points to its local {image_service} API endpoint through `glance_api_servers`. This ensures that volume creation from images uses the local {image_service} and {Ceph} cluster. The examples use `http://` for the {image_service} endpoints. If your {rhos_prev_long} deployment uses TLS for internal endpoints, use `https://` instead, and ensure that you have completed the TLS migration. For more information, see xref:migrating-tls-everywhere_configuring-network[Migrating TLS-e to the RHOSO deployment]. -* The `rbd_cluster_name` setting identifies which {Ceph} cluster configuration to use from the mounted secrets. -* Adjust the number of edge sites and their names to match your DCN deployment. -==== - -. Patch the `OpenStackControlPlane` CR to deploy the {block_storage} with multiple {Ceph} back ends: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch-file cinder_dcn_patch.yaml ----- - -. Configure the {block_storage} backup service. In this example, the backup service runs at the central site and uses the central {Ceph} cluster. Add the `cinderBackups` section to your patch file and re-apply it: -+ -[subs="+quotes"] ----- -$ cat << EOF >> cinder_dcn_patch.yaml - cinderBackups: - central: - networkAttachments: - - storage - replicas: 1 - customServiceConfig: | - [DEFAULT] - backup_driver=cinder.backup.drivers.ceph.CephBackupDriver - backup_ceph_conf=/etc/ceph/central.conf - backup_ceph_user=openstack - backup_ceph_pool=backups - storage_availability_zone=az-central -EOF -$ oc patch openstackcontrolplane openstack --type=merge --patch-file cinder_dcn_patch.yaml ----- -+ -[NOTE] -==== -Unlike a single-site {Ceph} deployment where the backup config references `/etc/ceph/ceph.conf`, in a DCN deployment the {Ceph} configuration files in the `ceph-conf-files` secret are named by cluster. Set `backup_ceph_conf` to the path of the {Ceph} configuration file for whichever cluster hosts your `backups` pool. In this example the file is named `central.conf`, so the path is `/etc/ceph/central.conf`. Using a path that does not match a file in the secret will cause the backup service to fail with a `conf_read_file` error. - -Set `storage_availability_zone` to match the availability zone of the volumes you want to back up. The backup scheduler uses this to route backup requests to a service in the correct zone. If the backup service zone does not match the volume zone, backup creation fails with `Service not found for creating backup`. -==== - -. Verify that the {block_storage} volume services are running for each availability zone: -+ ----- -$ openstack volume service list --service cinder-volume - -+------------------+---------------------+------------+---------+-------+----------------------------+ -| Binary | Host | Zone | Status | State | Updated At | -+------------------+---------------------+------------+---------+-------+----------------------------+ -| cinder-volume | hostgroup@central | az-central | enabled | up | 2024-01-01T00:00:00.000000 | -| cinder-volume | hostgroup@dcn1 | az-dcn1 | enabled | up | 2024-01-01T00:00:00.000000 | -| cinder-volume | hostgroup@dcn2 | az-dcn2 | enabled | up | 2024-01-01T00:00:00.000000 | -+------------------+---------------------+------------+---------+-------+----------------------------+ ----- - -. Verify that the {block_storage} backup service is running and in the correct availability zone: -+ ----- -$ openstack volume service list --service cinder-backup - -+---------------+-------------------------+------------+---------+-------+----------------------------+ -| Binary | Host | Zone | Status | State | Updated At | -+---------------+-------------------------+------------+---------+-------+----------------------------+ -| cinder-backup | cinder-backup-central-0 | az-central | enabled | up | 2024-01-01T00:00:00.000000 | -+---------------+-------------------------+------------+---------+-------+----------------------------+ ----- - -. Test the backup service by creating a volume, backing it up, and restoring the backup: -+ ----- -$ openstack volume create --size 1 backup-test-vol - -$ openstack volume backup create --name backup-test-backup backup-test-vol - -$ openstack volume backup show backup-test-backup -+-----------------------+--------------------------------------+ -| Field | Value | -+-----------------------+--------------------------------------+ -| container | backups | -| fail_reason | None | -| name | backup-test-backup | -| size | 1 | -| status | available | -+-----------------------+--------------------------------------+ - -$ openstack volume backup restore backup-test-backup backup-test-restore ----- -+ -[NOTE] -==== -Some versions of the {rhocp_long} client display a `cannot unpack non-iterable VolumeBackupsRestore object` error after the restore command. This is a known issue in the client, the restore operation might not have failed. Verify by checking the restored volume status directly. -==== -+ ----- -$ openstack volume show backup-test-restore -c status -c availability_zone -c os-vol-host-attr:host -f value -available -az-central -hostgroup@central#central ----- diff --git a/docs_user/modules/proc_adopting-compute-services-to-the-data-plane.adoc b/docs_user/modules/proc_adopting-compute-services-to-the-data-plane.adoc deleted file mode 100644 index 6a24c0e19..000000000 --- a/docs_user/modules/proc_adopting-compute-services-to-the-data-plane.adoc +++ /dev/null @@ -1,894 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="adopting-compute-services-to-the-data-plane_{context}"] - -= Adopting Compute services to the {rhos_acro} data plane - -[role="_abstract"] -Adopt your Compute (nova) services to the {rhos_long} data plane. - -.Prerequisites - -* You have stopped the remaining control plane nodes, repositories, and packages on the {compute_service_first_ref} hosts. For more information, see xref:stopping-infrastructure-management-and-compute-services_{context}[Stopping infrastructure management and Compute services]. -* You have configured the Ceph back end for the `NovaLibvirt` service. For more information, see xref:configuring-a-ceph-backend_migrating-databases[Configuring a Ceph back end]. -* You have configured IP Address Management (IPAM): -+ ----- -$ oc apply -f - < *["standalone.localdomain"]="192.168.122.100"* -> # ** -> # ** -> # ** ->) -$ declare -A COMPUTES_CELL2 -$ export COMPUTES_CELL2=( -> # ** ->) -$ declare -A COMPUTES_CELL3 -$*export COMPUTES_CELL3=(* -> # ** -> # ** ->) - -$ declare -A COMPUTES_API_CELL1 -$*export COMPUTES_API_CELL1=(* -> ["standalone.localdomain"]="172.17.0.100" -> ["standalone2.localdomain"]="172.17.0.101" ->) - -$ NODESETS="" -$ for CELL in $(echo $RENAMED_CELLS); do -> ref="COMPUTES_$(echo ${CELL}|tr '[:lower:]' '[:upper:]')" -> eval names=\${!${ref}[@]} -> [ -z "$names" ] && continue -> NODESETS="'openstack-${CELL}', $NODESETS" ->done -$ NODESETS="[${NODESETS%,*}]" ----- -+ -** `DEFAULT_CELL_NAME="cell3"` defines the source cloud `default` cell that acquires a new `DEFAULT_CELL_NAME` on the destination cloud after adoption. -In a multi-cell adoption scenario, you can retain the original name, `default`, or create a new cell default name by providing the incremented index of the last cell in the source cloud. For example, if the incremented index of the last cell is `cell5`, the new cell default name is `cell6`. -** `export COMPUTES_CELL1=` For each cell, update the `<["standalone.localdomain"]="x.x.x.x">` value and the `COMPUTES_CELL` value with the names and IP addresses of the {compute_service} nodes that are connected to the `ctlplane` and `internalapi` networks. Do not specify a real FQDN defined for each network. Always use the same hostname for each connected network of a Compute node. Provide the IP addresses and the names of the hosts on the remaining networks of the source cloud as needed, or you can manually adjust the files that you generate in step 9 of this procedure. -** ``, ``, and `` specifies the names of your {compute_service} nodes for each cell. Assign all {compute_service} nodes from the source cloud `cell1` cell into `COMPUTES_CELL1`, and so on. -** `export COMPUTES_CELL=(` specifies all {compute_service} nodes that you assign from the source cloud `default` cell into `COMPUTES_CELL` and `COMPUTES_API_CELL`, where `` is the `DEFAULT_CELL_NAME` environment variable value. In this example, the `DEFAULT_CELL_NAME` environment variable value equals `cell3`. -** `export COMPUTES_API_CELL1=(` For each cell, update the `<["standalone.localdomain"]="192.168.122.100">` value and the `COMPUTES_API_CELL` value with the names and IP addresses of the {compute_service} nodes that are connected to the `ctlplane` and `internalapi` networks. `["standalone.localdomain"]="192.168.122.100"` defines the custom DNS domain in the FQDN value of the nodes. This value is used in the data plane node set `spec.nodes..hostName`. Do not specify a real FQDN defined for each network. Use the same hostname for each of its connected networks. Provide the IP addresses and the names of the hosts on the remaining networks of the source cloud as needed, or you can manually adjust the files that you generate in step 9 of this procedure. -** `NODESETS="'openstack-${CELL}', $NODESETS"` specifies the cells that contain Compute nodes. Cells that do not contain Compute nodes are omitted from this template because no node sets are created for the cells. -+ -[NOTE] -==== -If you deployed the source cloud with a `default` cell, and want to rename it during adoption, define the new name that you want to use, as shown in the following example: ----- -$ DEFAULT_CELL_NAME="cell1" -$ RENAMED_CELLS="cell1" ----- -==== - -[NOTE] -==== -Do not set a value for the `CEPH_FSID` parameter if the local storage back end is configured by the {compute_service} for libvirt. The storage back end must match the source cloud storage back end. You cannot change the storage back end during adoption. -==== - -.Procedure - -ifeval::["{build}" != "downstream"] -. Create a https://kubernetes.io/docs/concepts/configuration/secret/#ssh-authentication-secrets[ssh authentication secret] for the data plane nodes: -//kgilliga:I need to check if we will document this in Red Hat docs. -endif::[] -ifeval::["{build}" != "upstream"] -. Create an SSH authentication secret for the data plane nodes: -endif::[] -+ -[subs=+quotes] ----- -$ oc apply -f - < | base64 | sed \'s/^/ /') -endif::[] -EOF ----- -+ -ifeval::["{build}" == "downstream"] -* Replace `` with the path to your SSH key. -+ -For more information about creating data plane secrets, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/deploying_red_hat_openstack_services_on_openshift/assembly_creating-the-data-plane#proc_creating-the-data-plane-secrets_dataplane[Creating the data plane secrets] in _Deploying Red Hat OpenStack Services on OpenShift_. -endif::[] - -. Generate an ssh key-pair `nova-migration-ssh-key` secret: -+ ----- -$ cd "$(mktemp -d)" -$ ssh-keygen -f ./id -t ecdsa-sha2-nistp521 -N '' -$ oc get secret nova-migration-ssh-key || oc create secret generic nova-migration-ssh-key \ - --from-file=ssh-privatekey=id \ - --from-file=ssh-publickey=id.pub \ - --type kubernetes.io/ssh-auth -$ rm -f id* -$ cd - ----- - -. If TLS Everywhere is enabled, set `LIBVIRT_PASSWORD` to match the existing {OpenStackShort} deployment password: -+ ----- -declare -A TRIPLEO_PASSWORDS -TRIPLEO_PASSWORDS[default]="$HOME/overcloud-passwords.yaml" -LIBVIRT_PASSWORD=$(cat ${TRIPLEO_PASSWORDS[default]} | grep ' LibvirtTLSPassword:' | awk -F ': ' '{ print $2; }') -LIBVIRT_PASSWORD_BASE64=$(echo -n "$LIBVIRT_PASSWORD" | base64) ----- - -.. Create libvirt-secret when TLS-e is enabled: -+ ----- -$ oc apply -f - <` files. There is a requirement to index the `<*.conf>` files from '03' to '99', based on precedence. A `<99-*.conf>` file takes the highest precedence, while indexes below '03' are reserved for internal use. -+ -[NOTE] -If you adopt a live cloud, you might be required to carry over additional configurations for the default `nova` data plane services that are stored in the cell1 default `nova-extra-config` configuration map. Do not delete or overwrite the existing configuration in the `cell1` default `nova-extra-config` configuration map that is assigned to `nova`. Overwriting the configuration can break the data place services that rely on specific contents of the `nova-extra-config` configuration map. - -. Configure a {Ceph} back end for libvirt: -+ ----- -$ oc apply -f - <-metadata-neutron-config` secret to enable a local metadata service for cell. You should also set -`spec.nova.template.cellTemplates.cell.metadataServiceTemplate.enable` in the `OpenStackControlPlane/openstack` CR, as described in xref:adopting-the-compute-service_adopt-control-plane[Adopting the Compute service]. You can configure a single top-level metadata, or define the metadata per cell. -* `nova-$CELL-compute-config` specifies the secret that auto-generates for each `cell`. You must append the `nova-cell-compute-config` for each custom `OpenStackDataPlaneService` CR that is related to the {compute_service}. -* `nova-migration-ssh-key` specifies the secret that you must append for each custom `OpenStackDataPlaneService` CR that is related to the {compute_service}. -+ -[NOTE] -==== -When creating your data plane services for {compute_service} cells, review the following considerations: - -* In this example, the same `nova-migration-ssh-key` key is shared across cells. However, you should use different keys for different cells. -* For simple configuration overrides, you do not need a custom data plane service. However, to reconfigure the cell, `cell1`, -the safest option is to create a custom service and a dedicated configuration map for it. -* The cell, `cell1`, is already managed with the default `OpenStackDataPlaneService` CR called `nova` and its `nova-extra-config` configuration map. Do not change the default data plane service `nova` definition. The changes are lost when the {rhos_acro} operator is updated with OLM. -* When a cell spans multiple node sets, give the custom `OpenStackDataPlaneService` resources a name that relates to the node set, for example, `nova-cell1-nfv` and `nova-cell1-enterprise`. The auto-generated configuration maps are then named `nova-cell1-nfv-extra-config` and `nova-cell1-enterprise-extra-config`. -* Different configurations for nodes in multiple node sets of the same cell are also supported, but are not covered in this guide. -==== - -. If TLS Everywhere is enabled, append the following content to the `OpenStackDataPlaneService` CR: -+ ----- - tlsCerts: - nova: - contents: - - dnsnames - - ips - networks: - - ctlplane - issuer: osp-rootca-issuer-internal - edpmRoleServiceName: nova - caCerts: combined-ca-bundle - edpmServiceType: nova ----- - -ifeval::["{build}" == "downstream"] -. Create a secret for the subscription manager: -+ ----- -$ oc create secret generic subscription-manager \ ---from-literal rhc_auth='{"login": {"username": "", "password": ""}}' ----- -+ -* Replace `` with the applicable username. -* Replace `` with the applicable password. - -. Create a secret for the Red Hat registry: -+ ----- -$ oc create secret generic redhat-registry \ ---from-literal edpm_container_registry_logins='{"registry.redhat.io": {"": ""}}' ----- -+ -* Replace `` with the applicable username. -* Replace `` with the applicable password. -endif::[] -+ - -[NOTE] -You do not need to reference the `subscription-manager` secret in the `dataSources` field of the `OpenStackDataPlaneService` CR. -The secret is already passed in with a node-specific `OpenStackDataPlaneNodeSet` CR in the `ansibleVarsFrom` property in the `nodeTemplate` field. - - -. Create the data plane node set definitions for each cell: -+ -[subs="+quotes"] ----- -$ declare -A names -$ for CELL in $(echo $RENAMED_CELLS); do - ref="COMPUTES_$(echo ${CELL}|tr '[:lower:]' '[:upper:]')" - eval names=\${!${ref}[@]} - ref_api="COMPUTES_API_$(echo ${CELL}|tr '[:lower:]' '[:upper:]')" - [ -z "$names" ] && continue - ind=0 - rm -f computes-$CELL - for compute in $names; do - ip="${ref}['$compute']" - ip_api="${ref_api}['$compute']" - cat >> computes-$CELL << EOF - ${compute}: - hostName: $compute - ansible: - ansibleHost: $compute - networks: - - defaultRoute: true - fixedIP: ${!ip} - name: ctlplane - subnetName: subnet1 - - name: internalapi - subnetName: subnet1 - fixedIP: ${!ip_api} - - name: storage - subnetName: subnet1 - - name: tenant - subnetName: subnet1 -EOF - ind=$(( ind + 1 )) - done - - test -f computes-$CELL || continue - cat > nodeset-${CELL}.yaml <", state: enabled} - - {name: "", state: enabled} - - {name: "", state: enabled} - - {name: "", state: enabled} - - {name: "", state: enabled} - - {name: "", state: enabled} -endif::[] - edpm_bootstrap_release_version_package: [] - # edpm_network_config - # Default nic config template for a EDPM node - # These vars are edpm_network_config role vars - edpm_network_config_template: | - --- - {% set mtu_list = [ctlplane_mtu] %} - {% for network in nodeset_networks %} - {% set _ = mtu_list.append(lookup('vars', networks_lower[network] ~ '_mtu')) %} - {%- endfor %} - {% set min_viable_mtu = mtu_list | max %} - network_config: - - type: ovs_bridge - name: {{ neutron_physical_bridge_name }} - mtu: {{ min_viable_mtu }} - use_dhcp: false - dns_servers: {{ ctlplane_dns_nameservers }} - domain: {{ dns_search_domains }} - addresses: - - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_cidr }} - routes: {{ ctlplane_host_routes }} - members: - - type: interface - name: nic1 - mtu: {{ min_viable_mtu }} - # force the MAC address of the bridge to this interface - primary: true - {% for network in nodeset_networks %} - - type: vlan - mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }} - vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }} - addresses: - - ip_netmask: - {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }} - routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }} - {% endfor %} - - edpm_network_config_nmstate: false - # Control resolv.conf management by NetworkManager - # false = disable NetworkManager resolv.conf update (default) - # true = enable NetworkManager resolv.conf update - edpm_bootstrap_network_resolvconf_update: false - edpm_network_config_hide_sensitive_logs: false - # - # These vars are for the network config templates themselves and are - # considered EDPM network defaults. - neutron_physical_bridge_name: br-ctlplane - neutron_public_interface_name: eth0 - - # edpm_nodes_validation - edpm_nodes_validation_validate_controllers_icmp: false - edpm_nodes_validation_validate_gateway_icmp: false - - # edpm ovn-controller configuration - edpm_ovn_bridge_mappings: [<"bridge_mappings">] - edpm_ovn_bridge: br-int - edpm_ovn_encap_type: geneve - ovn_monitor_all: true - edpm_ovn_remote_probe_interval: 60000 - edpm_ovn_ofctrl_wait_before_clear: 8000 - - timesync_ntp_servers: -ifeval::["{build}" != "downstream"] - - hostname: pool.ntp.org -endif::[] -ifeval::["{build}" == "downstream"] - - hostname: clock.redhat.com - - hostname: clock2.redhat.com -endif::[] - -ifeval::["{build}" != "downstream"] - edpm_bootstrap_command: | - # This is a hack to deploy RDO Delorean repos to RHEL as if it were Centos 9 Stream - set -euxo pipefail - curl -sL https://github.com/openstack-k8s-operators/repo-setup/archive/refs/heads/main.tar.gz | tar -xz - python3 -m venv ./venv - PBR_VERSION=0.0.0 ./venv/bin/pip install ./repo-setup-main - # This is required for FIPS enabled until trunk.rdoproject.org - # is not being served from a centos7 host, tracked by - # https://issues.redhat.com/browse/RHOSZUUL-1517 - sudo dnf -y install crypto-policies - sudo update-crypto-policies --set FIPS:NO-ENFORCE-EMS - sudo ./venv/bin/repo-setup current-podified -b antelope -d centos9 --stream - sudo dnf -y upgrade openstack-selinux - sudo rm -f /run/virtlogd.pid - sudo rm -rf repo-setup-main -endif::[] -ifeval::["{build}" == "downstream"] - edpm_bootstrap_command: | - set -euxo pipefail - sudo dnf -y upgrade openstack-selinux - sudo rm -f /run/virtlogd.pid -endif::[] - - gather_facts: false - # edpm firewall, change the allowed CIDR if needed - edpm_sshd_configure_firewall: true - edpm_sshd_allowed_ranges: ['192.168.122.0/24'] - - # Do not attempt OVS major upgrades here - edpm_ovs_packages: - - openvswitch3.3 - edpm_default_mounts: - - path: /dev/hugepages - opts: pagesize= - fstype: hugetlbfs - group: hugetlbfs - nodes: -EOF - cat computes-$CELL >> nodeset-${CELL}.yaml -done ----- -+ -* `${compute}.hostName` specifies the FQDN for the node if your deployment has a custom DNS Domain. -* `${compute}.networks` specifies the network composition. The network composition must match the source cloud configuration to avoid data plane connectivity downtime. The `ctlplane` network must come first. The commands only retain IP addresses for the hosts on the `ctlplane` and `internalapi` networks. Repeat this step for other isolated networks, or update the resulting files manually. -* `${compute}.ansible.ansibleHost` specifies the Ansible host for the Compute node. If you are not using DNS, use the value `${!ip}`. -* `metadata.name:` specifies the node set names for each cell, for example, `openstack-cell1`, `openstack-cell2`. Only create node sets for cells that contain Compute nodes. -* `spec.tlsEnabled` specifies whether TLS Everywhere is enabled. If it is enabled, change `tlsEnabled` to `true`. -* `spec.services` specifies the services to be adopted. If you are not adopting telemetry services, omit it from the services list. -* `neutron_physical_bridge_name: br-ctlplane` specifies the bridge name. The bridge name and other OVN and {networking_service}-specific values must match the source cloud configuration to avoid data plane connectivity downtime. -* `edpm_ovn_bridge_mappings`: Replace `[<"bridge_mappings">]` with the value of the bridge mappings in your configuration, for example, `["datacentre:br-ctlplane"]`. -* `path: /dev/hugepages` and `opts: pagesize=` configures huge pages. Replace `` with the size of the page. To configure multi-sized huge pages, create more items in the list. Note that the mount points must match the source cloud configuration. -* ``, ``, ``, ``, ``, `` specifies the name of the repository to enable. For more information about which repositories are required, see link:https://access.redhat.com/articles/7139612[Required repositories for Red Hat OpenStack Services on OpenShift 18.0]. -+ -[NOTE] -==== -Ensure that you use the same `ovn-controller` settings in the `OpenStackDataPlaneNodeSet` CR that you used in the {compute_service} nodes before adoption. This configuration is stored in the `external_ids` column in the `Open_vSwitch` table in the Open vSwitch database: - ----- -$ ovs-vsctl list Open . -... -external_ids : {hostname=standalone.localdomain, ovn-bridge=br-int, ovn-bridge-mappings=, ovn-chassis-mac-mappings="datacentre:1e:0a:bb:e6:7c:ad", ovn-encap-ip="172.19.0.100", ovn-encap-tos="0", ovn-encap-type=geneve, ovn-match-northd-version=False, ovn-monitor-all=True, ovn-ofctrl-wait-before-clear="8000", ovn-openflow-probe-interval="60", ovn-remote="tcp:ovsdbserver-sb.openstack.svc:6642", ovn-remote-probe-interval="60000", rundir="/var/run/openvswitch", system-id="2eec68e6-aa21-4c95-a868-31aeafc11736"} -... ----- -==== - -. Deploy the `OpenStackDataPlaneNodeSet` CRs for each Compute cell: -+ ----- -for CELL in $(echo $RENAMED_CELLS); do -test -f nodeset-${CELL}.yaml || continue -oc apply -f nodeset-${CELL}.yaml -done ----- - -. If you use a {Ceph} back end for {block_storage_first_ref}, prepare the adopted data plane workloads: -+ ----- -for CELL in $(echo $RENAMED_CELLS); do -test -f nodeset-${CELL}.yaml || continue -oc patch osdpns/openstack-$CELL --type=merge --patch " -spec: - services: -ifeval::["{build}" == "downstream"] - - redhat -endif::[] - - bootstrap - - download-cache - - configure-network - - validate-network - - install-os - - configure-os - - ssh-known-hosts - - run-os - - reboot-os - - ceph-client - - install-certs - - ovn - - neutron-metadata - - libvirt - - nova-$CELL - - telemetry - nodeTemplate: - extraMounts: - - extraVolType: Ceph - volumes: - - name: ceph - secret: - secretName: ceph-conf-files - mounts: - - name: ceph - mountPath: "/etc/ceph" - readOnly: true - " -done ----- -ifeval::["{build}" != "downstream"] -+ -[NOTE] -==== -Ensure that you use the same list of services from the original `OpenStackDataPlaneNodeSet` CR, except for the `ceph-client` and `ceph-hci-pre` services. - -For environments that are enabled with border gateway protocol (BGP), you must add the following services to the list in the order shown: - -* After `configure-network` and before `validate-network`: Add `frr` service for FRRouting BGP support -* After `neutron-metadata` and before `libvirt`: Add `ovn-bgp-agent` service for OVN BGP agent - -You must also configure the following additional Ansible variables in the `nodeTemplate.ansible.ansibleVars` section: - -* `edpm_frr_image`: The FRRouting container image -* `edpm_ovn_bgp_agent_image`: The OVN BGP agent container image -* `edpm_frr_bgp_ipv4_src_network`: The network name for BGP IPv4 source (for example, `bgpmainnet`) -* `edpm_frr_bgp_ipv6_src_network`: The network name for BGP IPv6 source (for example, `bgpmainnetv6`) -* `edpm_frr_bgp_neighbor_password`: The BGP neighbor password -* `edpm_ovn_encap_ip`: Set to the BGP main network IP (for example, `{{ lookup("vars", "bgpmainnet_ip") }}`) -==== -endif::[] - -. Optional: Enable `neutron-sriov-nic-agent` in the `OpenStackDataPlaneNodeSet` CR: -+ ----- -for CELL in $(echo $RENAMED_CELLS); do -test -f nodeset-${CELL}.yaml || continue -oc patch openstackdataplanenodeset openstack-$CELL --type='json' --patch='[ -{ - "op": "add", - "path": "/spec/services/-", - "value": "neutron-sriov" -}, { - "op": "add", - "path": "/spec/nodeTemplate/ansible/ansibleVars/edpm_neutron_sriov_agent_SRIOV_NIC_physical_device_mappings", - "value": "dummy_sriov_net:dummy-dev" -}, { - "op": "add", - "path": "/spec/nodeTemplate/ansible/ansibleVars/edpm_neutron_sriov_agent_SRIOV_NIC_resource_provider_bandwidths", - "value": "dummy-dev:40000000:40000000" -}, { - "op": "add", - "path": "/spec/nodeTemplate/ansible/ansibleVars/edpm_neutron_sriov_agent_SRIOV_NIC_resource_provider_hypervisors", - "value": "dummy-dev:standalone.localdomain" -}]' -done ----- - -. Optional: Enable `neutron-dhcp` in the `OpenStackDataPlaneNodeSet` CR: -+ ----- -for CELL in $(echo $RENAMED_CELLS); do -test -f nodeset-${CELL}.yaml || continue -oc patch openstackdataplanenodeset openstack-$CELL --type='json' --patch='[ -{ - "op": "add", - "path": "/spec/services/-", - "value": "neutron-dhcp" -}]' -done ----- -+ -[NOTE] -==== -To use `neutron-dhcp` with OVN for the {bare_metal_first_ref}, you must set the `disable_ovn_dhcp_for_baremetal_ports` configuration option for the {networking_first_ref} to `true`. You can set this configuration in the `NeutronAPI` spec: ----- -.. -spec: - serviceUser: neutron - ... - customServiceConfig: | - [DEFAULT] - dhcp_agent_notification = True - [ovn] - disable_ovn_dhcp_for_baremetal_ports = true ----- -==== -. Run the pre-adoption validation: - -.. Create the validation service: -+ ----- -$ oc apply -f - <"' | base64 -d | awk '/fsid/{print $3}') -$ CEPH_FSID_DCN1=$(oc get secret ceph-conf-dcn1 -o json | jq -r '.data.""' | base64 -d | awk '/fsid/{print $3}') -$ CEPH_FSID_DCN2=$(oc get secret ceph-conf-dcn2 -o json | jq -r '.data.""' | base64 -d | awk '/fsid/{print $3}') ----- -+ -where: - -``:: -Specifies the name of the {Ceph} configuration file for the central site in the `ceph-conf-central` secret. - -``:: -Specifies the name of the {Ceph} configuration file for an edge site in the `ceph-conf-dcn1` secret. - -``:: -Specifies the name of the {Ceph} configuration file for an additional edge site in the `ceph-conf-dcn2` secret. - -. Create a `ConfigMap` for each site. Each `ConfigMap` contains the {Ceph} and {image_service} configuration specific to that site. -+ -The following example creates `ConfigMap` resources for a central site and two edge sites. -+ -.. Create the `ConfigMap` for the central site: -+ ----- -$ oc apply -f - <* - spec: - type: LoadBalancer - networkAttachments: - - storage ----- -+ -where: - -<172.17.0.80>:: -Specifies the load balancer IP. If you use IPv6, change the load balancer IP to the load balancer IP in your environment, for example, `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80`. -+ -[NOTE] -The {block_storage} as a back end establishes a dependency with the {image_service}. Any deployed `GlanceAPI` instances do not work if the {image_service} is configured with the {block_storage} that is not available in the `OpenStackControlPlane` custom resource. -After the {block_storage}, and in particular `CinderVolume`, is adopted, you can proceed with the `GlanceAPI` adoption. For more information, see xref:adopting-the-block-storage-service_adopt-control-plane[Adopting the Block Storage service]. - -. Verify that `CinderVolume` is available: -+ ----- -$ oc get pod -l component=cinder-volume | grep Running -cinder-volume-75cb47f65-92rxq 3/3 Running 0 ----- - -. Patch the `GlanceAPI` service that is deployed in the control plane: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch-file=glance_cinder.patch ----- diff --git a/docs_user/modules/proc_adopting-image-service-with-ceph-backend.adoc b/docs_user/modules/proc_adopting-image-service-with-ceph-backend.adoc deleted file mode 100644 index d1e3d9f41..000000000 --- a/docs_user/modules/proc_adopting-image-service-with-ceph-backend.adoc +++ /dev/null @@ -1,82 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="adopting-image-service-with-ceph-backend_{context}"] - -= Adopting the {image_service} that is deployed with a {Ceph} back end - -[role="_abstract"] -Adopt the {image_service_first_ref} that you deployed with a {Ceph} back end. Use the `customServiceConfig` parameter to inject the right configuration to the `GlanceAPI` instance. - -.Prerequisites - -* You have completed the previous adoption steps. -* Ensure that the Ceph-related secret (`ceph-conf-files`) is created in -the `openstack` namespace and that the `extraMounts` property of the -`OpenStackControlPlane` custom resource (CR) is configured properly. For more information, see xref:configuring-a-ceph-backend_migrating-databases[Configuring a Ceph back end]. -+ -[subs="+quotes"] ----- -$ cat << EOF > glance_patch.yaml -spec: - glance: - enabled: true - template: - databaseInstance: openstack - customServiceConfig: | - [DEFAULT] - enabled_backends=default_backend:rbd - [glance_store] - default_backend=default_backend - [default_backend] - rbd_store_ceph_conf=/etc/ceph/ceph.conf - rbd_store_user=openstack - rbd_store_pool=images - store_description=Ceph glance store backend. - storage: - storageRequest: 10G - glanceAPIs: - default: - replicas: 3 - override: - service: - internal: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/allow-shared-ip: internalapi - *metallb.universe.tf/loadBalancerIPs: <172.17.0.80>* - spec: - type: LoadBalancer - networkAttachments: - - storage -EOF ----- -+ -where: - -<172.17.0.80>:: -Specifies the load balancer IP. If you use IPv6, change the load balancer IP to the load balancer IP in your environment, for example, `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80`. - -[NOTE] -==== -If you backed up your {rhos_prev_long} ({OpenStackShort}) services configuration file from the original environment, you can compare it with the confgiuration file that you adopted and ensure that the configuration is correct. -For more information, see xref:pulling-configuration-from-tripleo-deployment_adopt-control-plane[Pulling the configuration from a {OpenStackPreviousInstaller} deployment]. - -ifeval::["{build_variant}" == "ospdo"] -[NOTE] -Os-diff does not currently support director Operator. -endif::[] - ----- -os-diff diff /tmp/collect_tripleo_configs/glance/etc/glance/glance-api.conf glance_patch.yaml --crd ----- - -This command produces the difference between both ini configuration files. -==== - -.Procedure - -* Patch the `OpenStackControlPlane` CR to deploy the {image_service} with a {Ceph} back end: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch-file glance_patch.yaml ----- diff --git a/docs_user/modules/proc_adopting-image-service-with-dcn-backend.adoc b/docs_user/modules/proc_adopting-image-service-with-dcn-backend.adoc deleted file mode 100644 index d6b94bb2f..000000000 --- a/docs_user/modules/proc_adopting-image-service-with-dcn-backend.adoc +++ /dev/null @@ -1,262 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="adopting-image-service-with-dcn-backend_{context}"] - -= Adopting the {image_service} with multiple {Ceph} back ends (DCN) - -[role="_abstract"] -Adopt the {image_service_first_ref} in a Distributed Compute Node (DCN) deployment with multiple {CephCluster} clusters that provide storage at different sites. - -This configuration deploys multiple `GlanceAPI` instances: a central API with access to all {Ceph} clusters, and edge APIs at each DCN site with access to their local cluster and the central cluster. - -During adoption, the {image_service} instances that ran on edge site Compute nodes are migrated to run on {rhocp_long} at the central site. Although the control path for API requests now traverses the WAN to reach the {image_service} running on {rhocp_long}, the data path remains local. Image data continues to be stored in the {Ceph} cluster at each edge site. When you create a virtual machine or volume from an image, the operation occurs at the local {Ceph} cluster. This architecture uses {Ceph} shallow copies (copy-on-write clones) to enable fast boot times without transferring image data across the WAN. - -The virtual IP addresses (VIPs) used by {compute_service} nodes to reach the {image_service} change during adoption. Before adoption, edge site nodes contact a local {image_service} VIP on the `internalapi` subnet. After adoption, they contact a {rhocp_long} service endpoint on a different `internalapi` subnet. The following table shows an example of this change: - -[cols="1,2,2"] -|=== -| Site | Before adoption | After adoption - -| Central -| {identity_service} catalog VIP -| {identity_service} catalog updated to `\http://glance-central-internal.openstack.svc:9292` - -| DCN1 -| `\http://172.17.10.111:9293` -| `\http://glance-dcn1-internal.openstack.svc:9292` - -| DCN2 -| `\http://172.17.20.121:9293` -| `\http://glance-dcn2-internal.openstack.svc:9292` -|=== - -In {rhos_prev_long}, the internal {image_service} endpoint at edge sites used TCP port 9293, after adoption, all {image_service} endpoints use port 9292. The new endpoints are backed by MetalLB load balancer IPs that you assign using the `metallb.universe.tf/loadBalancerIPs` annotation on each `GlanceAPI`. When you patch the `OpenStackControlPlane` custom resource (CR), {rhocp_long} creates internal Kubernetes services (for example, `glance-dcn1-internal.openstack.svc`) that resolve to those MetalLB IPs. The {compute_service} nodes are configured to use these endpoints when you adopt the data plane. For more information, see xref:adopting-compute-services-with-dcn-backend_data-plane[Adopting Compute services with multiple Ceph back ends (DCN)]. The examples in this procedure use `http://` for the {image_service} endpoints. If your {rhos_prev_long} deployment uses TLS for internal endpoints, use `https://` and ensure that you have completed the TLS migration. For more information, see xref:migrating-tls-everywhere_configuring-network[Migrating TLS-e to the RHOSO deployment]. - -.Prerequisites - -* You have completed the previous adoption steps. -* The per-site {Ceph} secrets (`ceph-conf-central`, `ceph-conf-dcn1`, `ceph-conf-dcn2`) exist and contain the configuration and keyrings for each site's {Ceph} cluster. For more information, see xref:configuring-a-ceph-backend_migrating-databases[Configuring a {Ceph} back end]. -* The `extraMounts` property of the `OpenStackControlPlane` CR is configured to mount the {Ceph} configuration to all Glance instances. -* You have stopped the {image_service} on all DCN nodes. If your deployment includes `DistributedComputeHCIScaleOut` or `DistributedComputeScaleOut` nodes, you have also stopped HAProxy on those nodes. For more information, see xref:stopping-openstack-services_migrating-databases[Stopping {rhos_prev_long} services]. - -.Procedure - -. Create a patch file for the {image_service} with multiple {Ceph} back ends. Use MetalLB loadbalancer IPs for the {image_service} endpoints: -+ -Example DCN deployment with a central site and two edge sites: -+ -[subs="+quotes"] ----- -$ cat << EOF > glance_dcn_patch.yaml -spec: - glance: - enabled: true - template: - databaseInstance: openstack - databaseAccount: glance - keystoneEndpoint: central - storage: - storageRequest: *<10G>* - glanceAPIs: - central: - type: split - replicas: 3 - override: - service: - internal: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/allow-shared-ip: internalapi - *metallb.universe.tf/loadBalancerIPs: <172.17.0.80>* - spec: - type: LoadBalancer - networkAttachments: - - storage - customServiceConfig: | - [DEFAULT] - enabled_import_methods = [web-download,copy-image,glance-direct] - enabled_backends = central:rbd,dcn1:rbd,dcn2:rbd - [glance_store] - default_backend = central - [central] - rbd_store_ceph_conf = /etc/ceph/central.conf - store_description = "Central RBD backend" - rbd_store_pool = images - rbd_store_user = openstack - rbd_thin_provisioning = True - [dcn1] - rbd_store_ceph_conf = /etc/ceph/dcn1.conf - store_description = "DCN1 RBD backend" - rbd_store_pool = images - rbd_store_user = openstack - rbd_thin_provisioning = True - [dcn2] - rbd_store_ceph_conf = /etc/ceph/dcn2.conf - store_description = "DCN2 RBD backend" - rbd_store_pool = images - rbd_store_user = openstack - rbd_thin_provisioning = True - dcn1: - type: edge - replicas: 2 - override: - service: - internal: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/allow-shared-ip: internalapi - *metallb.universe.tf/loadBalancerIPs: <172.17.0.81>* - spec: - type: LoadBalancer - networkAttachments: - - storage - customServiceConfig: | - [DEFAULT] - enabled_import_methods = [web-download,copy-image,glance-direct] - enabled_backends = central:rbd,dcn1:rbd - [glance_store] - default_backend = dcn1 - [central] - rbd_store_ceph_conf = /etc/ceph/central.conf - store_description = "Central RBD backend" - rbd_store_pool = images - rbd_store_user = openstack - rbd_thin_provisioning = True - [dcn1] - rbd_store_ceph_conf = /etc/ceph/dcn1.conf - store_description = "DCN1 RBD backend" - rbd_store_pool = images - rbd_store_user = openstack - rbd_thin_provisioning = True - dcn2: - type: edge - replicas: 2 - override: - service: - internal: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/allow-shared-ip: internalapi - *metallb.universe.tf/loadBalancerIPs: <172.17.0.82>* - spec: - type: LoadBalancer - networkAttachments: - - storage - customServiceConfig: | - [DEFAULT] - enabled_import_methods = [web-download,copy-image,glance-direct] - enabled_backends = central:rbd,dcn2:rbd - [glance_store] - default_backend = dcn2 - [central] - rbd_store_ceph_conf = /etc/ceph/central.conf - store_description = "Central RBD backend" - rbd_store_pool = images - rbd_store_user = openstack - rbd_thin_provisioning = True - [dcn2] - rbd_store_ceph_conf = /etc/ceph/dcn2.conf - store_description = "DCN2 RBD backend" - rbd_store_pool = images - rbd_store_user = openstack - rbd_thin_provisioning = True -EOF ----- -+ -where: - -`<172.17.0.80>`:: -Specifies the load balancer IP for the central {image_service} API. - -`<172.17.0.81>`:: -Specifies the load balancer IP for the DCN1 edge {image_service} API. - -`<172.17.0.82>`:: -Specifies the load balancer IP for the DCN2 edge {image_service} API. - -+ -You must configure the Compute nodes at each site to use their local {image_service} endpoints. For example, Compute nodes at central use 172.17.0.80, Compute nodes at dcn1 use 172.17.0.81, and Compute nodes at dcn2 use 172.17.0.82. This configuration is applied when you adopt the data plane by adding a per-site ConfigMap with the `glance_api_servers` setting to each `OpenStackDataPlaneNodeSet`. For more information, see xref:adopting-compute-services-to-the-data-plane_data-plane[Adopting Compute services to the data plane]. - -+ -[NOTE] -==== -* The central `GlanceAPI` uses `type: split` and has access to all {Ceph} clusters. The `keystoneEndpoint: central` setting registers this API as the public endpoint in the {identity_service}. -* Each edge `GlanceAPI` uses `type: edge` and has access to its local {Ceph} cluster plus the central cluster. This enables image copying between sites. -* Set the `storageRequest` PVC size based on the storage requirements of each edge site. -* Adjust the number of edge sites and their names to match your DCN deployment. -==== - -. Patch the `OpenStackControlPlane` CR to deploy the {image_service} with multiple {Ceph} back ends: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch-file glance_dcn_patch.yaml ----- - -. Verify that the {image_service} stores are available for each site: -+ ----- -$ glance stores-info -+----------+----------------------------------------------------------------------------------+ -| Property | Value | -+----------+----------------------------------------------------------------------------------+ -| stores | [{"id": "central", "description": "Central RBD backend", "default": "true"}, | -| | {"id": "dcn1", "description": "dcn1 RBD backend"}, {"id": "dcn2", "description": | -| | "dcn2 RBD backend"}] | -+----------+----------------------------------------------------------------------------------+ ----- -+ -The output should list one store for each {Ceph} back end configured in the central `GlanceAPI`, and the central store should be marked as the default. If any stores are missing, check the `customServiceConfig` in the `glanceAPIs` section of the patch and verify that the {Ceph} configuration files are present in the `ceph-conf-central` secret. - -. Verify that image import methods include `copy-image`, which is required for copying images between stores: -+ ----- -$ glance import-info -+----------------+----------------------------------------------------------------------------------+ -| Property | Value | -+----------------+----------------------------------------------------------------------------------+ -| import-methods | {"description": "Import methods available.", "type": "array", "value": ["web- | -| | download", "copy-image", "glance-direct"]} | -+----------------+----------------------------------------------------------------------------------+ ----- - -. Upload a test image to the central store. Note the image ID: -+ ----- -$ glance image-create --disk-format raw --container-format bare --name test-image \ - --file --store central ----- - -. Verify that the image ID from the previous command is shown in the central {CephCluster} cluster's `images` pool: -+ ----- -$ sudo cephadm shell --config /etc/ceph/central.conf --keyring /etc/ceph/central.client.openstack.keyring \ - -- rbd -p images --cluster central ls -l -NAME SIZE PARENT FMT PROT LOCK - 20 MiB 2 ----- - -. Copy the image to an edge site using the `copy-image` import method: -+ ----- -$ glance image-import --stores dcn1 --import-method copy-image ----- - -. After the import completes, verify that the `stores` field on the image now includes both `central` and `dcn1`: -+ ----- -$ glance image-show | grep stores -| stores | central,dcn1 | ----- - -. Verify the image was copied to the DCN1 {CephCluster} cluster: -+ ----- -$ sudo cephadm shell --config /etc/ceph/dcn1.conf --keyring /etc/ceph/dcn1.client.openstack.keyring \ - -- rbd -p images --cluster dcn1 ls -l -NAME SIZE PARENT FMT PROT LOCK - 20 MiB 2 ----- -+ -The image is now present on the DCN1 {CephCluster} cluster, confirming that {image_service} can copy images between sites. Repeat the `glance image-import` command for each additional edge site to distribute the image to all DCN locations. diff --git a/docs_user/modules/proc_adopting-image-service-with-nfs-backend.adoc b/docs_user/modules/proc_adopting-image-service-with-nfs-backend.adoc deleted file mode 100644 index 6eda37d46..000000000 --- a/docs_user/modules/proc_adopting-image-service-with-nfs-backend.adoc +++ /dev/null @@ -1,204 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="adopting-image-service-with-nfs-backend_{context}"] - -= Adopting the {image_service} that is deployed with an NFS back end - -[role="_abstract"] -Adopt the {image_service_first_ref} that you deployed with an NFS back end. To complete the following procedure, ensure that your environment meets the following criteria: - -* The Storage network is propagated to the {rhos_prev_long} ({OpenStackShort}) control plane. -* The {image_service} can reach the Storage network and connect to the nfs-server through the port `2049`. - -.Prerequisites - -* You have completed the previous adoption steps. -* In the source cloud, verify the NFS parameters that the overcloud uses to configure the {image_service} back end. Specifically, in your{OpenStackPreviousInstaller} heat templates, find the following variables that override the default content that is provided by the `glance-nfs.yaml` file in the -`/usr/share/openstack-tripleo-heat-templates/environments/storage` directory: -+ ----- - -GlanceBackend: file -GlanceNfsEnabled: true -GlanceNfsShare: 192.168.24.1:/var/nfs - ----- -+ -[NOTE] -==== -In this example, the `GlanceBackend` variable shows that the {image_service} has no notion of an NFS back end. The variable is using the `File` driver and, in the background, the `filesystem_store_datadir`. The `filesystem_store_datadir` is mapped to the export value provided by the `GlanceNfsShare` variable instead of `/var/lib/glance/images/`. -If you do not export the `GlanceNfsShare` through a network that is propagated to the adopted {rhos_long} control plane, you must stop the `nfs-server` and remap the export to the `storage` network. Before doing so, ensure that the {image_service} is stopped in the source Controller nodes. -ifeval::["{build}" != "downstream"] -In the control plane, as per the (https://github.com/openstack-k8s-operators/docs/blob/main/images/network_diagram.jpg)[network isolation diagram], -the {image_service} is attached to the Storage network, propagated via the associated `NetworkAttachmentsDefinition` custom resource, and the resulting Pods have already the right permissions to handle the {image_service} traffic through this network. -endif::[] - -ifeval::["{build}" != "upstream"] -In the control plane, the {image_service} is attached to the Storage network, then propagated through the associated `NetworkAttachmentsDefinition` custom resource (CR), and the resulting pods already have the right permissions to handle the {image_service} traffic through this network. -endif::[] -In a deployed {OpenStackShort} control plane, you can verify that the network mapping matches with what has been deployed in the {OpenStackPreviousInstaller}-based environment by checking both the `NodeNetworkConfigPolicy` (`nncp`) and the `NetworkAttachmentDefinition` (`net-attach-def`). The following is an example of the output that you should check in the {rhocp_long} environment to make sure that there are no issues with the propagated networks: - ----- -$ oc get nncp -NAME STATUS REASON -enp6s0-crc-8cf2w-master-0 Available SuccessfullyConfigured - -$ oc get net-attach-def -NAME -ctlplane -internalapi -storage -tenant - -$ oc get ipaddresspool -n metallb-system -NAME AUTO ASSIGN AVOID BUGGY IPS ADDRESSES -ctlplane true false ["192.168.122.80-192.168.122.90"] -internalapi true false ["172.17.0.80-172.17.0.90"] -storage true false ["172.18.0.80-172.18.0.90"] -tenant true false ["172.19.0.80-172.19.0.90"] ----- -==== - -.Procedure - -. Adopt the {image_service} and create a new `default` `GlanceAPI` instance that is connected with the existing NFS share: -+ -[subs="+quotes"] ----- -$ cat << EOF > glance_nfs_patch.yaml - -spec: - extraMounts: - - extraVol: - - extraVolType: Nfs - mounts: - - mountPath: /var/lib/glance/images - name: nfs - propagation: - - Glance - volumes: - - name: nfs - nfs: - *path: * - *server: * - name: r1 - region: r1 - glance: - enabled: true - template: - databaseInstance: openstack - customServiceConfig: | - [DEFAULT] - enabled_backends = default_backend:file - [glance_store] - default_backend = default_backend - [default_backend] - filesystem_store_datadir = /var/lib/glance/images/ - storage: - storageRequest: 10G - keystoneEndpoint: nfs - glanceAPIs: - nfs: - replicas: 3 - type: single - override: - service: - internal: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/allow-shared-ip: internalapi - metallb.universe.tf/loadBalancerIPs: *<172.17.0.80>* - spec: - type: LoadBalancer - networkAttachments: - - storage -EOF ----- -+ -where: - -:: -Specifies the exported path in the `nfs-server`. -:: -Specifies the IP address that you use to communicate with the `nfs-server`. -<172.17.0.80>:: -Specifies the load balancer IP in your environment. If you use IPv6, change the load balancer IP to the load balancer IP in your environment, for example, `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80`. - -. Patch the `OpenStackControlPlane` CR to deploy the {image_service} with an NFS back end: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch-file glance_nfs_patch.yaml ----- - -. Patch the `OpenStackControlPlane` CR to remove the default {image_service}: -+ ----- -$ oc patch openstackcontrolplane openstack --type=json -p="[{'op': 'remove', 'path': '/spec/glance/template/glanceAPIs/default'}]" ----- - -.Verification - -* When `GlanceAPI` is active, confirm that you can see a single API instance: -+ ----- -$ oc get pods -l service=glance -NAME READY STATUS RESTARTS -glance-nfs-single-0 2/2 Running 0 -glance-nfs-single-1 2/2 Running 0 -glance-nfs-single-2 2/2 Running 0 ----- - -* Ensure that the description of the pod reports the following output: -+ ----- -Mounts: -... - nfs: - Type: NFS (an NFS mount that lasts the lifetime of a pod) - Server: {{ server ip address }} - Path: {{ nfs export path }} - ReadOnly: false -... ----- - -* Check that the mountpoint that points to `/var/lib/glance/images` is mapped to the expected `nfs server ip` and `nfs path` that you defined in the new default `GlanceAPI` instance: -+ ----- -$ oc rsh -c glance-api glance-default-single-0 - -sh-5.1# mount -... -... -{{ ip address }}:/var/nfs on /var/lib/glance/images type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=172.18.0.5,local_lock=none,addr=172.18.0.5) -... -... ----- - -* Confirm that the UUID is created in the exported directory on the NFS node. For example: -+ ----- -$ oc rsh openstackclient -$ openstack image list - -sh-5.1$ curl -L -o /tmp/cirros-0.6.3-x86_64-disk.img http://download.cirros-cloud.net/0.6.3/cirros-0.6.3-x86_64-disk.img -... -... - -sh-5.1$ openstack image create --container-format bare --disk-format raw --file /tmp/cirros-0.6.3-x86_64-disk.img cirros -... -... - -sh-5.1$ openstack image list -+--------------------------------------+--------+--------+ -| ID | Name | Status | -+--------------------------------------+--------+--------+ -| 634482ca-4002-4a6d-b1d5-64502ad02630 | cirros | active | -+--------------------------------------+--------+--------+ ----- - -* On the `nfs-server` node, the same `uuid` is in the exported `/var/nfs`: -+ ----- -$ ls /var/nfs/ -634482ca-4002-4a6d-b1d5-64502ad02630 ----- diff --git a/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc b/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc deleted file mode 100644 index 53a141d1a..000000000 --- a/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc +++ /dev/null @@ -1,97 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="adopting-image-service-with-object-storage-backend_{context}"] - -= Adopting the {image_service} that is deployed with a {object_storage} back end - -[role="_abstract"] -Adopt the {image_service_first_ref} with an {object_storage_first_ref} back end by using the following configuration from the control plane `glanceAPI` instance. Use this configuration in the patch manifest that deploys the {image_service} with the object storage back end. - ----- -.. -spec - glance: - ... - customServiceConfig: | - [DEFAULT] - enabled_backends = default_backend:swift - [glance_store] - default_backend = default_backend - [default_backend] - swift_store_create_container_on_put = True - swift_store_auth_version = 3 - swift_store_auth_address = {{ .KeystoneInternalURL }} - swift_store_endpoint_type = internalURL - swift_store_user = service:glance - swift_store_key = {{ .ServicePassword }} ----- - -.Prerequisites - -* You have completed the previous adoption steps. - -.Procedure - -. Create a new file, for example, `glance_swift.patch`, and include the following content: -+ -[subs="+quotes"] ----- -spec: - glance: - enabled: true - apiOverride: - route: {} - template: - secret: osp-secret - databaseInstance: openstack - storage: - storageRequest: 10G - customServiceConfig: | - [DEFAULT] - enabled_backends = default_backend:swift - [glance_store] - default_backend = default_backend - [default_backend] - swift_store_create_container_on_put = True - swift_store_auth_version = 3 - swift_store_auth_address = {{ .KeystoneInternalURL }} - swift_store_endpoint_type = internalURL - swift_store_user = service:glance - swift_store_key = {{ .ServicePassword }} - glanceAPIs: - default: - replicas: 1 - override: - service: - internal: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/allow-shared-ip: internalapi - metallb.universe.tf/loadBalancerIPs: *<172.17.0.80>* - spec: - type: LoadBalancer - networkAttachments: - - storage ----- -+ -where: - -<172.17.0.80>:: -Specifies the load balancer IP in your environment. If you use IPv6, change the load balancer IP to the load balancer IP in your environment, for example, `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80`. -+ -[NOTE] -The {object_storage} as a back end establishes a dependency with the {image_service}. Any deployed `GlanceAPI` instances do not work if the {image_service} is configured with the {object_storage} that is not available in the `OpenStackControlPlane` custom resource. -After the {object_storage}, and in particular `SwiftProxy`, is adopted, you can proceed with the `GlanceAPI` adoption. For more information, see xref:adopting-the-object-storage-service_adopt-control-plane[Adopting the Object Storage service]. - -. Verify that `SwiftProxy` is available: -+ ----- -$ oc get pod -l component=swift-proxy | grep Running -swift-proxy-75cb47f65-92rxq 3/3 Running 0 ----- - -. Patch the `GlanceAPI` service that is deployed in the control plane: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch-file=glance_swift.patch ----- diff --git a/docs_user/modules/proc_adopting-key-manager-service-with-hsm-integration.adoc b/docs_user/modules/proc_adopting-key-manager-service-with-hsm-integration.adoc deleted file mode 100644 index 0f803c499..000000000 --- a/docs_user/modules/proc_adopting-key-manager-service-with-hsm-integration.adoc +++ /dev/null @@ -1,181 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="adopting-key-manager-service-with-hsm-integration_{context}"] - -= Adopting the {key_manager} with HSM integration - -[role="_abstract"] -When your source {OpenStackPreviousInstaller} environment includes hardware security module (HSM) integration, you must use the HSM-enabled adoption approach to preserve HSM functionality and maintain access to HSM-backed secrets. - -.Prerequisites - -* The source {OpenStackPreviousInstaller} environment with HSM integration is configured. -* HSM client software and certificates are available from accessible URLs. -* The target {rhos_long} environment with HSM infrastructure is accessible. -* HSM-enabled {key_manager_first_ref} container images are built and available in your registry. - -.Procedure - -. Confirm that your source environment configuration includes HSM integration: -+ -[source,bash] ----- -$ ssh tripleo-admin@controller-0.ctlplane \ - "sudo cat /var/lib/config-data/puppet-generated/barbican/etc/barbican/barbican.conf | grep -A5 '\[.*plugin\]'" ----- -+ -If you see `[p11_crypto_plugin]` or other HSM-specific sections, continue with the HSM adoption. - -. Extract the simple crypto key encryption keys (KEK) from your source environment: -+ -[source,bash] ----- -$ SIMPLE_CRYPTO_KEK=$(ssh tripleo-admin@controller-0.ctlplane \ - "sudo python3 -c \"import configparser; c = configparser.ConfigParser(); c.read('/var/lib/config-data/puppet-generated/barbican/etc/barbican/barbican.conf'); print(c['simple_crypto_plugin']['kek'])\"") ----- - -. Add the KEK to the target environment: -+ -[source,bash] ----- -$ oc set data secret/osp-secret "BarbicanSimpleCryptoKEK=${SIMPLE_CRYPTO_KEK}" ----- - -. Create HSM-specific secrets in the {rhos_acro} target environment: -+ -[source,bash] ----- -# Create HSM login credentials secret -$ oc create secret generic hsm-login \ - --from-literal=PKCS11Pin= \ - -n openstack - -# Create HSM client configuration and certificates secret -$ oc create secret generic proteccio-data \ - --from-file=client.crt= \ - --from-file=client.key= \ - --from-file=10_8_60_93.CRT= \ - --from-file=proteccio.rc= \ - -n openstack ----- -+ -where: - - -:: -Specifies the HSM password for your {rhos_acro} environment. -:: -Specifies the path to the HSM client certificate. -:: -Specifies the path to the client key. -:: -Specifies the path to the server certificate. -:: -Specifies the path to your HSM configuration in your {rhos_acro} environment. - -. Patch the `OpenStackControlPlane` custom resource to deploy {key_manager} with HSM support: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch ' -spec: - barbican: - enabled: true - apiOverride: - route: {} - template: - databaseInstance: openstack - databaseAccount: barbican - rabbitMqClusterName: rabbitmq - secret: osp-secret - simpleCryptoBackendSecret: osp-secret - serviceAccount: barbican - serviceUser: barbican - passwordSelectors: - database: BarbicanDatabasePassword - service: BarbicanPassword - simplecryptokek: BarbicanSimpleCryptoKEK - customServiceConfig: | - [p11_crypto_plugin] - plugin_name = PKCS11 - library_path = /usr/lib64/libnethsm.so - token_labels = VHSM1 - mkek_label = adoption_mkek_1 - hmac_label = adoption_hmac_1 - encryption_mechanism = CKM_AES_CBC - hmac_key_type = CKK_GENERIC_SECRET - hmac_keygen_mechanism = CKM_GENERIC_SECRET_KEY_GEN - hmac_mechanism = CKM_SHA256_HMAC - key_wrap_mechanism = CKM_AES_CBC_PAD - key_wrap_generate_iv = true - always_set_cka_sensitive = true - os_locking_ok = false - globalDefaultSecretStore: pkcs11 - enabledSecretStores: ["simple_crypto", "pkcs11"] - pkcs11: - loginSecret: hsm-login - clientDataSecret: proteccio-data - clientDataPath: /etc/proteccio - barbicanAPI: - replicas: 1 - override: - service: - internal: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/allow-shared-ip: internalapi - metallb.universe.tf/loadBalancerIPs: 172.17.0.80 - spec: - type: LoadBalancer - barbicanWorker: - replicas: 1 - barbicanKeystoneListener: - replicas: 1 -' ----- -+ -* `library_path` specifies the path to the PKCS#11 library, for example, `/usr/lib64/libnethsm.so` for Proteccio). -* `token_labels` specifies the HSM partition name, for example, `VHSM1`. -* `mkek_label` and `hmac_label` specify key labels that are configured in the HSM. -* `loginSecret` specifies the name of the Kubernetes secret that contains the HSM PIN. -* `clientDataSecret` specifies the name of the Kubernetes secret that contains the HSM certificates and configuration. - -.Verification - -. Verify that both secret stores are available: -+ -[source,bash] ----- -$ openstack secret store list ----- - -. Test the HSM back-end functionality: -+ -[source,bash] ----- -$ openstack secret store --name "hsm-test-$(date +%s)" \ - --payload "test-payload" \ - --algorithm aes --mode cbc --bit-length 256 ----- - -. Verify that the migrated secrets are accessible: -+ -[source,bash] ----- -$ openstack secret list ----- - -. Check that the {key_manager} services are operational: -+ -[source,bash] ----- -$ oc get pods -l service=barbican -NAME READY STATUS RESTARTS AGE -barbican-api-5d65949b4-xhkd7 2/2 Running 7 (10m ago) 29d -barbican-keystone-listener-687cbdc77d-4kjnk 2/2 Running 3 (11m ago) 29d -barbican-worker-5c4b947d5c-l9jdh 2/2 Running 3 (11m ago) 29d ----- - -[NOTE] -==== -HSM adoption preserves both simple crypto and HSM-backed secrets. The migration process maintains HSM metadata and secret references, ensuring continued access to existing secrets while enabling new secrets to use either back-end. -==== diff --git a/docs_user/modules/proc_adopting-key-manager-service-with-proteccio-hsm.adoc b/docs_user/modules/proc_adopting-key-manager-service-with-proteccio-hsm.adoc deleted file mode 100644 index da5b3ccec..000000000 --- a/docs_user/modules/proc_adopting-key-manager-service-with-proteccio-hsm.adoc +++ /dev/null @@ -1,221 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="adopting-the-key-manager-service-with-proteccio-hsm_{context}"] - -= Adopting the {key_manager} with Proteccio HSM integration - -[role="_abstract"] -Adopt the {key_manager_first_ref} with Proteccio HSM by patching the `OpenStackControlPlane` custom resource (CR) where {key_manager} is disabled. Configure the {key_manager} to use both the `simple_crypto` and `pkcs11` back ends. - -The patch starts the service with the configuration parameters from the {rhos_prev_long} ({OpenStackShort}) environment and preserves access to existing HSM-backed secrets. - -The {key_manager} Proteccio HSM adoption is complete if you see the following results: - -* The `BarbicanAPI`, `BarbicanWorker`, and `BarbicanKeystoneListener` services are up and running with HSM-enabled configuration. -* All secrets from the source {OpenStackShort} {rhos_prev_ver} environment are available in {rhos_long} {rhos_curr_ver}. -* The PKCS11 crypto plugin is available alongside `simple_crypto` for new secret storage. -* HSM functionality is verified and operational. - -[NOTE] -If your environment does not include Proteccio HSM, to adopt the {key_manager} by using `simple_crypto` only, see xref:adopting-the-key-manager-service_adopt-control-plane[Adopting the {key_manager}]. - -.Prerequisites - -* You have a running {OpenStackPreviousInstaller} environment with Proteccio HSM integration (the source cloud). -* You have a Single Node OpenShift or OpenShift Local running in the {rhocp_long} cluster. -* You have SSH access to the source {OpenStackPreviousInstaller} undercloud and Controller nodes. -* Custom {key_manager} container images with the Proteccio client libraries are built and available in your container registry. For more information, see the `rhoso_proteccio_hsm` Ansible role documentation. -* The Proteccio client certificate, client key, server certificate, and `proteccio.rc` configuration file for the target environment are available on the host where you run the adoption commands. - -[IMPORTANT] -==== -Without proper HSM configuration, your HSM-protected secrets become inaccessible after adoption. Ensure the following before you begin: - -* The HSM partition name, MKEK label, and HMAC label match the values configured in your source environment ({OpenStackShort}). -* The Proteccio client certificates and configuration files are valid for the target environment ({rhos_acro}). -==== - -.Procedure - -. Confirm that your source environment configuration includes Proteccio HSM integration: -+ -[source,bash] ----- -$ ssh tripleo-admin@controller-0.ctlplane \ - "sudo cat /var/lib/config-data/puppet-generated/barbican/etc/barbican/barbican.conf | grep -A5 '\[p11_crypto_plugin\]'" ----- -+ -If you see the `[p11_crypto_plugin]` section with Proteccio-specific settings, for example `library_path = /usr/lib64/libnethsm.so`, continue with the HSM adoption. If you do not see this section, your source environment does not include Proteccio HSM integration. Use the standard adoption procedure instead. For more information, see xref:adopting-the-key-manager-service_adopt-control-plane[Adopting the {key_manager}]. - -. Add the simple crypto key encryption key (KEK) secret: -+ ----- -$ oc set data secret/osp-secret "BarbicanSimpleCryptoKEK=$($CONTROLLER1_SSH "python3 -c \"import configparser; c = configparser.ConfigParser(); c.read('/var/lib/config-data/puppet-generated/barbican/etc/barbican/barbican.conf'); print(c['simple_crypto_plugin']['kek'])\"")" ----- - -. Create the HSM login credentials secret: -+ -[source,bash] ----- -$ oc create secret generic hsm-login \ - --from-literal=PKCS11Pin= \ - -n openstack ----- -+ -where: - -``:: -Specifies the HSM PKCS#11 PIN for the Proteccio partition in your environment. - -. Create the Proteccio client data secret with the certificates and configuration: -+ -[source,bash] ----- -$ oc create secret generic proteccio-data \ - --from-file=client.crt= \ - --from-file=client.key= \ - --from-file== \ - --from-file=proteccio.rc= \ - -n openstack ----- -+ -where: - -``:: -Specifies the path to the HSM client certificate file. -``:: -Specifies the path to the HSM client key file. -``:: -Specifies the filename of the HSM server certificate that is expected by the Proteccio client, for example, `10_8_60_93.CRT`. -``:: -Specifies the path to the HSM server certificate file. -``:: -Specifies the path to the `proteccio.rc` configuration file for your environment. - -. Patch the `OpenStackControlPlane` CR to deploy the {key_manager} with HSM support: -+ -[subs="+quotes"] ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch ' -spec: - barbican: - enabled: true - apiOverride: - route: {} - template: - databaseInstance: openstack - databaseAccount: barbican - messagingBus: - cluster: rabbitmq - secret: osp-secret - simpleCryptoBackendSecret: osp-secret - serviceAccount: barbican - serviceUser: barbican - passwordSelectors: - database: BarbicanDatabasePassword - service: BarbicanPassword - simplecryptokek: BarbicanSimpleCryptoKEK - customServiceConfig: | - [p11_crypto_plugin] - plugin_name = PKCS11 - library_path = ** - token_labels = ** - mkek_label = ** - hmac_label = ** - encryption_mechanism = CKM_AES_CBC - hmac_key_type = CKK_GENERIC_SECRET - hmac_keygen_mechanism = CKM_GENERIC_SECRET_KEY_GEN - hmac_mechanism = CKM_SHA256_HMAC - key_wrap_mechanism = ** - key_wrap_generate_iv = true - always_set_cka_sensitive = true - os_locking_ok = false - globalDefaultSecretStore: pkcs11 - enabledSecretStores: ["simple_crypto", "pkcs11"] - pkcs11: - loginSecret: hsm-login - clientDataSecret: proteccio-data - clientDataPath: /etc/proteccio - barbicanAPI: - replicas: 1 - override: - service: - internal: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/allow-shared-ip: internalapi - metallb.universe.tf/loadBalancerIPs: *<172.17.0.80>* - spec: - type: LoadBalancer - barbicanWorker: - replicas: 1 - barbicanKeystoneListener: - replicas: 1 -' ----- -+ -where: - -``:: -Specifies the path to the PKCS#11 library inside the container, for example, `/usr/lib64/libnethsm.so` for Proteccio. -``:: -Specifies the HSM partition name, for example, `VHSM1`. This value must match the partition configured in your source environment. -``:: -Specifies the label of the Master Key Encryption Key (MKEK) in the HSM. This value must match the key configured in your source environment. -``:: -Specifies the label of the HMAC key in the HSM. This value must match the key configured in your source environment. -``:: -Specifies the PKCS#11 key wrap mechanism, for example, `CKM_AES_CBC_PAD`. This value must match the mechanism configured in your source environment. -`<172.17.0.80>`:: -Specifies the load balancer IP in your environment. If you use IPv6, change the load balancer IP to the load balancer IP in your environment, for example, `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80`. - -`messagingBus.Cluster`:: -For more information about RHOSO RabbitMQ clusters, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/monitoring_high_availability_services/ref_rhoso-rabbitmq-clusters_ha-monitoring#con_understand-the-rabbitmq-interface-for-openstack-services[RHOSO RabbitMQ clusters] in _Monitoring high availability services_. - -.Verification - -. Ensure that the {identity_service_first_ref} endpoints are defined and are pointing to the control plane FQDNs: -+ ----- -$ openstack endpoint list | grep key-manager ----- - -. Ensure that the Barbican API service is registered in the {identity_service}: -+ ----- -$ openstack service list | grep key-manager ----- - -. Verify that all secrets from the source environment are available: -+ ----- -$ openstack secret list ----- - -. Confirm that the {key_manager} services are running with HSM-enabled configuration: -+ ----- -$ oc get pods -n openstack -l service=barbican -o wide ----- - -. Test secret creation to verify HSM functionality: -+ ----- -$ openstack secret store --name adoption-verification --payload 'HSM adoption successful' ----- - -. Verify that the HSM back end is operational by retrieving the secret: -+ ----- -$ openstack secret get --payload ----- -+ -where: - -``:: -Specifies the ID of the secret created in the previous step. - -[NOTE] -==== -HSM adoption preserves both simple crypto and HSM-backed secrets. The migration process maintains HSM metadata and secret references, ensuring continued access to existing secrets while enabling new secrets to use either back end. -==== diff --git a/docs_user/modules/proc_adopting-key-manager-service.adoc b/docs_user/modules/proc_adopting-key-manager-service.adoc deleted file mode 100644 index 097b78072..000000000 --- a/docs_user/modules/proc_adopting-key-manager-service.adoc +++ /dev/null @@ -1,100 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="adopting-the-key-manager-service_{context}"] - -= Adopting the {key_manager} - -[role="_abstract"] -Adopt the {key_manager_first_ref} by patching the existing `OpenStackControlPlane` custom resource (CR) where {key_manager} is disabled. Configure the {key_manager} to use the `simple_crypto` back end. - -The patch starts the service with the configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) environment. - -The {key_manager} adoption is complete if you see the following results: - -* The `BarbicanAPI`, `BarbicanWorker`, and `BarbicanKeystoneListener` services are up and running. -* Keystone endpoints are updated, and the same crypto plugin of the source cloud is available. - -[NOTE] -To configure hardware security module (HSM) integration with Proteccio HSM, see xref:adopting-the-key-manager-service-with-proteccio-hsm_adopt-control-plane[Adopting the {key_manager} with Proteccio HSM integration]. - -.Procedure - -. Add the kek secret: -+ ----- -$ oc set data secret/osp-secret "BarbicanSimpleCryptoKEK=$($CONTROLLER1_SSH "python3 -c \"import configparser; c = configparser.ConfigParser(); c.read('/var/lib/config-data/puppet-generated/barbican/etc/barbican/barbican.conf'); print(c['simple_crypto_plugin']['kek'])\"")" ----- - -. Patch the `OpenStackControlPlane` CR to deploy the {key_manager}: -+ -[subs="+quotes"] ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch ' -spec: - barbican: - enabled: true - apiOverride: - route: {} - template: - databaseInstance: openstack - databaseAccount: barbican - messagingBus: - cluster: rabbitmq - secret: osp-secret - simpleCryptoBackendSecret: osp-secret - serviceAccount: barbican - serviceUser: barbican - passwordSelectors: - service: BarbicanPassword - simplecryptokek: BarbicanSimpleCryptoKEK - barbicanAPI: - replicas: 1 - override: - service: - internal: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/allow-shared-ip: internalapi - metallb.universe.tf/loadBalancerIPs: *<172.17.0.80>* - spec: - type: LoadBalancer - barbicanWorker: - replicas: 1 - barbicanKeystoneListener: - replicas: 1 -' ----- -+ -where: - -`<172.17.0.80>`:: -Specifies the load balancer IP in your environment. If you use IPv6, change the load balancer IP to the load balancer IP in your environment, for example, `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80`. - -`messagingBus.Cluster`:: -For more information about RHOSO RabbitMQ clusters, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/monitoring_high_availability_services/ref_rhoso-rabbitmq-clusters_ha-monitoring#con_understand-the-rabbitmq-interface-for-openstack-services[RHOSO RabbitMQ clusters] in _Monitoring high availability services_. - -.Verification - -* Ensure that the {identity_service_first_ref} endpoints are defined and are pointing to the control plane FQDNs: -+ ----- -$ openstack endpoint list | grep key-manager ----- - -* Ensure that Barbican API service is registered in the {identity_service}: -+ ----- -$ openstack service list | grep key-manager ----- -+ ----- -$ openstack endpoint list | grep key-manager ----- - -* List the secrets: -+ ----- -$ openstack secret list ----- - -//**TODO: Once different crypto plugins are supported, additional lines test those should be added. diff --git a/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc b/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc deleted file mode 100644 index 11d45bdeb..000000000 --- a/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc +++ /dev/null @@ -1,452 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="adopting-networker-services-to-the-data-plane_{context}"] - -= Adopting Networker services to the {rhos_acro} data plane - -[role="_abstract"] -Adopt Networker services to the {rhos_long} data plane by creating a `OpenStackDataPlaneNodeSet` custom resource (CR) that includes the services to run on the Networker nodes. The Networker services could be running on Controller nodes or dedicated Networker nodes. - -[TIP] -==== -By definition, any node that has set `enable-chassis-as-gw` is considered a _Networker node_. After the adoption process, these nodes continue to be Networker nodes. -==== - -You can implement the following options if they apply to your environment: - -* Depending on your topology, you might need to run the `neutron-metadata` service on the nodes, specifically when you want to serve metadata to SR-IOV ports that are hosted on Compute nodes. - -* If you want to continue running OVN gateway services on Networker nodes, keep `ovn` service in the list to deploy. - -* Optional: You can run the `neutron-dhcp` service on your Networker nodes instead of your Compute nodes. You might not need to use `neutron-dhcp` with OVN, unless your deployment uses DHCP relays, or advanced DHCP options that are supported by dnsmasq but not by the OVN DHCP implementation. - -Adopt each Controller or Networker node in your existing {rhos_prev_long} deployment to the {rhos_long} when your node is set as an OVN chassis gateway. Any node with -parameter set to `enable-chassis-as-gw` is considered OVN gateway chassis. In this case, such nodes will become edpm networker nodes after adoption. - -. Check for the nodes where `OVN Controller Gateway agent` agents are running. The list of agents varies depending on the services you enabled: -+ ----- -$ oc exec openstackclient -- openstack network agent list -+--------------------------------------+------------------------------+--------------------------+-------------------+-------+-------+----------------------------+ -| ID | Agent Type | Host | Availability Zone | Alive | State | Binary | -+--------------------------------------+------------------------------+--------------------------+-------------------+-------+-------+----------------------------+ -| e5075ee0-9dd9-4f0a-a42a-6bbdf1a6111c | OVN Controller Gateway agent | controller-0.localdomain | | XXX | UP | ovn-controller | -| f3112349-054c-403a-b00a-e219238192b8 | OVN Controller agent | compute-0.localdomain | | XXX | UP | ovn-controller | -| af9dae2d-1c1c-55a8-a743-f84719f6406d | OVN Metadata agent | compute-0.localdomain | | XXX | UP | neutron-ovn-metadata-agent | -| 51a11df8-a66e-47a2-aec0-52eb8589626c | OVN Controller Gateway agent | controller-1.localdomain | | XXX | UP | ovn-controller | -| bb817e5e-7832-410a-9e67-934dac8c602f | OVN Controller Gateway agent | controller-2.localdomain | | XXX | UP | ovn-controller | -+--------------------------------------+------------------------------+--------------------------+-------------------+-------+-------+----------------------------+ ----- - -.Prerequisites - -* Define the shell variable. Based on above agent list output, -controller-0, controller-1, controller-2 are our target -hosts. If you have both `Controller` and `Networker` nodes running -networker services then add all those hosts below. -+ -[subs=+quotes] ----- -declare -A networkers -networkers+=( - ["controller-0.localdomain"]="192.168.122.100" - ["controller-1.localdomain"]="192.168.122.101" - ["controller-2.localdomain"]="192.168.122.102" - # ... -) ----- -+ -** Replace `[""]="192.168.122.100"` with the name and IP address of the corresponding Networker or Controller node as per your environment. - -.Procedure - -. Deploy the `OpenStackDataPlaneNodeSet` CR for your nodes: -+ -[NOTE] -You can reuse most of the `nodeTemplate` section from the `OpenStackDataPlaneNodeSet` CR that is designated for your Compute nodes. You can omit some of the variables because of the limited set of services that are running on the Networker nodes. -+ -[subs="+quotes"] ----- -$ oc apply -f - <", state: enabled} - - {name: "", state: enabled} - - {name: "", state: enabled} - - {name: "", state: enabled} - - {name: "", state: enabled} - - {name: "", state: enabled} -endif::[] - edpm_bootstrap_release_version_package: [] - # edpm_network_config - # Default nic config template for a EDPM node - # These vars are edpm_network_config role vars - edpm_network_config_template: | - --- - {% set mtu_list = [ctlplane_mtu] %} - {% for network in nodeset_networks %} - {% set _ = mtu_list.append(lookup('vars', networks_lower[network] ~ '_mtu')) %} - {%- endfor %} - {% set min_viable_mtu = mtu_list | max %} - network_config: - - type: ovs_bridge - name: {{ neutron_physical_bridge_name }} - mtu: {{ min_viable_mtu }} - use_dhcp: false - dns_servers: {{ ctlplane_dns_nameservers }} - domain: {{ dns_search_domains }} - addresses: - - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_cidr }} - routes: {{ ctlplane_host_routes }} - members: - - type: interface - name: nic1 - mtu: {{ min_viable_mtu }} - # force the MAC address of the bridge to this interface - primary: true - {% for network in nodeset_networks %} - - type: vlan - mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }} - vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }} - addresses: - - ip_netmask: - {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }} - routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }} - {% endfor %} - edpm_network_config_nmstate: false - edpm_network_config_hide_sensitive_logs: false - # - # These vars are for the network config templates themselves and are - # considered EDPM network defaults. - neutron_physical_bridge_name: br-ctlplane - neutron_public_interface_name: eth0 - - # edpm_nodes_validation - edpm_nodes_validation_validate_controllers_icmp: false - edpm_nodes_validation_validate_gateway_icmp: false - - # edpm ovn-controller configuration - edpm_ovn_bridge_mappings: [<"bridge_mappings">] - edpm_ovn_bridge: br-int - edpm_ovn_encap_type: geneve - ovn_monitor_all: true - edpm_ovn_remote_probe_interval: 60000 - edpm_ovn_ofctrl_wait_before_clear: 8000 - - # serve as a OVN gateway - edpm_enable_chassis_gw: true - - timesync_ntp_servers: -ifeval::["{build}" != "downstream"] - - hostname: pool.ntp.org -endif::[] -ifeval::["{build}" == "downstream"] - - hostname: clock.redhat.com - - hostname: clock2.redhat.com -endif::[] - -ifeval::["{build}" != "downstream"] - edpm_bootstrap_command: | - # This is a hack to deploy RDO Delorean repos to RHEL as if it were Centos 9 Stream - set -euxo pipefail - curl -sL https://github.com/openstack-k8s-operators/repo-setup/archive/refs/heads/main.tar.gz | tar -xz - python3 -m venv ./venv - PBR_VERSION=0.0.0 ./venv/bin/pip install ./repo-setup-main - # This is required for FIPS enabled until trunk.rdoproject.org - # is not being served from a centos7 host, tracked by - # https://issues.redhat.com/browse/RHOSZUUL-1517 - sudo dnf -y install crypto-policies - sudo update-crypto-policies --set FIPS:NO-ENFORCE-EMS - sudo ./venv/bin/repo-setup current-podified -b antelope -d centos9 --stream - sudo rm -rf repo-setup-main -endif::[] - - gather_facts: false - enable_debug: false - # edpm firewall, change the allowed CIDR if needed - edpm_sshd_configure_firewall: true - edpm_sshd_allowed_ranges: ['192.168.122.0/24'] - # SELinux module - edpm_selinux_mode: enforcing - - # Do not attempt OVS major upgrades here - edpm_ovs_packages: - - openvswitch3.3 -EOF ----- -+ -* `spec.tlsEnabled` specifies whether TLS Everywhere is enabled. If TLS is enabled, change `spec:tlsEnabled` to `true`. -* `edpm_ovn_bridge_mappings`: Replace `[<"bridge_mappings">]` with the bridge mapping values that you used in your {rhos_prev_long} {rhos_prev_ver} deployment, for example, `["datacentre:br-ctlplane"]`. -* `edpm_enable_chassis_gw` specifies whether to run `ovn-controller` in gateway mode. -* ``, ``, ``, ``, ``, `` specifies the name of the repository to enable. For more information about which repositories are required, see link:https://access.redhat.com/articles/7139612[Required repositories for Red Hat OpenStack Services on OpenShift 18.0]. -ifeval::["{build}" != "downstream"] -+ -[IMPORTANT] -==== -For environments that are enabled with border gateway protocol (BGP), preserve the default routes on the data plane nodes. - -When adopting {rhos_prev_long} {rhos_prev_ver} environments with BGP, default routes can be lost when the data plane adoption procedure stops the {rhos_prev_long} services, specifically when FRRouting (FRR) is stopped. This causes connectivity issues during the {rhos_acro} data plane deployment. - -To prevent this, configure the required routes by using `os-net-config` on the data plane nodes (Compute nodes and Networker nodes) affected by this issue. - -Modify your `os-net-config` configuration file by adding the required routes, and then apply it: - ----- -$ sudo os-net-config -c /etc/os-net-config/modified_config_with_routes.yaml --provider ifcfg ----- - -This temporary default route is needed during the installation of the first services (such as `download-cache`) and is removed when the `configure-network` service applies the new network configuration. -==== -+ -[NOTE] -==== -For environments that are enabled with border gateway protocol (BGP), you must add the following services to the `services` list in the order shown: - -* After `configure-network` and before `validate-network`: Add `frr` service for FRRouting BGP support -* After `ovn` and `neutron-metadata` services: Add `ovn-bgp-agent` service - -You must also configure the following additional Ansible variables in the `nodeTemplate.ansible.ansibleVars` section: - -* `edpm_frr_image`: The FRRouting container image -* `edpm_ovn_bgp_agent_image`: The OVN BGP agent container image -* `edpm_frr_bgp_ipv4_src_network`: The network name for BGP IPv4 source (for example, `bgpmainnet`) -* `edpm_frr_bgp_ipv6_src_network`: The network name for BGP IPv6 source (for example, `bgpmainnetv6`) -* `edpm_frr_bgp_neighbor_password`: The BGP neighbor password -* `edpm_ovn_encap_ip`: Set to the BGP main network IP (for example, `{{ lookup("vars", "bgpmainnet_ip") }}`) -==== -endif::[] - -. Ensure that you use the same `ovn-controller` settings in the `OpenStackDataPlaneNodeSet` CR that you used in the Networker nodes before adoption. This configuration is stored in the `external_ids` column in the `Open_vSwitch` table in the Open vSwitch database: -+ ----- -ovs-vsctl list Open . -... -external_ids : {hostname=controller-0.localdomain, ovn-bridge=br-int, ovn-bridge-mappings=, ovn-chassis-mac-mappings="datacentre:1e:0a:bb:e6:7c:ad", ovn-cms-options=enable-chassis-as-gw, ovn-encap-ip="172.19.0.100", ovn-encap-tos="0", ovn-encap-type=geneve, ovn-match-northd-version=False, ovn-monitor-all=True, ovn-ofctrl-wait-before-clear="8000", ovn-openflow-probe-interval="60", ovn-remote="tcp:ovsdbserver-sb.openstack.svc:6642", ovn-remote-probe-interval="60000", rundir="/var/run/openvswitch", system-id="2eec68e6-aa21-4c95-a868-31aeafc11736"} -... ----- -+ -* Replace `` with the value of the bridge mappings in your configuration, for example, `"datacentre:br-ctlplane"`. - -. Optional: Enable `neutron-metadata` in the `OpenStackDataPlaneNodeSet` CR: -+ ----- -$ oc patch openstackdataplanenodeset --type='json' --patch='[ - { - "op": "add", - "path": "/spec/services/-", - "value": "neutron-metadata" - }]' ----- -+ -* Replace `` with the name of the CR that you deployed for your Networker nodes, for example, `openstack-networker`. - -. Optional: Enable `neutron-dhcp` in the `OpenStackDataPlaneNodeSet` CR: -+ ----- -$ oc patch openstackdataplanenodeset --type='json' --patch='[ - { - "op": "add", - "path": "/spec/services/-", - "value": "neutron-dhcp" - }]' ----- - -. Run the `pre-adoption-validation` service for Networker nodes: - -.. Create a `OpenStackDataPlaneDeployment` CR that runs only the validation: -+ ----- -$ oc apply -f - < ----- -* Replace `` with the ID of the agent to delete, for example, `856960f0-5530-46c7-a331-6eadcba362da`. - - -.Verification - -. Confirm that all the Ansible EE pods reach a `Completed` status: -+ ----- -$ watch oc get pod -l app=openstackansibleee ----- -+ ----- -$ oc logs -l app=openstackansibleee -f --max-log-requests 20 ----- - -. Wait for the data plane node set to reach the `Ready` status: -+ ----- -$ oc wait --for condition=Ready osdpns/ --timeout=30m ----- -+ -* Replace `` with the name of the CR that you deployed for your Networker nodes, for example, `openstack-networker`. - -. Verify that the {networking_first_ref} agents are running. The list of agents varies depending on the services you enabled: -+ ----- -$ oc exec openstackclient -- openstack network agent list -+--------------------------------------+------------------------------+--------------------------+-------------------+-------+-------+----------------------------+ -| ID | Agent Type | Host | Availability Zone | Alive | State | Binary | -+--------------------------------------+------------------------------+--------------------------+-------------------+-------+-------+----------------------------+ -| e5075ee0-9dd9-4f0a-a42a-6bbdf1a6111c | OVN Controller Gateway agent | controller-0.localdomain | | :-) | UP | ovn-controller | -| f3112349-054c-403a-b00a-e219238192b8 | OVN Controller agent | compute-0.localdomain | | :-) | UP | ovn-controller | -| af9dae2d-1c1c-55a8-a743-f84719f6406d | OVN Metadata agent | compute-0.localdomain | | :-) | UP | neutron-ovn-metadata-agent | -| 51a11df8-a66e-47a2-aec0-52eb8589626c | OVN Controller Gateway agent | controller-1.localdomain | | :-) | UP | ovn-controller | -| bb817e5e-7832-410a-9e67-934dac8c602f | OVN Controller Gateway agent | controller-2.localdomain | | :-) | UP | ovn-controller | -+--------------------------------------+------------------------------+--------------------------+-------------------+-------+-------+----------------------------+ ----- diff --git a/docs_user/modules/proc_adopting-telemetry-services.adoc b/docs_user/modules/proc_adopting-telemetry-services.adoc deleted file mode 100644 index e8325232f..000000000 --- a/docs_user/modules/proc_adopting-telemetry-services.adoc +++ /dev/null @@ -1,147 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="adopting-telemetry-services_{context}"] - -= Adopting Telemetry services - -[role="_abstract"] -To adopt Telemetry services, you patch an existing `OpenStackControlPlane` custom resource (CR) that has Telemetry services disabled to start the service with the configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) {rhos_prev_ver} environment. - -If you adopt Telemetry services, the observability solution that is used in the {OpenStackShort} {rhos_prev_ver} environment, Service Telemetry Framework, is removed from the cluster. The new solution is deployed in the {rhos_long} environment, allowing for metrics, and optionally logs, to be retrieved and stored in the new back ends. - -You cannot automatically migrate old data because different back ends are used. Metrics and logs are considered short-lived data and are not intended to be migrated to the {rhos_acro} environment. For information about adopting legacy autoscaling stack templates to the {rhos_acro} environment, see xref:adopting-autoscaling_adopt-control-plane[Adopting Autoscaling services]. - -.Prerequisites - -* The {OpenStackPreviousInstaller} environment is running (the source cloud). -* The Single Node OpenShift or OpenShift Local is running in the {rhocp_long} cluster. -* Previous adoption steps are completed. - -.Procedure - -. Patch the `OpenStackControlPlane` CR to deploy `cluster-observability-operator`: -+ ----- -$ oc create -f - < cinder.conf ----- - -.Procedure - -. Create a new file, for example, `cinder_api.patch`, and apply the configuration: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch-file= ----- -+ -* Replace `` with the name of your patch file. -+ -The following example shows a `cinder_api.patch` file: -+ -[subs="+quotes"] ----- -spec: - extraMounts: - - extraVol: - - extraVolType: Ceph - mounts: - - mountPath: /etc/ceph - name: ceph - readOnly: true - propagation: - - CinderVolume - - CinderBackup - - Glance - volumes: - - name: ceph - projected: - sources: - - secret: - name: ceph-conf-files - cinder: - enabled: true - apiOverride: - route: {} - template: - databaseInstance: openstack - databaseAccount: cinder - secret: osp-secret - cinderAPI: - override: - service: - internal: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/allow-shared-ip: internalapi - metallb.universe.tf/loadBalancerIPs: *<172.17.0.80>* - spec: - type: LoadBalancer - replicas: 1 - customServiceConfig: | - [DEFAULT] - default_volume_type=tripleo - cinderScheduler: - replicas: 0 - cinderBackup: - networkAttachments: - - storage - replicas: 0 - cinderVolumes: - ceph: - networkAttachments: - - storage - replicas: 0 ----- -+ -where: - -<172.17.0.80>:: -Specifies the load balancer IP in your environment. If you use IPv6, change the load balancer IP to the load balancer IP in your environment, for example, `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80`. - -. Retrieve the list of the previous scheduler and backup services: -+ ----- -$ openstack volume service list - -+------------------+------------------------+------+---------+-------+----------------------------+ -| Binary | Host | Zone | Status | State | Updated At | -+------------------+------------------------+------+---------+-------+----------------------------+ -| cinder-scheduler | standalone.localdomain | nova | enabled | down | 2024-11-04T17:47:14.000000 | -| cinder-backup | standalone.localdomain | nova | enabled | down | 2024-11-04T17:47:14.000000 | -| cinder-volume | hostgroup@tripleo_ceph | nova | enabled | down | 2024-11-04T17:47:14.000000 | -+------------------+------------------------+------+---------+-------+----------------------------+ ----- - -. Remove services for hosts that are in the `down` state: -+ ----- -$ oc exec -t cinder-api-0 -c cinder-api -- cinder-manage service remove ----- -+ -* Replace `` with the name of the binary, for example, `cinder-backup`. -* Replace `` with the host name, for example, `cinder-backup-0`. -+ - -. Deploy the scheduler, backup, and volume services: -+ -* Create another file, for example, `cinder_services.patch`, and apply the configuration: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch-file= ----- -+ -* Replace `` with the name of your patch file. -+ -* The following example shows a `cinder_services.patch` file for a Ceph RBD deployment: -+ -[source,yaml] ----- -spec: - cinder: - enabled: true - template: - cinderScheduler: - replicas: 1 - cinderBackup: - networkAttachments: - - storage - replicas: 1 - customServiceConfig: | - [DEFAULT] - backup_driver=cinder.backup.drivers.ceph.CephBackupDriver - backup_ceph_conf=/etc/ceph/ceph.conf - backup_ceph_user=openstack - backup_ceph_pool=backups - cinderVolumes: - ceph: - networkAttachments: - - storage - replicas: 1 - customServiceConfig: | - [tripleo_ceph] - backend_host=hostgroup - volume_backend_name=tripleo_ceph - volume_driver=cinder.volume.drivers.rbd.RBDDriver - rbd_ceph_conf=/etc/ceph/ceph.conf - rbd_user=openstack - rbd_pool=volumes - rbd_flatten_volume_from_snapshot=False - report_discard_supported=True ----- -+ -[NOTE] -==== -Ensure that you use the same configuration group name for the driver that you used in the source cluster. In this example, the driver configuration group in `customServiceConfig` is called `tripleo_ceph` because it reflects the value of the configuration group name in the `cinder.conf` file of the source OpenStack cluster. -==== -+ -. Configure the NetApp NFS Block Storage volume service: -.. Create a secret that includes sensitive information such as hostnames, passwords, and usernames to access the third-party NetApp NFS storage. You can find the credentials in the `cinder.conf` file that was generated from the {OpenStackPreviousInstaller} deployment: -+ ----- -$ oc apply -f - < ----- -+ -* Replace `` with the name of the patch file for your NetApp NFS Block Storage volume back end. -+ -The following example shows a `cinder_netappNFS.patch` file that configures a NetApp NFS Block Storage volume service: -+ -[source,yaml] ----- -spec: - cinder: - enabled: true - template: - cinderVolumes: - ontap-nfs: - networkAttachments: - - storage - customServiceConfig: | - [tripleo_netapp] - volume_backend_name=ontap-nfs - volume_driver=cinder.volume.drivers.netapp.common.NetAppDriver - nfs_snapshot_support=true - nas_secure_file_operations=false - nas_secure_file_permissions=false - netapp_server_hostname= netapp_backendip - netapp_server_port=80 - netapp_storage_protocol=nfs - netapp_storage_family=ontap_cluster - customServiceConfigSecrets: - - cinder-volume-ontap-secrets ----- -+ -. Configure the NetApp iSCSI Block Storage volume service: -.. Create a secret that includes sensitive information such as hostnames, passwords, and usernames to access the third-party NetApp iSCSI storage. You can find the credentials in the `cinder.conf` file that was generated from the {OpenStackPreviousInstaller} deployment: -+ ----- -$ oc apply -f - < ----- -+ -* Replace `` with the name of the patch file for your NetApp iSCSI Block Storage volume back end. -+ -The following example shows a `cinder_netappISCSI.patch` file that configures a NetApp iSCSI Block Storage volume service: -+ ----- -spec: - cinder: - enabled: true - template: - cinderVolumes: - ontap-iscsi: - networkAttachments: - - storage - customServiceConfig: | - [tripleo_netapp] - volume_backend_name=ontap-iscsi - volume_driver=cinder.volume.drivers.netapp.common.NetAppDriver - netapp_storage_protocol=iscsi - netapp_storage_family=ontap_cluster - consistencygroup_support=True - customServiceConfigSecrets: - - cinder-volume-ontap-secrets ----- -. Check if all the services are up and running: -+ ----- -$ openstack volume service list - -+------------------+--------------------------+------+---------+-------+----------------------------+ -| Binary | Host | Zone | Status | State | Updated At | -+------------------+--------------------------+------+---------+-------+----------------------------+ -| cinder-volume | hostgroup@tripleo_netapp | nova | enabled | up | 2023-06-28T17:00:03.000000 | -| cinder-scheduler | cinder-scheduler-0 | nova | enabled | up | 2023-06-28T17:00:02.000000 | -| cinder-backup | cinder-backup-0 | nova | enabled | up | 2023-06-28T17:00:01.000000 | -+------------------+--------------------------+------+---------+-------+----------------------------+ ----- - -. Apply the DB data migrations: -+ -[NOTE] -==== -You are not required to run the data migrations at this step, but you must run them before the next upgrade. However, for adoption, you can run the migrations now to ensure that there are no issues before you run production workloads on the deployment. -==== -+ ----- -$ oc exec -it cinder-scheduler-0 -- cinder-manage db online_data_migrations ----- - -.Verification - -. Ensure that the `openstack` alias is defined: -+ ----- -$ alias openstack="oc exec -t openstackclient -- openstack" ----- - -. Confirm that {block_storage} endpoints are defined and pointing to the control plane FQDNs: -+ ----- -$ openstack endpoint list --service ----- -+ -* Replace `` with the name of the endpoint that you want to confirm. - -. Confirm that the Block Storage services are running: -+ ----- -$ openstack volume service list ----- -+ -[NOTE] -Cinder API services do not appear in the list. However, if you get a response from the `openstack volume service list` command, that means at least one of the cinder API services is running. - -. Confirm that you have your previous volume types, volumes, snapshots, and backups: -+ ----- -$ openstack volume type list -$ openstack volume list -$ openstack volume snapshot list -$ openstack volume backup list ----- - -. To confirm that the configuration is working, perform the following steps: - -.. Create a volume from an image to check that the connection to {image_service_first_ref} is working: -+ ----- -$ openstack volume create --image cirros --bootable --size 1 disk_new ----- - -.. If you deployed and adopted the `cinder-backup` service, back up the previously attached volume: -+ ----- -$ openstack volume backup create --name ----- -+ -where: - -``:: Specifies the volume that you want to back up. -Replace `` with the volume you want to back up. -``:: Specifies the name of your new backup. -Replace `` with the name of your new backup. -+ -[NOTE] -You do not boot a {compute_service_first_ref} instance by using the new `volume from` image or try to detach the previous volume because the {compute_service} and the {block_storage} are still not connected. - -.Additional resources - -* xref:adopting-block-storage-service-with-dcn-backend_{context}[Adopting the {block_storage} with multiple {Ceph} back ends (DCN)] diff --git a/docs_user/modules/proc_adopting-the-compute-service.adoc b/docs_user/modules/proc_adopting-the-compute-service.adoc deleted file mode 100644 index fc92c24bc..000000000 --- a/docs_user/modules/proc_adopting-the-compute-service.adoc +++ /dev/null @@ -1,202 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="adopting-the-compute-service_{context}"] - -= Adopting the {compute_service} - -[role="_abstract"] -Adopt the {compute_service_first_ref} by patching the existing `OpenStackControlPlane` custom resource (CR) where the {compute_service} is disabled. The patch starts the service with the configuration parameters from {rhos_prev_long}. This procedure describes a single-cell setup. - -//[NOTE] -//The following example scenario describes a single-cell setup. Real -//multi-stack topology that is recommended for production use results in cells having a different database layout, and should use different naming schemes. kgilliga: We might reinstate this note after multi-cell is finished in Feature Release 1. - -.Prerequisites - -* You have completed the previous adoption steps. -* You have defined the following shell variables. Replace the following example values with the values that are correct for your environment: -+ ----- -alias openstack="oc exec -t openstackclient -- openstack" - -DEFAULT_CELL_NAME="cell3" -RENAMED_CELLS="cell1 cell2 $DEFAULT_CELL_NAME" ----- -+ -** The source cloud `default` cell takes a new `$DEFAULT_CELL_NAME`. In a multi-cell adoption scenario, the 'default' cell might retain its original name,`DEFAULT_CELL_NAME=default`, or become renamed as a cell that is free for use. Do not use other existing cell names for `DEFAULT_CELL_NAME`, except for `default`. -** If you deployed the source cloud with a `default` cell, and want to rename it during adoption, define the new name that you want to use, as shown in the following example: -+ ----- -DEFAULT_CELL_NAME="cell1" -RENAMED_CELLS="cell1" ----- - -.Procedure - -. Patch the `OpenStackControlPlane` CR to deploy the {compute_service}: -+ -[NOTE] -This procedure assumes that {compute_service} metadata is deployed on the top level and not on each cell level. If the {OpenStackShort} deployment has a per-cell metadata deployment, adjust the following patch as needed. You cannot run the metadata service in `cell0`. -To enable the metadata services of a local cell, set the `enabled` property in the `metadataServiceTemplate` field of the local cell to `true` in the `OpenStackControlPlane` CR. -+ -[subs="+quotes"] ----- -$ rm -f celltemplates -$ for CELL in $(echo $RENAMED_CELLS); do -> cat >> celltemplates << EOF -> ${CELL}: -> *hasAPIAccess: true* -> cellDatabaseAccount: nova-$CELL -> *cellDatabaseInstance: openstack-$CELL* -> *cellMessageBusInstance: rabbitmq-$CELL* -> metadataServiceTemplate: -> enabled: false -> override: -> service: -> metadata: -> annotations: -> metallb.universe.tf/address-pool: internalapi -> metallb.universe.tf/allow-shared-ip: internalapi -> metallb.universe.tf/loadBalancerIPs: 172.17.0.$(( 79 + ${CELL##*cell} )) -> spec: -> type: LoadBalancer -> customServiceConfig: | -> [workarounds] -> disable_compute_service_check_for_ffu=true -> conductorServiceTemplate: -> customServiceConfig: | -> [workarounds] -> disable_compute_service_check_for_ffu=true ->EOF ->done - -$ cat > oscp-patch.yaml << EOF ->spec: -> nova: -> enabled: true -> apiOverride: -> route: {} -> template: -> secret: osp-secret -> apiDatabaseAccount: nova-api -> apiServiceTemplate: -> override: -> service: -> internal: -> metadata: -> annotations: -> metallb.universe.tf/address-pool: internalapi -> metallb.universe.tf/allow-shared-ip: internalapi -> metallb.universe.tf/loadBalancerIPs: <172.17.0.80> -> spec: -> type: LoadBalancer -> customServiceConfig: | -> [workarounds] -> disable_compute_service_check_for_ffu=true -> metadataServiceTemplate: -> enabled: true -> override: -> service: -> metadata: -> annotations: -> metallb.universe.tf/address-pool: internalapi -> metallb.universe.tf/allow-shared-ip: internalapi -> metallb.universe.tf/loadBalancerIPs: <172.17.0.80> -> spec: -> type: LoadBalancer -> customServiceConfig: | -> [workarounds] -> disable_compute_service_check_for_ffu=true -> schedulerServiceTemplate: -> customServiceConfig: | -> [workarounds] -> disable_compute_service_check_for_ffu=true -> cellTemplates: -> cell0: -> hasAPIAccess: true -> cellDatabaseAccount: nova-cell0 -> cellDatabaseInstance: openstack -> cellMessageBusInstance: rabbitmq -> conductorServiceTemplate: -> customServiceConfig: | -> [workarounds] -> disable_compute_service_check_for_ffu=true ->EOF -$ cat celltemplates >> oscp-patch.yaml -$ oc patch openstackcontrolplane openstack --type=merge --patch-file=oscp-patch.yaml ----- -+ -* `${CELL}.hasAPIAccess` specifies upcall access to the API. In the source cloud, cells are always configured with the main Nova API database upcall access. You can disable upcall access to the API by setting `hasAPIAccess` to `false`. However, do not make changes to the API during adoption. -* `${CELL}.cellDatabaseInstance` specifies the database instance that is used by the cell. The database instance names must match the names that are defined in the `OpenStackControlPlane` CR that you created in when you deployed the back-end services as described in xref:deploying-backend-services__migrating-databases[Deploying back-end services]. -* `${CELL}.cellMessageBusInstance` specifies the message bus instance that is used by the cell. The message bus instance names must match the names that are defined in the `OpenStackControlPlane` CR. -* `metallb.universe.tf/loadBalancerIPs: <172.17.0.80>` specifies the load balancer IP in your environment. If you use IPv6, change the load balancer IP to the load balancer IP in your environment, for example, `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80`. - -. If you are adopting the {compute_service} with the {bare_metal_first_ref}, append the `novaComputeTemplates` field with the following content in each cell in the {compute_service} CR patch. For example: -+ -[source,yaml] ----- - cell1: - novaComputeTemplates: - standalone: - customServiceConfig: | - [DEFAULT] - host = - [workarounds] - disable_compute_service_check_for_ffu=true - computeDriver: ironic.IronicDriver - ... ----- -+ -* Replace `` with the hostname of the node that is running the `ironic` Compute driver in the source cloud. - -. Wait for the CRs for the Compute control plane services to be ready: -+ ----- -$ oc wait --for condition=Ready --timeout=300s Nova/nova ----- -+ -[NOTE] -The local Conductor services are started for each cell, while the superconductor runs in `cell0`. -Note that `disable_compute_service_check_for_ffu` is mandatory for all imported Compute services until the external data plane is imported, and until the Compute services are fast-forward upgraded. For more information, see xref:adopting-compute-services-to-the-data-plane_data-plane[Adopting Compute services to the {rhos_acro} data plane] and xref:performing-a-fast-forward-upgrade-on-compute-services_data-plane[Upgrading Compute services]. - -.Verification - -* Check that {compute_service} endpoints are defined and pointing to the -control plane FQDNs, and that the Nova API responds: -+ ----- -$ openstack endpoint list | grep nova -$ openstack server list ----- -+ -** Compare the outputs with the topology-specific configuration in xref:proc_retrieving-topology-specific-service-configuration_migrating-databases[Retrieving topology-specific service configuration]. - -* Query the superconductor to check that the expected cells exist, and compare it to its pre-adoption values: -+ ----- -for CELL in $(echo $CELLS); do -set +u -. ~/.source_cloud_exported_variables_$CELL -set -u -RCELL=$CELL -[ "$CELL" = "default" ] && RCELL=$DEFAULT_CELL_NAME - -echo "comparing $CELL to $RCELL" -echo $PULL_OPENSTACK_CONFIGURATION_NOVAMANAGE_CELL_MAPPINGS | grep -F "| $CELL |" -oc rsh nova-cell0-conductor-0 nova-manage cell_v2 list_cells | grep -F "| $RCELL |" -done ----- -+ -The following changes are expected for each cell: -+ -** The `cellX` `nova` database and username become `nova_cellX`. -** The `default` cell is renamed to `DEFAULT_CELL_NAME`. The `default` cell might retain the original name if there are multiple cells. -** The RabbitMQ transport URL no longer uses `guest`. - -[NOTE] -==== -At this point, the {compute_service} control plane services do not control the existing {compute_service} workloads. The control plane manages the data plane only after the data adoption process is completed. For more information, see xref:adopting-compute-services-to-the-data-plane_data-plane[Adopting Compute services to the {rhos_acro} data plane]. -==== - -[IMPORTANT] -To import external Compute services to the {rhos_acro} data plane, you must upgrade them first. -For more information, see xref:adopting-compute-services-to-the-data-plane_data-plane[Adopting Compute services to the {rhos_acro} data plane], and xref:performing-a-fast-forward-upgrade-on-compute-services_data-plane[Performing a fast-forward upgrade on Compute services]. diff --git a/docs_user/modules/proc_adopting-the-dns-service.adoc b/docs_user/modules/proc_adopting-the-dns-service.adoc deleted file mode 100644 index bea047bd3..000000000 --- a/docs_user/modules/proc_adopting-the-dns-service.adoc +++ /dev/null @@ -1,322 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="adopting-the-dns-service_{context}"] - -= Adopting the {dns_service} - -[role="_abstract"] -To adopt the {dns_first_ref}, you patch an existing `OpenStackControlPlane` custom resource (CR) where the {dns_service} is disabled. The patch starts the service with the configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) environment. - -.Procedure - -. Create an alias for the `openstack` command: -+ ----- -$ alias openstack="oc exec -t openstackclient -- openstack" ----- - -. To isolate the {dns_service} networks, add the network interfaces for the VLAN base interfaces: -+ -[subs="+quotes"] ----- -$ oc get --no-headers nncp --output=custom-columns='NAME:.metadata.name' | while read; do - -interfaces=$(oc get nncp $REPLY -o jsonpath="{.spec.desiredState.interfaces[*].name}") - -(echo $interfaces | grep -w -q "enp6s0.25\|enp6s0.26") || \ - oc patch nncp $REPLY --type json --patch ' -[{ - "op": "add", - "path": "/spec/desiredState/interfaces/-", - "value": { - "description": "Designate vlan interface", - "name": "enp6s0.25", - "state": "up", - "type": "vlan", - "vlan": { - "base-iface": "", - "id": 25, - "reorder-headers": true - }, - "ipv4": { - "address": [{"ip": "172.28.0.5", "prefix-length": 24}], - "enabled": true, - "dhcp": false - }, - "ipv6": { - "enabled": false - } - } -}, -{ - "op": "add", - "path": "/spec/desiredState/interfaces/-", - "value": { - "description": "Designate external vlan interface", - "name": "enp6s0.26", - "state": "up", - "type": "vlan", - "vlan": { - "base-iface": "", - "id": 26, - "reorder-headers": true - }, - "ipv4": { - "address": [{"ip": "172.50.0.5", "prefix-length": 24}], - "enabled": true, - "dhcp": false - }, - "ipv6": { - "enabled": false - } - } -}]' - -done ----- -+ -where: - -``:: -Specifies the name of the network interface in your {rhocp_long} setup. - -. Configure the {dns_service} internal network attachment definition: -+ ----- -$ cat >> designate-nad.yaml << EOF_CAT -apiVersion: k8s.cni.cncf.io/v1 -kind: NetworkAttachmentDefinition -metadata: - labels: - osp/net: designate - name: designate -spec: - config: | - { - "cniVersion": "0.3.1", - "name": "designate", - "type": "macvlan", - "master": "enp6s0.25", - "ipam": { - "type": "whereabouts", - "range": "172.28.0.0/24", - "range_start": "172.28.0.30", - "range_end": "172.28.0.70" - } - } -EOF_CAT ----- -. Apply the configuration: -+ ----- -$ oc apply -f designate-nad.yaml ----- -. Configure the {dns_service} external network attachment definition: -+ ----- -$ cat >> designateext-nad.yaml << EOF_CAT -apiVersion: k8s.cni.cncf.io/v1 -kind: NetworkAttachmentDefinition -metadata: - labels: - osp/net: designateext - name: designateext -spec: - config: | - { - "cniVersion": "0.3.1", - "name": "designateext", - "type": "macvlan", - "master": "enp6s0.26", - "ipam": { - "type": "whereabouts", - "range": "172.50.0.0/24", - "range_start": "172.50.0.30", - "range_end": "172.50.0.70" - } - } -EOF_CAT ----- - -. Apply the configuration: -+ ----- -$ oc apply -f designateext-nad.yaml ----- - -. Create a MetalLB IPAddressPool for the {dns_service} external network: -+ ----- -$ oc apply -f - < /tmp/designate_ns_records_raw.txt ----- - -. Parse the nameserver records into YAML format for the {dns_service} CR: -+ ----- -$ raw=/tmp/designate_ns_records_raw.txt -$ out=/tmp/designate_ns_records.yaml -$ if [ ! -s "$raw" ]; then - echo "[]" > "$out" -else - awk '{ gsub(/\.$/, "", $1); if (NF >= 2) printf "- hostname: %s.\n priority: %s\n", $1, $2 }' "$raw" > "$out" -fi ----- - -. Enable the {dns_service} Redis instance in {rhocp_short}: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch ' -spec: - redis: - enabled: true - templates: - designate-redis: - replicas: 1 -' ----- - -. Wait for the {dns_service} Redis instance to become ready: -+ ----- -$ oc wait --for condition=Ready --timeout=60s redises.redis.openstack.org/designate-redis ----- - -. Create the {dns_service} CR patch file: -+ -[subs="+quotes"] ----- -$ cat > /tmp/designate_osp_patch.yaml << 'MAINCR' -spec: - designate: - enabled: true - template: - designateAPI: - networkAttachments: - - internalapi - designateWorker: - networkAttachments: - - designate - replicas: 3 - designateCentral: - replicas: 3 - designateProducer: - replicas: 3 - designateBackendbind9: - networkAttachments: - - designate - override: - services: - - metadata: - annotations: - metallb.universe.tf/address-pool: designateext - metallb.universe.tf/allow-shared-ip: designateext - metallb.universe.tf/loadBalancerIPs: 172.50.0.80 - spec: - type: LoadBalancer - - metadata: - annotations: - metallb.universe.tf/address-pool: designateext - metallb.universe.tf/allow-shared-ip: designateext - metallb.universe.tf/loadBalancerIPs: 172.50.0.81 - spec: - type: LoadBalancer - - metadata: - annotations: - metallb.universe.tf/address-pool: designateext - metallb.universe.tf/allow-shared-ip: designateext - metallb.universe.tf/loadBalancerIPs: 172.50.0.82 - spec: - type: LoadBalancer - replicas: 3 - storageClass: - storageRequest: 10G - designateMdns: - networkAttachments: - - designate - replicas: 3 - designateUnbound: - networkAttachments: - - designate - replicas: 2 - override: - services: - - metadata: - annotations: - metallb.universe.tf/address-pool: designateext - metallb.universe.tf/allow-shared-ip: designateext - metallb.universe.tf/loadBalancerIPs: 172.50.0.85 - spec: - type: LoadBalancer - - metadata: - annotations: - metallb.universe.tf/address-pool: designateext - metallb.universe.tf/allow-shared-ip: designateext - metallb.universe.tf/loadBalancerIPs: 172.50.0.86 - spec: - type: LoadBalancer -MAINCR ----- -+ -where: - -``:: -Specifies the storage class name for persistent volumes (for example, `local-storage`). - -. Append the nameserver records to the patch file: -+ ----- -$ ns_yaml=/tmp/designate_ns_records.yaml -$ patch_file=/tmp/designate_osp_patch.yaml -$ echo ' nsRecords:' >> "$patch_file" -$ if [ -s "$ns_yaml" ] && [ "$(cat "$ns_yaml")" != "[]" ]; then - sed 's/^/ /' "$ns_yaml" >> "$patch_file" -else - echo ' []' >> "$patch_file" -fi ----- - -. Enable the {dns_service} in {rhocp_short}: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch-file /tmp/designate_osp_patch.yaml ----- - -. Wait for the {dns_service} to become ready: -+ ----- -$ oc wait --for condition=Ready --timeout=600s designate.designate.openstack.org/designate ----- diff --git a/docs_user/modules/proc_adopting-the-identity-service.adoc b/docs_user/modules/proc_adopting-the-identity-service.adoc deleted file mode 100644 index 4749e8e9e..000000000 --- a/docs_user/modules/proc_adopting-the-identity-service.adoc +++ /dev/null @@ -1,91 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="adopting-the-identity-service_{context}"] - -= Adopting the {identity_service} - -[role="_abstract"] -To adopt the {identity_service_first_ref}, you patch an existing `OpenStackControlPlane` custom resource (CR) where the {identity_service} is disabled. The patch starts the service with the configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) environment. - -.Prerequisites - -* Create the keystone secret that includes the Fernet keys that were copied from the {OpenStackShort} environment: -+ ----- -$ oc apply -f - <* - spec: - type: LoadBalancer - databaseInstance: openstack - secret: osp-secret -' ----- -+ -where: - -<172.17.0.80>:: -Specifies the load balancer IP in your environment. If you use IPv6, change the load balancer IP to the load balancer IP in your environment, for example, `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80`. - -. Create an alias to use the `openstack` command in the {rhos_long} deployment: -+ ----- -$ alias openstack="oc exec -t openstackclient -- openstack" ----- - -. Remove services and endpoints that still point to the {OpenStackShort} -control plane, excluding the {identity_service} and its endpoints: -+ ----- -$ openstack endpoint list | grep keystone | awk '/admin/{ print $2; }' | xargs ${BASH_ALIASES[openstack]} endpoint delete || true -> for service in aodh heat heat-cfn barbican cinderv3 glance designate gnocchi manila manilav2 neutron nova placement swift ironic-inspector ironic octavia; do -> openstack service list | awk "/ $service /{ print \$2; }" | xargs -r ${BASH_ALIASES[openstack]} service delete || true -> done ----- - -.Verification - -. Verify that you can access the `OpenStackClient` pod. For more information, see link:{defaultURL}/maintaining_the_red_hat_openstack_services_on_openshift_deployment/assembly_accessing-the-rhoso-cloud#proc_accessing-the-OpenStackClient-pod_cloud-access-admin[Accessing the OpenStackClient pod] in _Maintaining the {rhos_long_noacro} deployment_. - -. Confirm that the {identity_service} endpoints are defined and are pointing to the control plane FQDNs: -+ ----- -$ openstack endpoint list | grep keystone ----- - -. Wait for the `OpenStackControlPlane` resource to become `Ready`: -+ ----- -$ oc wait --for=condition=Ready --timeout=1m OpenStackControlPlane openstack ----- diff --git a/docs_user/modules/proc_adopting-the-loadbalancer-service.adoc b/docs_user/modules/proc_adopting-the-loadbalancer-service.adoc deleted file mode 100644 index 5be427b8b..000000000 --- a/docs_user/modules/proc_adopting-the-loadbalancer-service.adoc +++ /dev/null @@ -1,168 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="adopting-the-loadbalancer-service_{context}"] - -= Adopting the {loadbalancer_service} - -[role="_abstract"] -Adopt the {loadbalancer_first_ref} by patching the existing `OpenStackControlPlane` custom resource (CR) where the {loadbalancer_service} is disabled. The patch starts the service with the configuration parameters from {rhos_prev_long}. - -After data plane adoption, trigger a failover of existing load balancers to upgrade amphora virtual machines to use the new image and to establish connectivity with the new control plane. - -.Procedure - -. Migrate the server certificate authority (CA) passphrase from the previous deployment: -+ ----- -SERVER_CA_PASSPHRASE=$($CONTROLLER1_SSH grep ^ca_private_key_passphrase /var/lib/config-data/puppet-generated/octavia/etc/octavia/octavia.conf) - -oc apply -f - <", - "id": 24 - } - } -}, -{ - "op": "add", - "path": "/spec/desiredState/interfaces/-", - "value": { - "description": "Octavia Bridge", - "mtu": , - "state": "up", - "type": "linux-bridge", - "name": "octbr", - "bridge": { - "options": { "stp": { "enabled": "false" } }, - "port": [ { "name": "enp6s0.24" } ] - } - } -}]' - -done ----- -+ -where: - -:: -Specifies the name of the network interface in your {OpenShiftShort} setup. -:: -Specifies the `mtu` value in your environment. - -. To connect pods that manage load balancer virtual machines (amphorae) and the OpenvSwitch pods the OVN operator manages, configure the {loadbalancer_service} network attachment definition: -+ ----- -$ cat octavia-nad.yaml << EOF_CAT -apiVersion: k8s.cni.cncf.io/v1 -kind: NetworkAttachmentDefinition -metadata: - labels: - osp/net: octavia - name: octavia -spec: - config: | - { - "cniVersion": "0.3.1", - "name": "octavia", - "type": "bridge", - "bridge": "octbr", - "ipam": { - "type": "whereabouts", - "range": "172.23.0.0/24", - "range_start": "172.23.0.30", - "range_end": "172.23.0.70", - "routes": [ - { - "dst": "172.24.0.0/16", - "gw" : "172.23.0.150" - } - ] - } - } -EOF_CAT ----- - -. Create the `NetworkAttachmentDefinition` CR: -+ ----- -$ oc apply -f octavia-nad.yaml ----- - -. Enable the {loadbalancer_service} in {OpenShiftShort}: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch ' -spec: - ovn: - template: - ovnController: - networkAttachment: tenant - nicMappings: - octavia: octbr - octavia: - enabled: true - template: - amphoraImageContainerImage: quay.io/gthiemonge/octavia-amphora-image - octaviaHousekeeping: - networkAttachments: - - octavia - octaviaHealthManager: - networkAttachments: - - octavia - octaviaWorker: - networkAttachments: - - octavia -' ----- - -. Wait for the {loadbalancer_service} control plane services CRs to be ready: -+ ----- -$ oc wait --for condition=Ready --timeout=600s octavia.octavia.openstack.org/octavia ----- - -. Ensure that the {loadbalancer_service} is registered in the {identity_service}: -+ ----- -$ alias openstack="oc exec -t openstackclient -- openstack" -$ openstack service list | grep load-balancer -| bd078ca6f90c4b86a48801f45eb6f0d7 | octavia | load-balancer | -$ openstack endpoint list --service load-balancer -+----------------------------------+-----------+--------------+---------------+---------+-----------+---------------------------------------------------+ -| ID | Region | Service Name | Service Type | Enabled | Interface | URL | -+----------------------------------+-----------+--------------+---------------+---------+-----------+---------------------------------------------------+ -| f1ae7756b6164baf9cb82a1a670067a2 | regionOne | octavia | load-balancer | True | public | https://octavia-public-openstack.apps-crc.testing | -| ff3222b4621843669e89843395213049 | regionOne | octavia | load-balancer | True | internal | http://octavia-internal.openstack.svc:9876 | -+----------------------------------+-----------+--------------+---------------+---------+-----------+---------------------------------------------------+ ----- - -.Next steps - -After you complete the data plane adoption, you must upgrade existing load balancers and remove old resources. For more information, see xref:performing-post-adoption-cleanup-of-load-balancers_data-plane[Post-adoption tasks for the {loadbalancer_service}]. diff --git a/docs_user/modules/proc_adopting-the-networking-service.adoc b/docs_user/modules/proc_adopting-the-networking-service.adoc deleted file mode 100644 index 714f1dc62..000000000 --- a/docs_user/modules/proc_adopting-the-networking-service.adoc +++ /dev/null @@ -1,124 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="adopting-the-networking-service_{context}"] - -= Adopting the {networking_service} - -[role="_abstract"] -To adopt the {networking_first_ref}, you patch an existing `OpenStackControlPlane` custom resource (CR) that has the {networking_service} disabled. The patch starts the service with the -configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) environment. - -The {networking_service} adoption is complete if you see the following results: - -* The `NeutronAPI` service is running. -* The {identity_service_first_ref} endpoints are updated, and the same back end of the source cloud is available. - -ifeval::["{build}" != "downstream"] -The {networking_service} adoption follows a similar pattern to https://github.com/openstack-k8s-operators/data-plane-adoption/blob/main/keystone_adoption.md[Keystone]. -endif::[] - -.Prerequisites - -* Ensure that Single Node OpenShift or OpenShift Local is running in the {rhocp_long} cluster. -* Adopt the {identity_service}. For more information, see xref:adopting-the-identity-service_adopt-control-plane[Adopting the {identity_service}]. -* Migrate your OVN databases to `ovsdb-server` instances that run in the {rhocp_long} cluster. For more information, see xref:migrating-ovn-data_migrating-databases[Migrating OVN data]. - - -.Procedure - -* Patch the `OpenStackControlPlane` CR to deploy the {networking_service}: -+ -[subs="+quotes"] ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch ' -spec: - neutron: - enabled: true - apiOverride: - route: {} - template: - override: - service: - internal: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/allow-shared-ip: internalapi - metallb.universe.tf/loadBalancerIPs: *<172.17.0.80>* - spec: - type: LoadBalancer - databaseInstance: openstack - databaseAccount: neutron - secret: osp-secret - networkAttachments: - - internalapi -' ----- -+ -where: - -<172.17.0.80>:: -Specifies the load balancer IP in your environment. If you use IPv6, change the load balancer IP to the load balancer IP in your environment, for example, `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80`. -+ -[NOTE] -==== -If you used the `neutron-dhcp-agent` in your {OpenStackShort} {rhos_prev_ver} deployment and you still need to use it after adoption, you must enable the `dhcp_agent_notification` for the `neutron-api` service: - -[source,shell] ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch ' - spec: - neutron: - template: - customServiceConfig: | - [DEFAULT] - dhcp_agent_notification = True -' ----- -+ -==== -[NOTE] -==== -If you are adopting the {bare_metal_first_ref}, you must configure the ML2 mechanism drivers to include both `ovn` and `baremetal`: - -[source,shell] ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch ' -spec: - neutron: - template: - ml2MechanismDrivers: - - ovn - - baremetal -' ----- -==== - -.Verification - -* Inspect the resulting {networking_service} pods: -+ ----- -$ oc get pods -l service=neutron ----- - -* Ensure that the `Neutron API` service is registered in the {identity_service}: -+ ----- -$ openstack service list | grep network ----- -+ -[source,shell] ----- -$ openstack endpoint list | grep network - -| 6a805bd6c9f54658ad2f24e5a0ae0ab6 | regionOne | neutron | network | True | public | http://neutron-public-openstack.apps-crc.testing | -| b943243e596847a9a317c8ce1800fa98 | regionOne | neutron | network | True | internal | http://neutron-internal.openstack.svc:9696 | ----- - -* Create sample resources so that you can test whether the user can create networks, subnets, ports, or routers: -+ ----- -$ openstack network create net -$ openstack subnet create --network net --subnet-range 10.0.0.0/24 subnet -$ openstack router create router ----- diff --git a/docs_user/modules/proc_adopting-the-object-storage-service.adoc b/docs_user/modules/proc_adopting-the-object-storage-service.adoc deleted file mode 100644 index 6c6ddf767..000000000 --- a/docs_user/modules/proc_adopting-the-object-storage-service.adoc +++ /dev/null @@ -1,148 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="adopting-the-object-storage-service_{context}"] - -= Adopting the {object_storage} - -[role="_abstract"] -If you are using Object Storage as a service, adopt the {object_storage_first_ref} to the {rhos_long} environment. If you are using the Object Storage API of the Ceph Object Gateway (RGW), skip the following procedure. - -.Prerequisites - -* The {object_storage} storage back-end services are running in the {rhos_prev_long} ({OpenStackShort}) deployment. -* The storage network is properly configured on the {rhocp_long} cluster. For more information, see link:{deploying-rhoso}/assembly_preparing-rhocp-for-rhoso#proc_configuring-the-data-plane-network_preparing[Preparing Red Hat OpenShift Container Platform for Red Hat OpenStack Services on OpenShift] in _{deploying-rhoso-t}_. - -.Procedure - -. Create the `swift-conf` secret that includes the {object_storage} hash path suffix and prefix: -+ ----- -$ oc apply -f - <* - spec: - type: LoadBalancer - *networkAttachments:* - - storage -' ----- -+ -* `spec.swift.swiftStorage.storageClass` must match the {rhos_acro} deployment storage class. -* `metallb.universe.tf/loadBalancerIPs: <172.17.0.80>` specifies the load balancer IP in your environment. If you use IPv6, change the load balancer IP to the load balancer IP in your environment, for example, `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80`. -* `spec.swift.swiftProxy.networkAttachments` must match the network attachment for the previous {object_storage} configuration from the {OpenStackShort} deployment. -+ -[NOTE] -If `SwiftEncryptionEnabled: true` was set in {rhos_prev_long}, ensure that `spec.swift.swiftProxy.encryptionEnabled` is set to `true` and that the {key_manager_first_ref} adoption is complete before proceeding. - -.Verification - -* Inspect the resulting {object_storage} pods: -+ ----- -$ oc get pods -l component=swift-proxy ----- - -* Verify that the Object Storage proxy service is registered in the {identity_service_first_ref}: -+ ----- -$ openstack service list | grep swift -| b5b9b1d3c79241aa867fa2d05f2bbd52 | swift | object-store | ----- -+ ----- -$ openstack endpoint list | grep swift -| 32ee4bd555414ab48f2dc90a19e1bcd5 | regionOne | swift | object-store | True | public | https://swift-public-openstack.apps-crc.testing/v1/AUTH_%(tenant_id)s | -| db4b8547d3ae4e7999154b203c6a5bed | regionOne | swift | object-store | True | internal | http://swift-internal.openstack.svc:8080/v1/AUTH_%(tenant_id)s | ----- - -* Verify that you are able to upload and download objects: -+ ----- -$ openstack container create test -+---------------------------------------+-----------+------------------------------------+ -| account | container | x-trans-id | -+---------------------------------------+-----------+------------------------------------+ -| AUTH_4d9be0a9193e4577820d187acdd2714a | test | txe5f9a10ce21e4cddad473-0065ce41b9 | -+---------------------------------------+-----------+------------------------------------+ - -$ openstack object create test --name obj <(echo "Hello World!") -+--------+-----------+----------------------------------+ -| object | container | etag | -+--------+-----------+----------------------------------+ -| obj | test | d41d8cd98f00b204e9800998ecf8427e | -+--------+-----------+----------------------------------+ - -$ openstack object save test obj --file - -Hello World! ----- - -.Next steps - -After the initial adoption, the {object_storage} data is still stored on the existing {OpenStackShort} nodes. You have two options for handling these storage nodes: - -* *Migrate data to new {rhos_acro} nodes*: Provision new storage nodes on {rhocp_long} and gradually move data by using the `swift-ring-tool`. For more information, see xref:migrating-object-storage-data-to-rhoso-nodes_migrate-object-storage-service[Migrating the {object_storage_first_ref} data from {OpenStackShort} to {rhos_long} nodes]. - -* *Convert existing nodes to dataplane nodes*: Keep the data on the same nodes and convert them to data plane nodes that are managed by the `openstack-operators`. For more information, see xref:converting-object-storage-nodes[Converting {object_storage} storage nodes]. diff --git a/docs_user/modules/proc_adopting-the-openstack-dashboard.adoc b/docs_user/modules/proc_adopting-the-openstack-dashboard.adoc deleted file mode 100644 index fd554fa40..000000000 --- a/docs_user/modules/proc_adopting-the-openstack-dashboard.adoc +++ /dev/null @@ -1,44 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="adopting-the-openstack-dashboard_{context}"] - -= Adopting the {dashboard_service} - -[role="_abstract"] -To adopt the {dashboard_first_ref}, you patch an existing `OpenStackControlPlane` custom resource (CR) that has the {dashboard_service} disabled. The patch starts the service with the configuration parameters that are provided by the {rhos_prev_long} environment. - -.Prerequisites - -* You adopted Memcached. For more information, see xref:deploying-backend-services_migrating-databases[Deploying back-end services]. -* You adopted the {identity_service_first_ref}. For more information, see xref:adopting-the-identity-service_adopt-control-plane[Adopting the {identity_service}]. - -.Procedure - -* Patch the `OpenStackControlPlane` CR to deploy the {dashboard_service}: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch ' -spec: - horizon: - enabled: true - apiOverride: - route: {} - template: - memcachedInstance: memcached - secret: osp-secret -' ----- - -.Verification - -. Verify that the {dashboard_service} instance is successfully deployed and ready: -+ ----- -$ oc get horizon ----- - -. Confirm that the {dashboard_service} is reachable and returns a `200` status code: -+ ----- -PUBLIC_URL=$(oc get horizon horizon -o jsonpath='{.status.endpoint}') -curl --silent --output /dev/stderr --head --write-out "%{http_code}" "$PUBLIC_URL/dashboard/auth/login/?next=/dashboard/" -k | grep 200 ----- diff --git a/docs_user/modules/proc_adopting-the-orchestration-service.adoc b/docs_user/modules/proc_adopting-the-orchestration-service.adoc deleted file mode 100644 index d17127583..000000000 --- a/docs_user/modules/proc_adopting-the-orchestration-service.adoc +++ /dev/null @@ -1,186 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="adopting-the-orchestration-service_{context}"] - -= Adopting the {orchestration} - -[role="_abstract"] -To adopt the {orchestration_first_ref}, you patch an existing `OpenStackControlPlane` custom resource (CR), where the {orchestration} -is disabled. The patch starts the service with the configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) environment. - -After you complete the adoption process, you have CRs for `Heat`, `HeatAPI`, `HeatEngine`, and `HeatCFNAPI`, and endpoints within the {identity_service_first_ref} to facilitate these services. - -ifeval::["{build}" != "downstream"] -The Heat Adoption follows a similar workflow to https://github.com/openstack-k8s-operators/data-plane-adoption/blob/main/keystone_adoption.md[Keystone]. -endif::[] - -.Prerequisites - -* The source {OpenStackPreviousInstaller} environment is running. -* The target {rhocp_long} environment is running. -* You adopted MariaDB and the {identity_service}. -* If your existing {orchestration} stacks contain resources from other services such as {networking_first_ref}, {compute_service_first_ref}, {object_storage_first_ref}, and so on, adopt those sevices before adopting the {orchestration}. - -.Procedure - -. Retrieve the existing `auth_encryption_key` and `service` passwords. You use these passwords to patch the `osp-secret`. In the following example, the `auth_encryption_key` is used as `HeatAuthEncryptionKey` and the `service` password is used as `HeatPassword`: -+ ----- -[stack@rhosp17 ~]$ grep -E 'HeatPassword|HeatAuth|HeatStackDomainAdmin' ~/overcloud-deploy/overcloud/overcloud-passwords.yaml - HeatAuthEncryptionKey: Q60Hj8PqbrDNu2dDCbyIQE2dibpQUPg2 - HeatPassword: dU2N0Vr2bdelYH7eQonAwPfI3 - HeatStackDomainAdminPassword: dU2N0Vr2bdelYH7eQonAwPfI3 ----- - -. Log in to a Controller node and verify the `auth_encryption_key` value in use: -+ ----- -[stack@rhosp17 ~]$ ansible -i overcloud-deploy/overcloud/config-download/overcloud/tripleo-ansible-inventory.yaml overcloud-controller-0 -m shell -a "grep auth_encryption_key /var/lib/config-data/puppet-generated/heat/etc/heat/heat.conf | grep -Ev '^#|^$'" -b -overcloud-controller-0 | CHANGED | rc=0 >> -auth_encryption_key=Q60Hj8PqbrDNu2dDCbyIQE2dibpQUPg2 ----- - -. Encode the password to Base64 format: -+ ----- -$ echo -n Q60Hj8PqbrDNu2dDCbyIQE2dibpQUPg2 | base64 -UTYwSGo4UHFickROdTJkRENieUlRRTJkaWJwUVVQZzI= ----- - -. Patch the `osp-secret` to update the `HeatAuthEncryptionKey` and `HeatPassword` parameters. These values must match the values in the {OpenStackPreviousInstaller} {orchestration} configuration: -+ ----- -$ oc patch secret osp-secret --type='json' -p='[{"op" : "replace" ,"path" : "/data/HeatAuthEncryptionKey" ,"value" : "UTYwSGo4UHFickROdTJkRENieUlRRTJkaWJwUVVQZzI="}]' -secret/osp-secret patched ----- - -. Patch the `OpenStackControlPlane` CR to deploy the {orchestration}: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch ' -spec: - heat: - enabled: true - apiOverride: - route: {} - template: - databaseInstance: openstack - databaseAccount: heat - secret: osp-secret - memcachedInstance: memcached - passwordSelectors: - authEncryptionKey: HeatAuthEncryptionKey - service: HeatPassword - stackDomainAdminPassword: HeatStackDomainAdminPassword -' ----- - -. Remove old `heat-engine` services from the `heat-api` pods or the `heat-engine` pods. For example: -+ ----- -$ oc exec -it -n openstack "$(oc get pods -n openstack -l service=heat -o jsonpath='{.items[0].metadata.name}')" -c heat-api -- heat-manage service clean ----- -+ -[NOTE] -You cannot run this command from the `openstackclient` pod. The `openstackclient` pod does not include the {orchestration} configuration or the `heat-manage` binary. - -.Verification - -. Ensure that the statuses of all the CRs are `Setup complete`: -+ ----- -$ oc get Heat,HeatAPI,HeatEngine,HeatCFNAPI -NAME STATUS MESSAGE -heat.heat.openstack.org/heat True Setup complete - -NAME STATUS MESSAGE -heatapi.heat.openstack.org/heat-api True Setup complete - -NAME STATUS MESSAGE -heatengine.heat.openstack.org/heat-engine True Setup complete - -NAME STATUS MESSAGE -heatcfnapi.heat.openstack.org/heat-cfnapi True Setup complete ----- - -. Check that the {orchestration} is registered in the {identity_service}: -+ ----- -$ oc exec -it openstackclient -- openstack service list -c Name -c Type -+------------+----------------+ -| Name | Type | -+------------+----------------+ -| heat | orchestration | -| glance | image | -| heat-cfn | cloudformation | -| ceilometer | Ceilometer | -| keystone | identity | -| placement | placement | -| cinderv3 | volumev3 | -| nova | compute | -| neutron | network | -+------------+----------------+ ----- -+ ----- -$ oc exec -it openstackclient -- openstack endpoint list --service=heat -f yaml -- Enabled: true - ID: 1da7df5b25b94d1cae85e3ad736b25a5 - Interface: public - Region: regionOne - Service Name: heat - Service Type: orchestration - URL: http://heat-api-public-openstack-operators.apps.okd.bne-shift.net/v1/%(tenant_id)s -- Enabled: true - ID: 414dd03d8e9d462988113ea0e3a330b0 - Interface: internal - Region: regionOne - Service Name: heat - Service Type: orchestration - URL: http://heat-api-internal.openstack-operators.svc:8004/v1/%(tenant_id)s ----- - -. Check that the {orchestration} engine services are running: -+ ----- -$ oc exec -it openstackclient -- openstack orchestration service list -f yaml -- Binary: heat-engine - Engine ID: b16ad899-815a-4b0c-9f2e-e6d9c74aa200 - Host: heat-engine-6d47856868-p7pzz - Hostname: heat-engine-6d47856868-p7pzz - Status: up - Topic: engine - Updated At: '2023-10-11T21:48:01.000000' -- Binary: heat-engine - Engine ID: 887ed392-0799-4310-b95c-ac2d3e6f965f - Host: heat-engine-6d47856868-p7pzz - Hostname: heat-engine-6d47856868-p7pzz - Status: up - Topic: engine - Updated At: '2023-10-11T21:48:00.000000' -- Binary: heat-engine - Engine ID: 26ed9668-b3f2-48aa-92e8-2862252485ea - Host: heat-engine-6d47856868-p7pzz - Hostname: heat-engine-6d47856868-p7pzz - Status: up - Topic: engine - Updated At: '2023-10-11T21:48:00.000000' -- Binary: heat-engine - Engine ID: 1011943b-9fea-4f53-b543-d841297245fd - Host: heat-engine-6d47856868-p7pzz - Hostname: heat-engine-6d47856868-p7pzz - Status: up - Topic: engine - Updated At: '2023-10-11T21:48:01.000000' ----- - -. Verify that you can see your {orchestration} stacks: -+ ----- -$ openstack stack list -f yaml -- Creation Time: '2023-10-11T22:03:20Z' - ID: 20f95925-7443-49cb-9561-a1ab736749ba - Project: 4eacd0d1cab04427bc315805c28e66c9 - Stack Name: test-networks - Stack Status: CREATE_COMPLETE - Updated Time: null ----- diff --git a/docs_user/modules/proc_adopting-the-placement-service.adoc b/docs_user/modules/proc_adopting-the-placement-service.adoc deleted file mode 100644 index ca69a6443..000000000 --- a/docs_user/modules/proc_adopting-the-placement-service.adoc +++ /dev/null @@ -1,65 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="adopting-the-placement-service_{context}"] - -= Adopting the Placement service - -[role="_abstract"] -To adopt the Placement service, you patch an existing `OpenStackControlPlane` custom resource (CR) that has the Placement service disabled. The patch starts the service with the configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) environment. - -.Prerequisites - -* You import your databases to MariaDB instances on the control plane. For more information, see xref:migrating-databases-to-mariadb-instances_migrating-databases[Migrating databases to MariaDB instances]. -* You adopt the {identity_service_first_ref}. For more information, see xref:adopting-the-identity-service_adopt-control-plane[Adopting the Identity service]. - -.Procedure - -* Patch the `OpenStackControlPlane` CR to deploy the Placement service: -+ -[subs="+quotes"] ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch ' -spec: - placement: - enabled: true - apiOverride: - route: {} - template: - databaseInstance: openstack - databaseAccount: placement - secret: osp-secret - override: - service: - internal: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/allow-shared-ip: internalapi - metallb.universe.tf/loadBalancerIPs: *<172.17.0.80>* - spec: - type: LoadBalancer -' ----- -+ -where: - -<172.17.0.80>:: -Specifies the load balancer IP in your environment. If you use IPv6, change the load balancer IP to the load balancer IP in your environment, for example, `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80`. - -.Verification - -* Check that the Placement service endpoints are defined and pointing to the -control plane FQDNs, and that the Placement API responds: -+ ----- -$ alias openstack="oc exec -t openstackclient -- openstack" - -$ openstack endpoint list | grep placement - - -# Without OpenStack CLI placement plugin installed: -$ PLACEMENT_PUBLIC_URL=$(openstack endpoint list -c 'Service Name' -c 'Service Type' -c URL | grep placement | grep public | awk '{ print $6; }') -$ oc exec -t openstackclient -- curl "$PLACEMENT_PUBLIC_URL" - -# With OpenStack CLI placement plugin installed: -$ openstack resource class list ----- diff --git a/docs_user/modules/proc_comparing-configuration-files-between-deployments.adoc b/docs_user/modules/proc_comparing-configuration-files-between-deployments.adoc deleted file mode 100644 index ed2c284b0..000000000 --- a/docs_user/modules/proc_comparing-configuration-files-between-deployments.adoc +++ /dev/null @@ -1,101 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="comparing-configuration-files-between-deployments_{context}"] - -= Comparing configuration files between deployments - -[role="_abstract"] -To help you manage the configuration for your {OpenStackPreviousInstaller} and {rhos_prev_long} ({OpenStackShort}) services, you can compare the configuration files between your {OpenStackPreviousInstaller} deployment and the {rhos_long} cloud by using the os-diff tool. -ifeval::["{build_variant}" == "ospdo"] -[NOTE] - Os-diff does not currently support director Operator. -endif::[] - -.Prerequisites - -* Golang is installed and configured on your environment: -+ ----- -dnf install -y golang-github-openstack-k8s-operators-os-diff ----- - -.Procedure - -. Configure the `/etc/os-diff/os-diff.cfg` file and the `/etc/os-diff/ssh.config` file according to your environment. To allow os-diff to connect to your clouds and pull files from the services that you describe in the `config.yaml` file, you must set the following options in the `os-diff.cfg` file: -+ -[subs=+quotes] ----- -[Default] - -local_config_dir=/tmp/ -service_config_file=config.yaml - -[Tripleo] - -*ssh_cmd=ssh -F ssh.config* -*director_host=standalone* -container_engine=podman -connection=ssh -remote_config_path=/tmp/tripleo -local_config_path=/tmp/ - -[Openshift] - -ocp_local_config_path=/tmp/ocp -connection=local -ssh_cmd="" ----- -+ -* `ssh_cmd=ssh -F ssh.config` instructs os-diff to access your {OpenStackPreviousInstaller} host through SSH. The default value is `ssh -F ssh.config`. However, you can set the value without an ssh.config file, for example, `ssh -i /home/user/.ssh/id_rsa stack@my.undercloud.local`. -* `director_host=standalone` specifies the host to use to access your cloud, and the podman/docker binary is installed and allowed to interact with the running containers. You can leave this key blank. - -. If you use a host file to connect to your cloud, configure the `ssh.config` file to allow os-diff to access your {OpenStackShort} environment, for example: -+ -[source,yaml] -[subs=+quotes] ----- -Host * - IdentitiesOnly yes - -Host virthost - Hostname virthost - IdentityFile ~/.ssh/id_rsa - User root - StrictHostKeyChecking no - UserKnownHostsFile=/dev/null - - -Host standalone - Hostname standalone -ifeval::["{build}" != "downstream"] - IdentityFile ~/install_yamls/out/edpm/ansibleee-ssh-key-id_rsa -endif::[] -ifeval::["{build}" == "downstream"] - IdentityFile -endif::[] - User root - StrictHostKeyChecking no - UserKnownHostsFile=/dev/null - -Host crc - Hostname crc - IdentityFile ~/.ssh/id_rsa - User stack - StrictHostKeyChecking no - UserKnownHostsFile=/dev/null ----- -+ -* Replace `` with the path to your SSH key. You must provide a value for `IdentityFile` to get full working access to your {OpenStackShort} environment. - -. If you use an inventory file to connect to your cloud, generate the `ssh.config` file from your Ansible inventory, for example, `tripleo-ansible-inventory.yaml` file: -+ ----- -$ os-diff configure -i tripleo-ansible-inventory.yaml -o ssh.config --yaml ----- - -.Verification - -* Test your connection: -+ ----- -$ ssh -F ssh.config standalone ----- diff --git a/docs_user/modules/proc_completing-prerequisites-for-migrating-ceph-monitoring-stack.adoc b/docs_user/modules/proc_completing-prerequisites-for-migrating-ceph-monitoring-stack.adoc deleted file mode 100644 index 8f4ebb986..000000000 --- a/docs_user/modules/proc_completing-prerequisites-for-migrating-ceph-monitoring-stack.adoc +++ /dev/null @@ -1,75 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="completing-prerequisites-for-migrating-ceph-monitoring-stack_{context}"] - -= Completing prerequisites for a {Ceph} cluster with monitoring stack components - -[role="_abstract"] -Before you migrate a {Ceph} cluster with monitoring stack components, you must gather monitoring stack information, review and update the container image registry, and remove the undercloud container images. - -[NOTE] -In addition to updating the container images related to the monitoring stack, you must update the configuration entry related to the `container_image_base`. This has an impact on all the {Ceph} daemons that rely on the undercloud images. -New daemons are deployed by using the new image registry location that is configured in the {Ceph} cluster. - -.Procedure - -. Gather the current status of the monitoring stack. Verify that -the hosts have no `monitoring` label, or `grafana`, `prometheus`, or `alertmanager`, in cases of a per daemons placement evaluation: -[NOTE] -The entire relocation process is driven by `cephadm` and relies on labels to be -assigned to the target nodes, where the daemons are scheduled. -ifeval::["{build}" != "upstream"] -For more information about assigning labels to nodes, review the Red Hat Knowledgebase article https://access.redhat.com/articles/1548993[Red Hat Ceph Storage: Supported configurations]. -endif::[] -+ ----- -[tripleo-admin@controller-0 ~]$ sudo cephadm shell -- ceph orch host ls - -HOST ADDR LABELS STATUS -cephstorage-0.redhat.local 192.168.24.11 osd mds -cephstorage-1.redhat.local 192.168.24.12 osd mds -cephstorage-2.redhat.local 192.168.24.47 osd mds -controller-0.redhat.local 192.168.24.35 _admin mon mgr -controller-1.redhat.local 192.168.24.53 mon _admin mgr -controller-2.redhat.local 192.168.24.10 mon _admin mgr -6 hosts in cluster ----- -+ -Confirm that the cluster is healthy and that both `ceph orch ls` and -`ceph orch ps` return the expected number of deployed daemons. - -. Review and update the container image registry: -[NOTE] -If you run the {Ceph} externalization procedure after you migrate the {rhos_prev_long} control plane, update the container images in the {CephCluster} cluster configuration. The current container images point to the undercloud registry, which might not be available anymore. Because the undercloud is not available after adoption is complete, replace the undercloud-provided images with an alternative registry. -ifeval::["{build}" != "downstream"] -In case the desired option is to rely on the https://github.com/ceph/ceph/blob/reef/src/cephadm/cephadm.py#L48[default images] -shipped by cephadm, remove the following config options from the {CephCluster} cluster. -endif::[] -+ ----- -$ ceph config dump -... -... -ifeval::["{build}" != "downstream"] -mgr advanced mgr/cephadm/container_image_alertmanager undercloud-0.ctlplane.redhat.local:8787/ceph/alertmanager:v0.25.0 -mgr advanced mgr/cephadm/container_image_base undercloud-0.ctlplane.redhat.local:8787/ceph/ceph:v18 -mgr advanced mgr/cephadm/container_image_grafana undercloud-0.ctlplane.redhat.local:8787/ceph/ceph-grafana:9.4.7 -mgr advanced mgr/cephadm/container_image_node_exporter undercloud-0.ctlplane.redhat.local:8787/ceph/node-exporter:v1.5.0 -mgr advanced mgr/cephadm/container_image_prometheus undercloud-0.ctlplane.redhat.local:8787/ceph/prometheus:v2.43.0 -endif::[] -ifeval::["{build}" == "downstream"] -mgr advanced mgr/cephadm/container_image_alertmanager undercloud-0.ctlplane.redhat.local:8787/rh-osbs/openshift-ose-prometheus-alertmanager:v4.10 -mgr advanced mgr/cephadm/container_image_base undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhceph -mgr advanced mgr/cephadm/container_image_grafana undercloud-0.ctlplane.redhat.local:8787/rh-osbs/grafana:latest -mgr advanced mgr/cephadm/container_image_node_exporter undercloud-0.ctlplane.redhat.local:8787/rh-osbs/openshift-ose-prometheus-node-exporter:v4.10 -mgr advanced mgr/cephadm/container_image_prometheus undercloud-0.ctlplane.redhat.local:8787/rh-osbs/openshift-ose-prometheus:v4.10 -endif::[] ----- - -. Remove the undercloud container images: -+ ----- -$ cephadm shell -- ceph config rm mgr mgr/cephadm/container_image_base \ -for i in prometheus grafana alertmanager node_exporter; do \ - cephadm shell -- ceph config rm mgr mgr/cephadm/container_image_$i \ -done ----- diff --git a/docs_user/modules/proc_completing-prerequisites-for-migrating-ceph-rgw.adoc b/docs_user/modules/proc_completing-prerequisites-for-migrating-ceph-rgw.adoc deleted file mode 100644 index ce967ab10..000000000 --- a/docs_user/modules/proc_completing-prerequisites-for-migrating-ceph-rgw.adoc +++ /dev/null @@ -1,200 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="completing-prerequisites-for-migrating-ceph-rgw_{context}"] - -= Completing prerequisites for {Ceph} RGW migration - -[role="_abstract"] -Complete the following prerequisites before you begin the Ceph Object Gateway (RGW) migration. - -.Procedure - -. Check the current status of the {Ceph} nodes: -+ ----- -(undercloud) [stack@undercloud-0 ~]$ metalsmith list - - - +------------------------+ +----------------+ - | IP Addresses | | Hostname | - +------------------------+ +----------------+ - | ctlplane=192.168.24.25 | | cephstorage-0 | - | ctlplane=192.168.24.10 | | cephstorage-1 | - | ctlplane=192.168.24.32 | | cephstorage-2 | - | ctlplane=192.168.24.28 | | compute-0 | - | ctlplane=192.168.24.26 | | compute-1 | - | ctlplane=192.168.24.43 | | controller-0 | - | ctlplane=192.168.24.7 | | controller-1 | - | ctlplane=192.168.24.41 | | controller-2 | - +------------------------+ +----------------+ ----- - -. Log in to `controller-0` and check the Pacemaker status to identify important information for the RGW migration: -+ ----- -Full List of Resources: - * ip-192.168.24.46 (ocf:heartbeat:IPaddr2): Started controller-0 - * ip-10.0.0.103 (ocf:heartbeat:IPaddr2): Started controller-1 - * ip-172.17.1.129 (ocf:heartbeat:IPaddr2): Started controller-2 - * ip-172.17.3.68 (ocf:heartbeat:IPaddr2): Started controller-0 - * ip-172.17.4.37 (ocf:heartbeat:IPaddr2): Started controller-1 - * Container bundle set: haproxy-bundle - -[undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp17-openstack-haproxy:pcmklatest]: - * haproxy-bundle-podman-0 (ocf:heartbeat:podman): Started controller-2 - * haproxy-bundle-podman-1 (ocf:heartbeat:podman): Started controller-0 - * haproxy-bundle-podman-2 (ocf:heartbeat:podman): Started controller-1 ----- - -. Identify the ranges of the storage networks. The following is an example and the values might differ in your environment: -+ -[subs="+quotes"] ----- -[heat-admin@controller-0 ~]$ ip -o -4 a - -1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever -2: enp1s0 inet 192.168.24.45/24 brd 192.168.24.255 scope global enp1s0\ valid_lft forever preferred_lft forever -2: enp1s0 inet 192.168.24.46/32 brd 192.168.24.255 scope global enp1s0\ valid_lft forever preferred_lft forever -7: *br-ex* inet 10.0.0.122/24 brd 10.0.0.255 scope global br-ex\ valid_lft forever preferred_lft forever -8: vlan70 inet 172.17.5.22/24 brd 172.17.5.255 scope global vlan70\ valid_lft forever preferred_lft forever -8: vlan70 inet 172.17.5.94/32 brd 172.17.5.255 scope global vlan70\ valid_lft forever preferred_lft forever -9: vlan50 inet 172.17.2.140/24 brd 172.17.2.255 scope global vlan50\ valid_lft forever preferred_lft forever -10: *vlan30* inet 172.17.3.73/24 brd 172.17.3.255 scope global vlan30\ valid_lft forever preferred_lft forever -10: vlan30 inet 172.17.3.68/32 brd 172.17.3.255 scope global vlan30\ valid_lft forever preferred_lft forever -11: vlan20 inet 172.17.1.88/24 brd 172.17.1.255 scope global vlan20\ valid_lft forever preferred_lft forever -12: vlan40 inet 172.17.4.24/24 brd 172.17.4.255 scope global vlan40\ valid_lft forever preferred_lft forever ----- -+ -* `br-ex` represents the External Network, where in the current environment, HAProxy has the front-end Virtual IP (VIP) assigned. -* `vlan30` represents the Storage Network, where the new RGW instances should be started on the {CephCluster} nodes. - -. Identify the network that you previously had in HAProxy and propagate it through {OpenStackPreviousInstaller} to the {CephCluster} nodes. Use this network to reserve a new VIP that is owned by {Ceph} as the entry point for the RGW service. - -.. Log in to `controller-0` and find the `ceph_rgw` section in the current HAProxy configuration: -+ ----- -$ less /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg -... -... -listen ceph_rgw - bind 10.0.0.103:8080 transparent - bind 172.17.3.68:8080 transparent - mode http - balance leastconn - http-request set-header X-Forwarded-Proto https if { ssl_fc } - http-request set-header X-Forwarded-Proto http if !{ ssl_fc } - http-request set-header X-Forwarded-Port %[dst_port] - option httpchk GET /swift/healthcheck - option httplog - option forwardfor - server controller-0.storage.redhat.local 172.17.3.73:8080 check fall 5 inter 2000 rise 2 - server controller-1.storage.redhat.local 172.17.3.146:8080 check fall 5 inter 2000 rise 2 - server controller-2.storage.redhat.local 172.17.3.156:8080 check fall 5 inter 2000 rise 2 ----- - -.. Confirm that the network is used as an HAProxy front end. The following example shows that `controller-0` exposes the services by using the external network, which is absent from the {Ceph} nodes. You must propagate the external network through {OpenStackPreviousInstaller}: -+ ----- -[controller-0]$ ip -o -4 a - -... -7: br-ex inet 10.0.0.106/24 brd 10.0.0.255 scope global br-ex\ valid_lft forever preferred_lft forever -... ----- -+ -[NOTE] -If the target nodes are not managed by director, you cannot use this procedure to configure the network. An administrator must manually configure all the required networks. - -. Propagate the HAProxy front-end network to {CephCluster} nodes. - -.. In the NIC template that you use to define the `ceph-storage` network interfaces, add the new config section in the {Ceph} network configuration template file, for example, `/home/stack/composable_roles/network/nic-configs/ceph-storage.j2`: -+ ----- ---- -network_config: -- type: interface - name: nic1 - use_dhcp: false - dns_servers: {{ ctlplane_dns_nameservers }} - addresses: - - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_cidr }} - routes: {{ ctlplane_host_routes }} -- type: vlan - vlan_id: {{ storage_mgmt_vlan_id }} - device: nic1 - addresses: - - ip_netmask: {{ storage_mgmt_ip }}/{{ storage_mgmt_cidr }} - routes: {{ storage_mgmt_host_routes }} -- type: interface - name: nic2 - use_dhcp: false - defroute: false -- type: vlan - vlan_id: {{ storage_vlan_id }} - device: nic2 - addresses: - - ip_netmask: {{ storage_ip }}/{{ storage_cidr }} - routes: {{ storage_host_routes }} -- type: ovs_bridge - name: {{ neutron_physical_bridge_name }} - dns_servers: {{ ctlplane_dns_nameservers }} - domain: {{ dns_search_domains }} - use_dhcp: false - addresses: - - ip_netmask: {{ external_ip }}/{{ external_cidr }} - routes: {{ external_host_routes }} - members: [] - - type: interface - name: nic3 - primary: true ----- - -.. Add the External Network to the bare metal file, for example, `/home/stack/composable_roles/network/baremetal_deployment.yaml` that is used by `metalsmith`: -+ -[NOTE] -Ensure that 'network_config_update' is enabled for network propagation to the target nodes when `os-net-config` is triggered. -+ ----- -- name: CephStorage - count: 3 - hostname_format: cephstorage-%index% - instances: - - hostname: cephstorage-0 - name: ceph-0 - - hostname: cephstorage-1 - name: ceph-1 - - hostname: cephstorage-2 - name: ceph-2 - defaults: - profile: ceph-storage - network_config: - template: /home/stack/composable_roles/network/nic-configs/ceph-storage.j2 - network_config_update: true - networks: - - network: ctlplane - vif: true - - network: storage - - network: storage_mgmt - - network: external ----- - -.. Configure the new network on the bare metal nodes: -+ ----- -(undercloud) [stack@undercloud-0]$ openstack overcloud node provision \ - -o overcloud-baremetal-deployed-0.yaml \ - --stack overcloud \ - --network-config -y \ - $PWD/composable_roles/network/baremetal_deployment.yaml ----- - -.. Verify that the new network is configured on the {CephCluster} nodes: -+ ----- -[root@cephstorage-0 ~]# ip -o -4 a - -1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever -2: enp1s0 inet 192.168.24.54/24 brd 192.168.24.255 scope global enp1s0\ valid_lft forever preferred_lft forever -11: vlan40 inet 172.17.4.43/24 brd 172.17.4.255 scope global vlan40\ valid_lft forever preferred_lft forever -12: vlan30 inet 172.17.3.23/24 brd 172.17.3.255 scope global vlan30\ valid_lft forever preferred_lft forever -14: br-ex inet 10.0.0.133/24 brd 10.0.0.255 scope global br-ex\ valid_lft forever preferred_lft forever ----- diff --git a/docs_user/modules/proc_configuring-a-ceph-backend.adoc b/docs_user/modules/proc_configuring-a-ceph-backend.adoc deleted file mode 100644 index d33917e27..000000000 --- a/docs_user/modules/proc_configuring-a-ceph-backend.adoc +++ /dev/null @@ -1,214 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="configuring-a-ceph-backend_{context}"] - -= Configuring a {Ceph} back end - -[role="_abstract"] -If your {rhos_prev_long} ({OpenStackShort}) {rhos_prev_ver} deployment uses a {Ceph} back end for any service, such as {image_service_first_ref}, {block_storage_first_ref}, {compute_service_first_ref}, or {rhos_component_storage_file_first_ref}, you must configure the custom resources (CRs) to use the same back end in the {rhos_long} {rhos_curr_ver} deployment. - -[NOTE] -To run `ceph` commands, you must use SSH to connect to a {Ceph} node and run `sudo cephadm shell`. This generates a Ceph orchestrator container that enables you to run administrative commands against the {CephCluster} cluster. If you deployed the {CephCluster} cluster by using {OpenStackPreviousInstaller}, you can launch the `cephadm` shell from an {OpenStackShort} Controller node. - -.Prerequisites - -* The `OpenStackControlPlane` CR is created. -* If your {OpenStackShort} {rhos_prev_ver} deployment uses the {rhos_component_storage_file}, the openstack keyring is updated. Modify the `openstack` user so that you can use it across all {OpenStackShort} services: -+ ----- -ceph auth caps client.openstack \ - mgr 'allow *' \ - mon 'allow r, profile rbd' \ - osd 'profile rbd pool=vms, profile rbd pool=volumes, profile rbd pool=images, allow rw pool manila_data' ----- -+ -Using the same user across all services makes it simpler to create a common {Ceph} secret that includes the keyring and `ceph.conf` file and propagate the secret to all the services that need it. -* The following shell variables are defined. Replace the following example values with values that are correct for your environment: -+ -[subs=+quotes] ----- -ifeval::["{build}" != "downstream"] -CEPH_SSH="ssh -i ~/install_yamls/out/edpm/ansibleee-ssh-key-id_rsa root@192.168.122.100" -endif::[] -ifeval::["{build}" == "downstream"] -CEPH_SSH="ssh -i ** tripleo-admin@**" -endif::[] -CEPH_KEY=$($CEPH_SSH "cat /etc/ceph/ceph.client.openstack.keyring | base64 -w 0") -CEPH_CONF=$($CEPH_SSH "cat /etc/ceph/ceph.conf | base64 -w 0") ----- - -.Procedure - -. Create the `ceph-conf-files` secret that includes the {Ceph} configuration: -+ ----- -$ oc apply -f - < - caps mgr = "allow *" - caps mon = "allow r, profile rbd" - caps osd = "pool=vms, profile rbd pool=volumes, profile rbd pool=images, allow rw pool manila_data' - ceph.conf: | - [global] - fsid = 7a1719e8-9c59-49e2-ae2b-d7eb08c695d4 - mon_host = 10.1.1.2,10.1.1.3,10.1.1.4 ----- -+ -where: -+ -`mon_host`:: specifies the addresses of the cluster's monitors. If you use IPv6, use brackets for the `mon_host`. For example: `mon_host = [v2:[fd00:cccc::100]:3300/0,v1:[fd00:cccc::100]:6789/0]` -+ -[NOTE] -==== -For Distributed Compute Node (DCN) deployments with multiple {Ceph} clusters, create one secret per site. Each secret contains only the keys that the respective site requires. For more information on the rationale and key distribution pattern, see xref:ceph-migration-dcn_{context}[{Ceph} migration for Distributed Compute Node deployments]. - -The {Ceph} configuration files for all clusters are available on the {OpenStackShort} controller at either `/var/lib/tripleo-config/ceph/`, or `/etc/ceph`. Copy them locally and create the per-site secrets: - ----- -$ CEPH_SSH="ssh tripleo-admin@" -$ CEPH_DIR="/var/lib/tripleo-config/ceph" -$ TMPDIR=$(mktemp -d) - -$ $CEPH_SSH "cat ${CEPH_DIR}/central.conf" > ${TMPDIR}/central.conf -$ $CEPH_SSH "sudo cat ${CEPH_DIR}/central.client.openstack.keyring" > ${TMPDIR}/central.client.openstack.keyring -$ $CEPH_SSH "cat ${CEPH_DIR}/dcn1.conf" > ${TMPDIR}/dcn1.conf -$ $CEPH_SSH "sudo cat ${CEPH_DIR}/dcn1.client.openstack.keyring" > ${TMPDIR}/dcn1.client.openstack.keyring -$ $CEPH_SSH "cat ${CEPH_DIR}/dcn2.conf" > ${TMPDIR}/dcn2.conf -$ $CEPH_SSH "sudo cat ${CEPH_DIR}/dcn2.client.openstack.keyring" > ${TMPDIR}/dcn2.client.openstack.keyring - -# Central site secret: contains all clusters -$ oc create secret generic ceph-conf-central \ - --from-file=${TMPDIR}/central.conf \ - --from-file=${TMPDIR}/central.client.openstack.keyring \ - --from-file=${TMPDIR}/dcn1.conf \ - --from-file=${TMPDIR}/dcn1.client.openstack.keyring \ - --from-file=${TMPDIR}/dcn2.conf \ - --from-file=${TMPDIR}/dcn2.client.openstack.keyring \ - -n openstack - -# DCN1 edge site secret: central + local only -$ oc create secret generic ceph-conf-dcn1 \ - --from-file=${TMPDIR}/central.conf \ - --from-file=${TMPDIR}/central.client.openstack.keyring \ - --from-file=${TMPDIR}/dcn1.conf \ - --from-file=${TMPDIR}/dcn1.client.openstack.keyring \ - -n openstack - -# DCN2 edge site secret: central + local only -$ oc create secret generic ceph-conf-dcn2 \ - --from-file=${TMPDIR}/central.conf \ - --from-file=${TMPDIR}/central.client.openstack.keyring \ - --from-file=${TMPDIR}/dcn2.conf \ - --from-file=${TMPDIR}/dcn2.client.openstack.keyring \ - -n openstack - -$ rm -rf ${TMPDIR} ----- - -Repeat for each additional edge site. Each edge site secret must include the central cluster files and only the files for that edge site's local cluster. - -When configuring `extraMounts` on the `OpenStackControlPlane`, use propagation labels matching the service instance names (for example, `central`, `dcn1`, `dcn2`) so that each pod mounts only its site-specific secret. -==== - -. In your `OpenStackControlPlane` CR, inject the {Ceph} configuration into the {OpenStackShort} service pods using `extraMounts`. For a single-cluster deployment, propagate one secret to all services: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch ' -spec: - extraMounts: - - name: v1 - region: r1 - extraVol: - - propagation: - - CinderVolume - - CinderBackup - - GlanceAPI - - ManilaShare - extraVolType: Ceph - volumes: - - name: ceph - projected: - sources: - - secret: - name: ceph-conf-files - mounts: - - name: ceph - mountPath: "/etc/ceph" - readOnly: true -' ----- -+ -For a DCN deployment with per-site secrets, use propagation labels matching each service instance name so that each pod receives only the keys for its site: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch ' -spec: - extraMounts: - - name: v1 - region: r1 - extraVol: - - extraVolType: Ceph - propagation: - - central - - CinderBackup - - ManilaShare - volumes: - - name: ceph-central - projected: - sources: - - secret: - name: ceph-conf-central - mounts: - - name: ceph-central - mountPath: "/etc/ceph" - readOnly: true - - extraVolType: Ceph - propagation: - - dcn1 - volumes: - - name: ceph-dcn1 - projected: - sources: - - secret: - name: ceph-conf-dcn1 - mounts: - - name: ceph-dcn1 - mountPath: "/etc/ceph" - readOnly: true - - extraVolType: Ceph - propagation: - - dcn2 - volumes: - - name: ceph-dcn2 - projected: - sources: - - secret: - name: ceph-conf-dcn2 - mounts: - - name: ceph-dcn2 - mountPath: "/etc/ceph" - readOnly: true -' ----- -+ -The propagation label `central` matches the {image_service} and {block_storage} pod instances named `central`. The `CinderBackup` and `ManilaShare` labels are service-type propagation and apply to all {block_storage} backup and {rhos_component_storage_file} pods, which run only at the central site. Replace `central`, `dcn1`, and `dcn2` with the instance names used in your deployment. diff --git a/docs_user/modules/proc_configuring-control-plane-networking-for-spine-leaf.adoc b/docs_user/modules/proc_configuring-control-plane-networking-for-spine-leaf.adoc deleted file mode 100644 index 2e2c270ea..000000000 --- a/docs_user/modules/proc_configuring-control-plane-networking-for-spine-leaf.adoc +++ /dev/null @@ -1,313 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="configuring-control-plane-networking-for-spine-leaf_{context}"] - -= Configuring control plane networking for spine-leaf topologies - -[role="_abstract"] -Adopt a spine-leaf or Distributed Compute Node (DCN) deployment by updating the control plane networking for communication across sites. Add subnets for remote sites to `NetConfig` custom resources (CR) and add routes to `NetworkAttachmentDefinition` CRs to enable inter-site connectivity. - -.Prerequisites - -* You have deployed the {rhos_long} control plane. -* You have configured a `NetConfig` CR for the central site. For more information, see xref:configuring-isolated-networks_configuring-network[Configuring isolated networks]. -* You have the network topology information for all remote sites, including: -** IP address ranges for each service network at each site -** VLAN IDs for each service network at each site -** Gateway addresses for inter-site routing - -.Procedure - -. Update your existing `NetConfig` CR to add subnets for each remote site. Each service network must include a subnet for the central site and each remote site. Use unique VLAN IDs for each site. For example: -+ -* Central site: VLANs 20-23 -* Edge site 1: VLANs 30-33 -* Edge site 2: VLANs 40-43 -+ -[source,yaml] ----- -apiVersion: network.openstack.org/v1beta1 -kind: NetConfig -metadata: - name: netconfig -spec: - networks: - - name: ctlplane - dnsDomain: ctlplane.example.com - subnets: - - name: - allocationRanges: - - end: 192.168.122.120 - start: 192.168.122.100 - cidr: 192.168.122.0/24 - gateway: 192.168.122.1 - - name: - allocationRanges: - - end: 192.168.133.120 - start: 192.168.133.100 - cidr: 192.168.133.0/24 - gateway: 192.168.133.1 - - name: - allocationRanges: - - end: 192.168.144.120 - start: 192.168.144.100 - cidr: 192.168.144.0/24 - gateway: 192.168.144.1 - - name: internalapi - dnsDomain: internalapi.example.com - subnets: - - name: subnet1 - allocationRanges: - - end: 172.17.0.250 - start: 172.17.0.100 - cidr: 172.17.0.0/24 - vlan: 20 - - name: internalapisite1 - allocationRanges: - - end: 172.17.10.250 - start: 172.17.10.100 - cidr: 172.17.10.0/24 - vlan: 30 - - name: internalapisite2 - allocationRanges: - - end: 172.17.20.250 - start: 172.17.20.100 - cidr: 172.17.20.0/24 - vlan: 40 - - name: storage - dnsDomain: storage.example.com - subnets: - - name: subnet1 - allocationRanges: - - end: 172.18.0.250 - start: 172.18.0.100 - cidr: 172.18.0.0/24 - vlan: 21 - - name: storagesite1 - allocationRanges: - - end: 172.18.10.250 - start: 172.18.10.100 - cidr: 172.18.10.0/24 - vlan: 31 - - name: storagesite2 - allocationRanges: - - end: 172.18.20.250 - start: 172.18.20.100 - cidr: 172.18.20.0/24 - vlan: 41 - - name: tenant - dnsDomain: tenant.example.com - subnets: - - name: subnet1 - allocationRanges: - - end: 172.19.0.250 - start: 172.19.0.100 - cidr: 172.19.0.0/24 - vlan: 22 - - name: tenantsite1 - allocationRanges: - - end: 172.19.10.250 - start: 172.19.10.100 - cidr: 172.19.10.0/24 - vlan: 32 - - name: tenantsite2 - allocationRanges: - - end: 172.19.20.250 - start: 172.19.20.100 - cidr: 172.19.20.0/24 - vlan: 42 ----- -+ -where: - -``:: Specifies a user-defined subnet name for the central site subnet. -``:: Specifies a user-defined subnet for the first DCN edge site. -``:: Specifies a user-defined subnet for the second DCN edge site. -+ -[NOTE] -==== -You must have the `storagemgmt` network on OpenShift nodes when using DCN with Swift storage. It is not necessary when using Red Hat Ceph Storage. -==== - -. Update the `NetworkAttachmentDefinition` CR for the `internalapi` network to include routes to remote site subnets. These `routes` fields enable control plane pods attached to the `internalapi` network, such as OVN Southbound database, to communicate with Compute nodes at remote sites through the central site gateway, and are required for DCN: -+ -[source,yaml] ----- -apiVersion: k8s.cni.cncf.io/v1 -kind: NetworkAttachmentDefinition -metadata: - name: internalapi -spec: - config: | - { - "cniVersion": "0.3.1", - "name": "internalapi", - "type": "macvlan", - "master": "internalapi", - "ipam": { - "type": "whereabouts", - "range": "172.17.0.0/24", - "range_start": "172.17.0.30", - "range_end": "172.17.0.70", - "routes": [ - { "dst": "172.17.10.0/24", "gw": "172.17.0.1" }, - { "dst": "172.17.20.0/24", "gw": "172.17.0.1" } - ] - } - } ----- - -. Update the `NetworkAttachmentDefinition` CR for the `ctlplane` network to include routes to remote site subnets: -+ -[source,yaml] ----- -apiVersion: k8s.cni.cncf.io/v1 -kind: NetworkAttachmentDefinition -metadata: - name: ctlplane -spec: - config: | - { - "cniVersion": "0.3.1", - "name": "ctlplane", - "type": "macvlan", - "master": "ospbr", - "ipam": { - "type": "whereabouts", - "range": "192.168.122.0/24", - "range_start": "192.168.122.30", - "range_end": "192.168.122.70", - "routes": [ - { "dst": "192.168.133.0/24", "gw": "192.168.122.1" }, - { "dst": "192.168.144.0/24", "gw": "192.168.122.1" } - ] - } - } ----- - -. Update the `NetworkAttachmentDefinition` CR for the `storage` network to include routes to remote site subnets: -+ -[source,yaml] ----- -apiVersion: k8s.cni.cncf.io/v1 -kind: NetworkAttachmentDefinition -metadata: - name: storage -spec: - config: | - { - "cniVersion": "0.3.1", - "name": "storage", - "type": "macvlan", - "master": "storage", - "ipam": { - "type": "whereabouts", - "range": "172.18.0.0/24", - "range_start": "172.18.0.30", - "range_end": "172.18.0.70", - "routes": [ - { "dst": "172.18.10.0/24", "gw": "172.18.0.1" }, - { "dst": "172.18.20.0/24", "gw": "172.18.0.1" } - ] - } - } ----- - -. Update the `NetworkAttachmentDefinition` CR for the `tenant` network to include routes to remote site subnets: -+ -[source,yaml] ----- -apiVersion: k8s.cni.cncf.io/v1 -kind: NetworkAttachmentDefinition -metadata: - name: tenant -spec: - config: | - { - "cniVersion": "0.3.1", - "name": "tenant", - "type": "macvlan", - "master": "tenant", - "ipam": { - "type": "whereabouts", - "range": "172.19.0.0/24", - "range_start": "172.19.0.30", - "range_end": "172.19.0.70", - "routes": [ - { "dst": "172.19.10.0/24", "gw": "172.19.0.1" }, - { "dst": "172.19.20.0/24", "gw": "172.19.0.1" } - ] - } - } ----- -+ -[NOTE] -==== -Adjust the IP ranges, subnets, and gateway addresses in all NAD configurations to match your network topology. The `master` interface name must match the interface on the OpenShift nodes where the VLAN is configured. -==== - -. If you have already deployed OVN services, restart the OVN Southbound database pods to pick up the new routes: -+ ----- -$ oc delete pod -l service=ovsdbserver-sb ----- -+ -The pods are automatically recreated with the updated network configuration. - -. Configure the {networking_first_ref} to recognize all site physnets. In the `OpenStackControlPlane` CR, ensure the Networking service configuration includes all physnets: -+ -[source,yaml] ----- -apiVersion: core.openstack.org/v1beta1 -kind: OpenStackControlPlane -metadata: - name: openstack -spec: - neutron: - template: - customServiceConfig: | - [ml2_type_vlan] - network_vlan_ranges = leaf0:1:1000,leaf1:1:1000,leaf2:1:1000 - [ovn] - ovn_emit_need_to_frag = false ----- -+ -where: - -leaf0:: Represents the physnet for the central site. -leaf1:: Represents the physnet for the first remote site. -leaf2:: Represents the physnet for the second remote site. -+ -[NOTE] -==== -Adjust the physnet names to match your {rhos_prev_long} deployment. Common conventions include `leaf0/leaf1/leaf2` or `datacentre/dcn1/dcn2`. -==== - -.Verification - -. Verify that the `NetConfig` CR is created with all subnets: -+ ----- -$ oc get netconfig netconfig -o yaml | grep -A2 "name: subnet1\|name: .*site" ----- - -. Verify that each `NetworkAttachmentDefinition` includes routes to remote site subnets: -+ ----- -for nad in ctlplane internalapi storage tenant; do - echo "=== $nad ===" - oc get net-attach-def $nad -o jsonpath='{.spec.config}' | jq '.ipam.routes -done ----- - -. After restarting OVN SB pods, verify they have routes to remote site subnets: -+ ----- -$ oc exec $(oc get pod -l service=ovsdbserver-sb -o name | head -1) -- ip route show | grep 172.17 ----- -+ -Sample output: -+ ----- -172.17.10.0/24 via 172.17.0.1 dev internalapi -172.17.20.0/24 via 172.17.0.1 dev internalapi ----- diff --git a/docs_user/modules/proc_configuring-data-plane-nodes.adoc b/docs_user/modules/proc_configuring-data-plane-nodes.adoc deleted file mode 100644 index 36788fead..000000000 --- a/docs_user/modules/proc_configuring-data-plane-nodes.adoc +++ /dev/null @@ -1,78 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="configuring-data-plane-nodes_{context}"] - -= Configuring isolated networks on data plane nodes - -[role="_abstract"] -Data plane nodes are configured by the OpenStack Operator and your `OpenStackDataPlaneNodeSet` custom resources (CRs). The `OpenStackDataPlaneNodeSet` CRs define your desired network configuration for the nodes. - -Your {rhos_long} network configuration should reflect the existing {rhos_prev_long} ({OpenStackShort}) network setup. You must pull the `network_data.yaml` files from each {OpenStackShort} node and reuse them when you define the `OpenStackDataPlaneNodeSet` CRs. The format of the configuration does not change, so you can put network templates under `edpm_network_config_template` variables, either for all nodes or for each node. - -.Procedure - -. Configure a `NetConfig` CR with your desired VLAN tags and IPAM configuration. For example: -+ -[subs="+quotes"] ----- -apiVersion: network.openstack.org/v1beta1 -kind: NetConfig -metadata: - name: netconfig -spec: - networks: - - name: internalapi - dnsDomain: internalapi.example.com - subnets: - - name: subnet1 - allocationRanges: - - end: 172.17.0.250 - start: 172.17.0.100 - cidr: 172.17.0.0/24 - vlan: 20 - - name: storage - dnsDomain: storage.example.com - subnets: - - name: subnet1 - allocationRanges: - - end: 172.18.0.250 - start: 172.18.0.100 - cidr: 172.18.0.0/24 - vlan: 21 - - name: tenant - dnsDomain: tenant.example.com - subnets: - - name: subnet1 - allocationRanges: - - end: 172.19.0.250 - start: 172.19.0.100 - cidr: 172.19.0.0/24 - vlan: 22 ----- -+ -where: - -spec.networks:: Specifies the `networks` composition. The `networks` composition must match the source cloud configuration to avoid data plane connectivity downtime. - -. Optional: In the `NetConfig` CR, list multiple ranges for the `allocationRanges` field to exclude some of the IP addresses, for example, to accommodate IP addresses that are already consumed by the adopted environment: -+ ----- -apiVersion: network.openstack.org/v1beta1 -kind: NetConfig -metadata: - name: netconfig -spec: - networks: - - name: internalapi - dnsDomain: internalapi.example.com - subnets: - - name: subnet1 - allocationRanges: - - end: 172.17.0.199 - start: 172.17.0.100 - - end: 172.17.0.250 - start: 172.17.0.201 - cidr: 172.17.0.0/24 - vlan: 20 ----- -+ -This example excludes the `172.17.0.200` address from the pool. diff --git a/docs_user/modules/proc_configuring-dcn-data-plane-nodesets.adoc b/docs_user/modules/proc_configuring-dcn-data-plane-nodesets.adoc deleted file mode 100644 index 50271a2d4..000000000 --- a/docs_user/modules/proc_configuring-dcn-data-plane-nodesets.adoc +++ /dev/null @@ -1,286 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="configuring-dcn-data-plane-nodesets_{context}"] - -= Configuring data plane node sets for DCN sites - -[role="_abstract"] -If you are adopting a Distributed Compute Node (DCN) deployment, you must create separate `OpenStackDataPlaneNodeSet` custom resources (CRs) for each site. Each node set requires site-specific configuration for network subnets, OVN bridge mappings, and inter-site routes. - -.Prerequisites - -* You have adopted the {rhos_prev_long} ({OpenStackShort}) control plane to {rhos_long}. -* You have configured control plane networking for your spine-leaf topology, including multi-subnet `NetConfig` and `NetworkAttachmentDefinition` CRs with routes to remote sites. For more information, see xref:configuring-control-plane-networking-for-spine-leaf_adopt-control-plane[Configuring control plane networking for spine-leaf topologies]. -* You have the network configuration information for each DCN site: -** IP addresses and hostnames for all Compute nodes -** VLAN IDs for each service network -** Gateway addresses for inter-site routing -* You have identified the OVN bridge mappings (physnets) for each site. - -.Procedure - -. Define the OVN bridge mappings for each site. Each site requires a unique physnet that maps to the local provider network bridge: -+ -.Example OVN bridge mappings -[options="header"] -|=== -| Site | OVN bridge mapping -| Central | `leaf0:br-ex` -| DCN1 | `leaf1:br-ex` -| DCN2 | `leaf2:br-ex` -|=== - -. Create an `OpenStackDataPlaneNodeSet` CR for the central site Compute nodes: -+ -[source,yaml,subs="+quotes"] ----- -apiVersion: dataplane.openstack.org/v1beta1 -kind: OpenStackDataPlaneNodeSet -metadata: - name: openstack-edpm -spec: - tlsEnabled: false - networkAttachments: - - ctlplane - preProvisioned: true - services: -ifeval::["{build}" == "downstream"] - - redhat -endif::[] - - bootstrap - - download-cache - - configure-network - - validate-network - - install-os - - configure-os - - ssh-known-hosts - - run-os - - reboot-os - - install-certs - - ovn - - neutron-metadata - - libvirt - - nova-cell1 - - telemetry - nodeTemplate: - ansibleSSHPrivateKeySecret: dataplane-adoption-secret - ansible: - ansibleUser: tripleo-admin - ansibleVars: - *edpm_ovn_bridge_mappings: ["leaf0:br-ex"]* - edpm_ovn_bridge: br-int - edpm_ovn_encap_type: geneve - # Network configuration template for central site - edpm_network_config_template: | - --- - network_config: - - type: ovs_bridge - name: {{ neutron_physical_bridge_name }} - use_dhcp: false - dns_servers: {{ ctlplane_dns_nameservers }} - addresses: - - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_cidr }} - routes: {{ ctlplane_host_routes }} - members: - - type: interface - name: nic1 - primary: true - {% for network in nodeset_networks %} - - type: vlan - vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }} - addresses: - - ip_netmask: - {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }} - routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }} - {% endfor %} - nodes: - compute-0: - hostName: compute-0.example.com - ansible: - ansibleHost: compute-0.example.com - networks: - - defaultRoute: true - fixedIP: 192.168.122.100 - name: ctlplane - *subnetName: subnet1* - - name: internalapi - *subnetName: subnet1* - - name: storage - subnetName: subnet1 - - name: tenant - subnetName: subnet1 ----- -* The OVN bridge mapping uses the central site physnet `leaf0`. -* Central site nodes reference `subnet1` for all networks. - -. Create an `OpenStackDataPlaneNodeSet` CR for DCN1 edge site Compute nodes. You must add inter-site routes to the network configuration template: -+ -[source,yaml,subs="+quotes"] ----- -apiVersion: dataplane.openstack.org/v1beta1 -kind: OpenStackDataPlaneNodeSet -metadata: - name: openstack-edpm-dcn1 -spec: - tlsEnabled: false - networkAttachments: - - ctlplane - preProvisioned: true - services: - - redhat - - bootstrap - - download-cache - - configure-network - - validate-network - - install-os - - configure-os - - ssh-known-hosts - - run-os - - reboot-os - - install-certs - - ovn - - neutron-metadata - - libvirt - - nova-cell1 - - telemetry - nodeTemplate: - ansibleSSHPrivateKeySecret: dataplane-adoption-secret - ansible: - ansibleUser: tripleo-admin - ansibleVars: - *edpm_ovn_bridge_mappings: ["leaf1:br-ex"]* - edpm_ovn_bridge: br-int - edpm_ovn_encap_type: geneve - # Network configuration template for DCN1 site with inter-site routes - edpm_network_config_template: | - --- - network_config: - - type: ovs_bridge - name: {{ neutron_physical_bridge_name }} - use_dhcp: false - dns_servers: {{ ctlplane_dns_nameservers }} - addresses: - - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_cidr }} - routes: # <3> - {{ ctlplane_host_routes }} - *- ip_netmask: 192.168.122.0/24* - *next_hop: 192.168.133.1* - - ip_netmask: 192.168.144.0/24 - next_hop: 192.168.133.1 - members: - - type: interface - name: nic1 - primary: true - {% for network in nodeset_networks %} - - type: vlan - vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }} - addresses: - - ip_netmask: - {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }} - routes: - {{ lookup('vars', networks_lower[network] ~ '_host_routes') }} - {% if network == 'internalapi' %} - *- ip_netmask: 172.17.0.0/24* - *next_hop: 172.17.10.1* - - ip_netmask: 172.17.20.0/24 - next_hop: 172.17.10.1 - {% endif %} - {% if network == 'storage' %} - - ip_netmask: 172.18.0.0/24 - next_hop: 172.18.10.1 - - ip_netmask: 172.18.20.0/24 - next_hop: 172.18.10.1 - {% endif %} - {% if network == 'tenant' %} - - ip_netmask: 172.19.0.0/24 - next_hop: 172.19.10.1 - - ip_netmask: 172.19.20.0/24 - next_hop: 172.19.10.1 - {% endif %} - {% endfor %} - nodes: - dcn1-compute-0: - hostName: dcn1-compute-0.example.com - ansible: - ansibleHost: dcn1-compute-0.example.com - networks: - - defaultRoute: true - fixedIP: 192.168.133.100 - name: ctlplane - *subnetName: ctlplanedcn1* - - name: internalapi - *subnetName: internalapidcn1* - - name: storage - *subnetName: storagedcn1* - - name: tenant - *subnetName: tenantdcn1* ----- -* DCN1 uses the `leaf1` physnet for its OVN bridge mapping under `spec:nodeTemplate:ansible:ansibleVars:edpm_ovn_bridge_mappings`. -* Inter-site routes must be added to the network configuration template. These routes enable DCN1 compute nodes to reach the central site (192.168.122.0/24) and other DCN sites (192.168.144.0/24 for DCN2). Similar routes are added for each service network (internalapi, storage, tenant). -* DCN1 nodes reference site-specific subnet names like `ctlplanedcn1` and `internalapidcn1`. These subnet names must match those defined in the `NetConfig` CR. - -. Repeat step 3 for all other DCN sites. Adjust site specific parameters: -+ -* The nodeset name, for example: `openstack-edpm-dcn2` -* The OVN bridge mapping, for example: `leaf2:br-ex` -* The subnet names, for example: `ctlplanedcn2`, and `internalapidcn2` -* The inter-site routes. The routes from DCN2 should point to the central site subnets and the DCN1 site subnets. -* The compute node definitions with site-appropriate IP addresses. - -. Deploy all nodesets by creating an `OpenStackDataPlaneDeployment` CR: -+ -[source,yaml] ----- -apiVersion: dataplane.openstack.org/v1beta1 -kind: OpenStackDataPlaneDeployment -metadata: - name: openstack-edpm-deployment -spec: - nodeSets: - - openstack-edpm - - openstack-edpm-dcn1 - - openstack-edpm-dcn2 ----- -+ -[NOTE] -==== -All nodesets can be deployed in parallel once the control plane adoption is complete. -==== - -. Wait for the deployment to complete: -+ ----- -$ oc wait --for condition=Ready openstackdataplanedeployment/openstack-edpm-deployment --timeout=40m ----- - -.Verification - -. Verify that all node sets reach the `Ready` status: -+ ----- -$ oc get openstackdataplanenodeset -NAME STATUS MESSAGE -openstack-edpm True Ready -openstack-edpm-dcn1 True Ready -openstack-edpm-dcn2 True Ready ----- - -. Verify that Compute services are running across all sites. Ensure that all `nova-compute` services show `State=up` for nodes in all availability zones: -+ ----- -$ oc exec openstackclient -- openstack compute service list ----- - -. Verify inter-site connectivity by checking routes on a DCN Compute node: -+ ----- -$ ssh dcn1-compute-0 ip route show | grep 172.17.0 -172.17.0.0/24 via 172.17.10.1 dev internalapi ----- - -. Test that DCN Compute nodes can reach the control plane: -+ ----- -$ ssh dcn1-compute-0 ping -c 3 172.17.0.30 ----- -+ -Replace `172.17.0.30` with an IP address of a control plane service on the internalapi network. diff --git a/docs_user/modules/proc_configuring-federation-for-keystone.adoc b/docs_user/modules/proc_configuring-federation-for-keystone.adoc deleted file mode 100644 index d8ad965b4..000000000 --- a/docs_user/modules/proc_configuring-federation-for-keystone.adoc +++ /dev/null @@ -1,127 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="configuring-federation-for-keystone_{context}"] - -= Configuring OIDC federation for the Identity service - -[role="_abstract"] -To allow the {identity_service_first_ref} to trust an external OpenID Connect (OIDC) identity provider, apply the federation configuration and verify that federated users can authenticate. - -.Prerequisites - -* Keycloak is reachable from your {rhos_long} cluster. -* You have access to the Keycloak `keycloak-ca.crt` file that corresponds to its certificate chain. - -.Procedure - -. Create the `keycloakca` secret so that the {identity_service} pods trust the Keycloak certificate authority (CA): -+ ----- -$ oc create secret generic keycloakca \ - --from-file=KeyCloakCA= -n openstack ----- -+ -where: - -``:: Specifies the path to the CA file that you want to use. - -. Create the `keystone-httpd-override` secret that provides the Apache HTTPD overrides that are required for OIDC: -+ -[source,yaml] ----- -apiVersion: v1 -kind: Secret -metadata: - name: keystone-httpd-override - namespace: openstack -type: Opaque -stringData: - federation.conf: | - OIDCClaimPrefix "OIDC-" - OIDCResponseType "code" - OIDCScope "openid profile email" - OIDCClaimDelimiter "," - OIDCPassUserInfoAs "payload" - OIDCPassClaimsAs "both" - OIDCProviderMetadataURL "https://keycloak-openstack.apps-crc.testing/auth/realms/openstack/.well-known/openid-configuration" - OIDCClientID "rhoso" - OIDCClientSecret "" - OIDCCryptoPassphrase "" - OIDCOAuthClientID "rhoso" - OIDCOAuthClientSecret "" - OIDCOAuthIntrospectionEndpoint "https://keycloak-openstack.apps-crc.testing/auth/realms/openstack/protocol/openid-connect/token/introspect" - OIDCRedirectURI "https://keystone-public-openstack.apps-crc.testing/v3/auth/OS-FEDERATION/identity_providers/kcIDP/protocols/openid/websso/" - LogLevel debug - - - AuthType "openid-connect" - Require valid-user - - - - AuthType oauth20 - Require valid-user - - - - AuthType "openid-connect" - Require valid-user - ----- -+ -where: - -``:: Specifies the client ID to use for the OIDC provider handshake. You must get the client ID from your SSO administrator. -``:: Specifies the client secret to use for the OIDC provider handshake. You must get the client secret from your SSO administrator after providing your redirect URLs. -`` and ``:: Specifies the chosen string that creates your unique redirect URL. - -. Patch the `OpenStackControlPlane` custom resource (CR) to enable OIDC federation for Keystone. Ensure that you merge the patch with any existing custom configuration for the {identity_service}: -+ -[source,yaml] ----- -spec: - tls: - caBundleSecretName: keycloakca - keystone: - template: - customServiceConfig: | - [token] - expiration = 360000 - [federation] - trusted_dashboard=https://horizon-openstack.apps-crc.testing/dashboard/auth/websso/ - sso_callback_template=/etc/keystone/sso_callback_template.html - [openid] - remote_id_attribute=HTTP_OIDC_ISS - [auth] - methods = password,token,oauth1,mapped,application_credential,openid - [trusted_ip] - trusted_forwarded_for_header=True - httpdCustomization: - customConfigSecret: keystone-httpd-override ----- -+ - -.Verification - -. Request a federated token before adoption: -+ ----- -$ openstack token issue ----- -+ -This command should return an access token that is issued for the federated user. - -. Verify the token against the newly adopted {identity_service} instance: -+ ----- -$ oc exec -t openstackclient -- env -u OS_CLOUD - \ - OS_AUTH_URL=https://keystone-public-openstack.apps-crc.testing/v3 \ - OS_AUTH_TYPE=v3oidcaccesstoken \ - OS_ACCESS_TOKEN=$(openstack token issue -f value -c id) \ - openstack project show ----- -+ -where: - -``:: Replace with the ID of your OpenStack project. -+ -A successful response confirms that the federated OIDC configuration is active on the podified Keystone deployment. diff --git a/docs_user/modules/proc_configuring-ldap-with-domain-specific-drivers.adoc b/docs_user/modules/proc_configuring-ldap-with-domain-specific-drivers.adoc deleted file mode 100644 index edddd9097..000000000 --- a/docs_user/modules/proc_configuring-ldap-with-domain-specific-drivers.adoc +++ /dev/null @@ -1,135 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id='configuring-ldap-with-domain-specific-drivers_{context}'] - -= Configuring LDAP with domain-specific drivers - -[role="_abstract"] -If you need to integrate the {identity_service_first_ref} with one or more LDAP servers using domain-specific configurations, you can enable domain-specific drivers and provide the necessary LDAP settings. - -This involves two main steps: - -. Create the secret that holds the domain-specific LDAP configuration files that the {identity_service} uses. Each file within the secret corresponds to an LDAP domain. -. Patch the `OpenStackControlPlane` custom resource (CR) to enable domain-specific drivers for the {identity_service} and mount a secret that contains the LDAP configurations. - - -.Procedure - -. To create the `keystone-domains` secret that stores the actual LDAP configuration files that {identity_service} uses, create a local file that includes your LDAP configuration, for example, `keystone.myldapdomain.conf`: -+ -The following example file includes the configuration for a single LDAP domain. If you have multiple LDAP domains, create a configuration file for each, for example, `keystone.DOMAIN_ONE.conf`, `keystone.DOMAIN_TWO.conf`. -+ -[source,ini] ----- -[identity] -driver = ldap -[ldap] -url = ldap://: -user = -password = -suffix = -query_scope = sub -# User configuration -user_tree_dn = -user_objectclass = -user_id_attribute = -user_name_attribute = -user_mail_attribute = -user_enabled_attribute = -user_enabled_default = true -# Group configuration -group_tree_dn = -group_objectclass = -group_id_attribute = -group_name_attribute = -group_member_attribute = -group_members_are_ids = true ----- -+ -* Replace the values, such as ``, ``, ``, and so on, with your LDAP server details. - -. Create the secret from this file: -+ ----- -$ oc create secret generic keystone-domains --from-file= ----- -+ -* Replace `` with the name of your local configuration file. If applicable, include additional configuration files by using the `--from-file` option. After creating the secret, you can remove the local configuration file if it is no longer needed, or store it securely. -+ -[IMPORTANT] -The name of the file that you provide to `--from-file`, for example `keystone.DOMAIN_NAME.conf`, is critical. The {identity_service} uses this filename to map incoming authentication requests for a domain to the correct LDAP configuration. Ensure that `DOMAIN_NAME` matches the name of the domain you are configuring in the {identity_service}. - -. Patch the `OpenStackControlPlane` CR: -+ ----- -$ oc patch openstackcontrolplane --type=merge -p ' -spec: - keystone: - template: - customServiceConfig: | - [identity] - domain_specific_drivers_enabled = true - extraMounts: - - name: v1 - region: r1 - extraVol: - - propagation: - - Keystone - extraVolType: Conf - volumes: - - name: keystone-domains - secret: - secretName: keystone-domains - mounts: - - name: keystone-domains - mountPath: "/etc/keystone/domains" - readOnly: true ----- -+ -* Replace `` with the name of your `OpenStackControlPlane` CR (for example, `openstack`). -* This patch does the following: -** Sets `spec.keystone.template.customServiceConfig`. Ensure that you do not overwrite any previously defined value. -** Defines `spec.keystone.template.extraMounts` to mount a secret named `keystone-domains` into the {identity_service} pods at `/etc/keystone/domains`. This secret contains your LDAP configuration files. -+ -[NOTE] -You might need to wait a few minutes for the changes to propagate and for the {identity_service} pods to be updated. - -.Verification - -. Verify that users from the LDAP domain are accessible: -+ ----- -$ oc exec -t openstackclient -- openstack user list --domain ----- -+ -* Replace `` with your LDAP domain name. -+ -This command returns a list of users from your LDAP server. - -. Verify that groups from the LDAP domain are accessible: -+ ----- -$ oc exec -t openstackclient -- openstack group list --domain ----- -+ -This command returns a list of groups from your LDAP server. - -. Test authentication with an LDAP user: -+ ----- -$ oc exec -t openstackclient -- openstack --os-auth-url --os-identity-api-version 3 --os-user-domain-name --os-username --os-password token issue ----- -+ -* Replace `` with the {identity_service} authentication URL. -* Replace `` and `` with valid LDAP user credentials. -+ -If successful, this command returns a token, confirming that LDAP authentication is working correctly. - -. Verify group membership for an LDAP user: -+ ----- -$ oc exec -t openstackclient -- openstack group contains user --group-domain --user-domain ----- -+ -* Replace ``, ``, and `` with the appropriate values from your LDAP server. -+ -This command verifies that the user is properly associated with the group through LDAP. diff --git a/docs_user/modules/proc_configuring-networking-for-control-plane-services.adoc b/docs_user/modules/proc_configuring-networking-for-control-plane-services.adoc deleted file mode 100644 index 34a3bb692..000000000 --- a/docs_user/modules/proc_configuring-networking-for-control-plane-services.adoc +++ /dev/null @@ -1,136 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="configuring-networking-for-control-plane-services_{context}"] - -= Configuring isolated networks on control plane services - -[role="_abstract"] -After the NMState operator creates the required hypervisor network configuration for isolated networks, configure {rhos_prev_long} services to use isolated network interfaces by defining `NetworkAttachmentDefinition` CRs for each network. - -In clusters managed by Cluster Network Operator, use `Network` CRs instead. - -For more information, see -link:{defaultOCPURL}/networking/cluster-network-operator#nw-cluster-network-operator_cluster-network-operator[Cluster Network Operator] in _Networking_. - -.Procedure - -. Define a `NetworkAttachmentDefinition` CR for each isolated network. -For example: -+ ----- -apiVersion: k8s.cni.cncf.io/v1 -kind: NetworkAttachmentDefinition -metadata: - name: internalapi -spec: - config: | - { - "cniVersion": "0.3.1", - "name": "internalapi", - "type": "macvlan", - "master": "enp6s0.20", - "ipam": { - "type": "whereabouts", - "range": "172.17.0.0/24", - "range_start": "172.17.0.20", - "range_end": "172.17.0.50" - } - } ----- -+ -[IMPORTANT] -Ensure that the interface name and IPAM range match the configuration that you used in the `NodeNetworkConfigurationPolicy` CRs. - -. Optional: When reusing existing IP ranges, you can exclude part of the range that is used in the existing deployment by using the `exclude` parameter in the `NetworkAttachmentDefinition` pool. For example: -+ ----- -apiVersion: k8s.cni.cncf.io/v1 -kind: NetworkAttachmentDefinition -metadata: - name: internalapi -spec: - config: | - { - "cniVersion": "0.3.1", - "name": "internalapi", - "type": "macvlan", - "master": "enp6s0.20", - "ipam": { - "type": "whereabouts", - "range": "172.17.0.0/24", - "range_start": "172.17.0.20", - "range_end": "172.17.0.50", - "exclude": [ - "172.17.0.24/32", - "172.17.0.44/31" - ] - } - } ----- -+ -* `spec.config.ipam.range_start` defines the start of the IP range. -* `spec.config.ipam.range_end` defines the end of the IP range. -* `spec.config.ipam.exclude` excludes part of the IP range. This example excludes IP addresses `172.17.0.24/32` and `172.17.0.44/31` from the allocation pool. - -. If your {OpenStackShort} services require load balancer IP addresses, define the pools for these services in an `IPAddressPool` CR. For example: -+ -[NOTE] -The load balancer IP addresses belong to the same IP range as the control plane services, and are managed by MetalLB. This pool should also be aligned with the {OpenStackShort} configuration. -+ ----- -- apiVersion: metallb.io/v1beta1 - kind: IPAddressPool - spec: - addresses: - - 172.17.0.60-172.17.0.70 ----- -+ -Define `IPAddressPool` CRs for each isolated network that requires load -balancer IP addresses. - -. Optional: When reusing existing IP ranges, you can exclude part of the range by listing multiple entries in the `addresses` section of the `IPAddressPool`. For example: -+ ----- -- apiVersion: metallb.io/v1beta1 - kind: IPAddressPool - spec: - addresses: - - 172.17.0.60-172.17.0.64 - - 172.17.0.66-172.17.0.70 ----- -+ -The example above would exclude the `172.17.0.65` address from the allocation -pool. - -. For environments that are enabled with border gateway protocol (BGP), add routes to the `NetworkAttachmentDefinition` CRs so that the pods can communicate with the {rhos_prev_long} Controller nodes and Compute nodes over the isolated networks. This is similar to the routes that should be added to the `NodeNetworkConfigurationPolicy` CRs in BGP environments. For more information about isolated networks, see xref:configuring-openshift-worker-nodes_{context}[Configuring isolated networks on RHOCP worker nodes]. The following example shows a `NetworkAttachmentDefinition` CR for the storage network with routes: -+ ----- -apiVersion: k8s.cni.cncf.io/v1 -kind: NetworkAttachmentDefinition -metadata: - name: storage - namespace: openstack -spec: - config: | - { - "cniVersion": "0.3.1", - "name": "storage", - "type": "bridge", - "isDefaultGateway": false, - "isGateway": true, - "forceAddress": false, - "hairpinMode": true, - "ipMasq": false, - "bridge": "storage", - "ipam": { - "type": "whereabouts", - "range": "172.18.0.0/24", - "range_start": "172.18.0.30", - "range_end": "172.18.0.70", - "routes": [ - {"dst": "172.31.0.0/24", "gw": "172.18.0.1"}, - {"dst": "192.168.188.0/24", "gw": "172.18.0.1"}, - {"dst": "99.99.0.0/16", "gw": "172.18.0.1"} - ] - } - } ----- diff --git a/docs_user/modules/proc_configuring-openshift-worker-nodes.adoc b/docs_user/modules/proc_configuring-openshift-worker-nodes.adoc deleted file mode 100644 index acab62d75..000000000 --- a/docs_user/modules/proc_configuring-openshift-worker-nodes.adoc +++ /dev/null @@ -1,131 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="configuring-openshift-worker-nodes_{context}"] - -= Configuring isolated networks on {OpenShiftShort} worker nodes - -[role="_abstract"] -To connect service pods to isolated networks on {rhocp_long} worker nodes that run {rhos_prev_long} services, physical network configuration on the hypervisor is required. - -This configuration is managed by the NMState operator, which uses `NodeNetworkConfigurationPolicy` custom resources (CRs) to define the desired network configuration for the nodes. - -// TODO: Move this to the IPv6 section once it is fully documented, both upstream and downstream. -ifeval::["{build}" != "downstream"] -[WARNING] -In IPv6, {rhocp_long} worker nodes need a `/64` prefix allocation due to OVN -limitations (RFC 4291). For dynamic IPv6 configuration, you need to change the -prefix allocation on the Router Advertisement settings. If you want to use -manual configuration for IPv6, define a similar CR to the -`NodeNetworkConfigurationPolicy` CR example in this procedure, and define an -IPv6 address and disable IPv4. Because the constraint for the `/64` prefix did -not exist in {OpenstackPreviousInstaller}, your {OpenStackShort} -control plane network might not have enough capacity to allocate these -networks. If that is the case, allocate a prefix that fits a large enough number -of addresses, for example, `/60`. The prefix depends on the number of worker nodes you have. -endif::[] - -.Procedure - -* For each {OpenShiftShort} worker node, define a `NodeNetworkConfigurationPolicy` CR that describes the desired network configuration. For example: -+ ----- -apiVersion: v1 -items: -- apiVersion: nmstate.io/v1 - kind: NodeNetworkConfigurationPolicy - spec: - desiredState: - interfaces: - - description: internalapi vlan interface - ipv4: - address: - - ip: 172.17.0.10 - prefix-length: 24 - dhcp: false - enabled: true - ipv6: - enabled: false - name: enp6s0.20 - state: up - type: vlan - vlan: - base-iface: enp6s0 - id: 20 - reorder-headers: true - - description: storage vlan interface - ipv4: - address: - - ip: 172.18.0.10 - prefix-length: 24 - dhcp: false - enabled: true - ipv6: - enabled: false - name: enp6s0.21 - state: up - type: vlan - vlan: - base-iface: enp6s0 - id: 21 - reorder-headers: true - - description: tenant vlan interface - ipv4: - address: - - ip: 172.19.0.10 - prefix-length: 24 - dhcp: false - enabled: true - ipv6: - enabled: false - name: enp6s0.22 - state: up - type: vlan - vlan: - base-iface: enp6s0 - id: 22 - reorder-headers: true - nodeSelector: - kubernetes.io/hostname: ocp-worker-0 - node-role.kubernetes.io/worker: "" ----- -+ -[NOTE] -==== -For environments that are enabled with border gateway protocol (BGP), you might need to add additional routes in the `NodeNetworkConfigurationPolicy` CR so that {OpenShiftShort} worker nodes can reach the {rhos_prev_long} Controller nodes and Compute nodes over the control plane and internal API networks. - -When you configure the {OpenShiftShort} worker nodes network in the `NodeNetworkConfigurationPolicy` CR, add routes for each of the following networks: - -* External network (for example, `172.31.0.0/24`) -* Control plane network (for example, `192.168.188.0/24`) -* BGP main network (for example, `99.99.0.0/16`) - -The following example shows the `routes.config` section from a `NodeNetworkConfigurationPolicy` CR for a worker node with BGP configured. In this example, `100.64.0.17` and `100.65.0.17` are the IP addresses of the leaf switches that are connected to the specific {OpenShiftShort} node: - ----- - routes: - config: - - destination: 99.99.0.0/16 - next-hop-address: 100.64.0.17 - next-hop-interface: enp7s0 - weight: 200 - - destination: 99.99.0.0/16 - next-hop-address: 100.65.0.17 - next-hop-interface: enp8s0 - weight: 200 - - destination: 172.31.0.0/24 - next-hop-address: 100.64.0.17 - next-hop-interface: enp7s0 - weight: 200 - - destination: 172.31.0.0/24 - next-hop-address: 100.65.0.17 - next-hop-interface: enp8s0 - weight: 200 - - destination: 192.168.188.0/24 - next-hop-address: 100.64.0.17 - next-hop-interface: enp7s0 - weight: 200 - - destination: 192.168.188.0/24 - next-hop-address: 100.65.0.17 - next-hop-interface: enp8s0 - weight: 200 ----- -==== diff --git a/docs_user/modules/proc_converting-object-storage-nodes.adoc b/docs_user/modules/proc_converting-object-storage-nodes.adoc deleted file mode 100644 index 2ce64cfc3..000000000 --- a/docs_user/modules/proc_converting-object-storage-nodes.adoc +++ /dev/null @@ -1,303 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="converting-object-storage-nodes"] - -= Converting {object_storage} storage nodes - -[role="_abstract"] -If you used external {object_storage} storage nodes, you can convert these -nodes after the initial {object_storage_first_ref} adoption is complete. This -step reconfigures the nodes in-place while keeping the {object_storage} -available throughout the process. - -Before you begin, review the following key concepts: - -Pre-provisioned nodes:: Setting `preProvisioned: true` in the - `OpenStackDataPlaneNodeSet` custom resource (CR) skips provisioning the node from scratch and does not reinstall the operating system. -{object_storage} disk and mount preservation:: `edpm_swift_disks: []` must be - set in both the `nodeTemplate` and in the individual node definition under - `nodes` to ensure that no disks are formatted or mounted differently. - Existing disk mounts are untouched. The `SwiftRawDisks` parameter from - {OpenStackPreviousInstaller} is not migrated or converted. Disks on - converted nodes must be managed manually. -Rolling conversion:: The `swift-conversion` service uses `serial: 1` by - default, which converts one node at a time to keep the {object_storage} - available. - -.Prerequisites - -* The initial {object_storage} adoption is complete. For more information, see - xref:adopting-the-object-storage-service_hsm-integration[Adopting the - {object_storage}]. -* Nodes cannot be members of more than one `OpenStackDataPlaneNodeSet` CR at - the same time. If the nodes you want to convert were part of the node set - that you created during the control plane adoption, delete that node set - before proceeding: -+ ----- -$ oc delete openstackdataplanenodeset ----- -+ -where: - -``:: -Specifies the node set that you want to delete. - -.Procedure - -. Create a patch file to configure the {object_storage} data plane storage - ports: -+ -[NOTE] -The {OpenStackPreviousInstaller} deployment used different default -ports: 6002 for the account server, 6001 for the container server, 6000 for -the object server. The converted nodes must continue to use these same -ports to ensure connectivity between all {object_storage} storage nodes by using -the unmodified rings. -+ ----- -cat > swift-config-patch.yaml << EOF -spec: - swift: - template: - swiftStorage: - defaultConfigOverwrite: - 01-account-server.conf: | - [DEFAULT] - bind_port = 6002 - 01-container-server.conf: | - [DEFAULT] - bind_port = 6001 - 01-object-server.conf: | - [DEFAULT] - bind_port = 6000 -EOF ----- -+ -[NOTE] -If you customized any {object_storage} service settings in the -{OpenStackPreviousInstaller} deployment, include those settings as well. For -example, if you changed the workers count or added additional configuration options -for the account, container, or object services, add them to the -corresponding section in the patch file. - -. Apply the patch to the `OpenStackControlPlane` CR: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch-file=swift-config-patch.yaml ----- - -. Create a `OpenStackDataPlaneService` CR to remove remaining - {OpenStackPreviousInstaller} artifacts and deploy the {object_storage} services - on the node: -+ ----- -$ oc apply -f - < nfs ----- -+ -* Replace `` with the name of the host that you identified. - -. Create the NFS cluster: -+ ----- -$ ceph nfs cluster create cephfs \ - "label:nfs" \ - --ingress \ - --virtual-ip= \ - --ingress-mode=haproxy-protocol ----- -+ -* Replace `` with the VIP for the Ceph NFS service. -+ -ifeval::["{build}" != "downstream"] -[NOTE] -==== -You must set the `ingress-mode` argument to `haproxy-protocol`. No other -ingress-mode is supported. This ingress mode allows you to enforce client -restrictions through the {rhos_component_storage_file}. - -* For more information on deploying the clustered Ceph NFS service, see the -link:https://docs.ceph.com/en/latest/cephadm/services/nfs/[ceph orchestrator -documentation]. -==== -endif::[] -ifeval::["{build}" != "upstream"] -[NOTE] -==== -You must set the `ingress-mode` argument to `haproxy-protocol`. No other -ingress-mode is supported. This ingress mode allows you to enforce client -restrictions through the {rhos_component_storage_file}. -For more information about deploying the clustered Ceph NFS service, see 'Management of NFS-Ganesha gateway using the Ceph Orchestrator' in the _Operations Guide_ for your Red Hat Ceph Storage version: - -* link:https://docs.redhat.com/documentation/en-us/red_hat_ceph_storage/7/html/operations_guide/index#management-of-nfs-ganesha-gateway-using-the-ceph-orchestrator[Red Hat Ceph Storage 7 _Operations Guide_] -* link:https://docs.redhat.com/documentation/en-us/red_hat_ceph_storage/8/html/operations_guide/index#management-of-nfs-ganesha-gateway-using-the-ceph-orchestrator[Red Hat Ceph Storage 8 _Operations Guide_] -* link:https://www.ibm.com/docs/en/{ceph9_pdf_path}/Red_Hat_Ceph_Storage_NFS_cluster_and_share_management_(OpenStack_Manila_users_only).pdf[Red Hat Ceph Storage 9 NFS cluster and share management (OpenStack Manila users only)] > Creating an NFS cluster -==== -endif::[] - -. Check the status of the NFS cluster: -+ ----- -$ ceph nfs cluster ls -$ ceph nfs cluster info cephfs ----- diff --git a/docs_user/modules/proc_decommissioning-rhosp-standalone-ceph-NFS-service.adoc b/docs_user/modules/proc_decommissioning-rhosp-standalone-ceph-NFS-service.adoc deleted file mode 100644 index 8d4bec8d3..000000000 --- a/docs_user/modules/proc_decommissioning-rhosp-standalone-ceph-NFS-service.adoc +++ /dev/null @@ -1,74 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="decommissioning-RHOSP-standalone-Ceph-NFS-service_{context}"] - -= Decommissioning the {rhos_prev_long} standalone Ceph NFS service - -[role="_abstract"] -If your deployment uses CephFS through NFS, you must decommission the {rhos_prev_long}({OpenStackShort}) standalone NFS service. Since future software upgrades do not support the previous NFS service, ensure that the decommissioning period is short. - -.Prerequisites - -* You identified the new export locations for your existing shares by querying the Shared File Systems API. -* You unmounted and remounted the shared file systems on each client to stop using the previous NFS server. -* If you are consuming the {rhos_component_storage_file} shares with the {rhos_component_storage_file} CSI plugin for {rhocp_long}, you migrated the shares by scaling down the application pods and scaling them back up. - -[NOTE] -Clients that are creating new workloads cannot use share exports through the previous NFS service. The {rhos_component_storage_file} no longer communicates with the previous NFS service, and cannot apply or alter export rules on the previous NFS service. - -.Procedure - -. Remove the `cephfs_ganesha_server_ip` option from the `manila-share` service configuration: -+ -[NOTE] -This restarts the `manila-share` process and removes the export locations that applied to the previous NFS service from all the shares. -+ ----- -$ cat << __EOF__ > ~/manila.patch -spec: - manila: - enabled: true - apiOverride: - route: {} - template: - manilaShares: - cephfs: - replicas: 1 - customServiceConfig: | - [DEFAULT] - enabled_share_backends = cephfs - host = hostgroup - [cephfs] - driver_handles_share_servers=False - share_backend_name=cephfs - share_driver=manila.share.drivers.cephfs.driver.CephFSDriver - cephfs_conf_path=/etc/ceph/ceph.conf - cephfs_auth_id=openstack - cephfs_cluster_name=ceph - cephfs_protocol_helper_type=NFS - cephfs_nfs_cluster_id=cephfs - networkAttachments: - - storage -__EOF__ - ----- - -. Patch the `OpenStackControlPlane` custom resource: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch-file=~/ ----- -* Replace `` with the name of your patch file. - -. Clean up the standalone `ceph-nfs` service from the {OpenStackShort} control plane nodes by disabling and deleting the Pacemaker resources associated with the service: -+ -[IMPORTANT] -You can defer this step until after {rhos_acro} {rhos_curr_ver} is operational. During this time, you cannot decommission the Controller nodes. -+ ----- -$ sudo pcs resource disable ceph-nfs -$ sudo pcs resource disable ip- -$ sudo pcs resource unmanage ceph-nfs -$ sudo pcs resource unmanage ip- ----- -+ -* Replace `` with the IP address assigned to the `ceph-nfs` service in your environment. diff --git a/docs_user/modules/proc_deploying-a-ceph-ingress-daemon.adoc b/docs_user/modules/proc_deploying-a-ceph-ingress-daemon.adoc deleted file mode 100644 index 8178d12fc..000000000 --- a/docs_user/modules/proc_deploying-a-ceph-ingress-daemon.adoc +++ /dev/null @@ -1,142 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="deploying-a-ceph-ingress-daemon_{context}"] - -= Deploying a {Ceph} ingress daemon - -[role="_abstract"] -To deploy the Ceph ingress daemon, you perform the following actions: - -. Remove the existing `ceph_rgw` configuration. -. Clean up the configuration created by {OpenStackPreviousInstaller}. -. Redeploy the {object_storage_first_ref}. - -When you deploy the ingress daemon, two new containers are created: - -* HAProxy, which you use to reach the back ends. -* Keepalived, which you use to own the virtual IP address. - -You use the `rgw` label to distribute the ingress daemon to only the number of nodes that host Ceph Object Gateway (RGW) daemons. For more information about distributing daemons among your nodes, see xref:ceph-daemon-cardinality_migrating-ceph[{Ceph} daemon cardinality]. - -After you complete this procedure, you can reach the RGW back end from the ingress daemon and use RGW through the {object_storage} CLI. - -.Procedure - -. Log in to each Controller node and remove the following configuration from the `/var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg` file: -+ ----- -listen ceph_rgw - bind 10.0.0.103:8080 transparent - mode http - balance leastconn - http-request set-header X-Forwarded-Proto https if { ssl_fc } - http-request set-header X-Forwarded-Proto http if !{ ssl_fc } - http-request set-header X-Forwarded-Port %[dst_port] - option httpchk GET /swift/healthcheck - option httplog - option forwardfor - server controller-0.storage.redhat.local 172.17.3.73:8080 check fall 5 inter 2000 rise 2 - server controller-1.storage.redhat.local 172.17.3.146:8080 check fall 5 inter 2000 rise 2 - server controller-2.storage.redhat.local 172.17.3.156:8080 check fall 5 inter 2000 rise 2 ----- - -. Restart `haproxy-bundle` and confirm that it is started: -+ ----- -[root@controller-0 ~]# sudo pcs resource restart haproxy-bundle -haproxy-bundle successfully restarted - - -[root@controller-0 ~]# sudo pcs status | grep haproxy - - * Container bundle set: haproxy-bundle [undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp17-openstack-haproxy:pcmklatest]: - * haproxy-bundle-podman-0 (ocf:heartbeat:podman): Started controller-0 - * haproxy-bundle-podman-1 (ocf:heartbeat:podman): Started controller-1 - * haproxy-bundle-podman-2 (ocf:heartbeat:podman): Started controller-2 ----- - -. Confirm that no process is connected to port 8080: -+ ----- -[root@controller-0 ~]# ss -antop | grep 8080 -[root@controller-0 ~]# ----- -+ -You can expect the {object_storage_first_ref} CLI to fail to establish the connection: -+ ----- -(overcloud) [root@cephstorage-0 ~]# swift list - -HTTPConnectionPool(host='10.0.0.103', port=8080): Max retries exceeded with url: /swift/v1/AUTH_852f24425bb54fa896476af48cbe35d3?format=json (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection refused')) ----- - -. Set the required images for both HAProxy and Keepalived: -+ ----- -ifeval::["{build}" != "downstream"] -[ceph: root@controller-0 /]# ceph config set mgr mgr/cephadm/container_image_haproxy quay.io/ceph/haproxy:2.3 -[ceph: root@controller-0 /]# ceph config set mgr mgr/cephadm/container_image_keepalived quay.io/ceph/keepalived:2.1.5 -endif::[] -ifeval::["{build}" == "downstream"] -[ceph: root@controller-0 /]# ceph config set mgr mgr/cephadm/container_image_haproxy registry.redhat.io/rhceph/rhceph-haproxy-rhel9:latest -[ceph: root@controller-0 /]# ceph config set mgr mgr/cephadm/container_image_keepalived registry.redhat.io/rhceph/keepalived-rhel9:latest -endif::[] ----- - -. Create a file called `rgw_ingress` in `controller-0`: -+ ----- -$ SPEC_DIR=${SPEC_DIR:-"$PWD/ceph_specs"} -$ vim ${SPEC_DIR}/rgw_ingress ----- - -. Paste the following content into the `rgw_ingress` file: -+ -[source,yaml] ----- ---- -service_type: ingress -service_id: rgw.rgw -placement: - label: rgw -spec: - backend_service: rgw.rgw - virtual_ip: 10.0.0.89/24 - frontend_port: 8080 - monitor_port: 8898 - virtual_interface_networks: - - - ssl_cert: ... ----- -+ -* Replace `` with your external network, for example, `10.0.0.0/24`. For more information, see xref:completing-prerequisites-for-migrating-ceph-rgw_ceph-prerequisites[Completing prerequisites for migrating {Ceph} RGW]. -* If TLS is enabled, add the SSL certificate and key concatenation as described in link:{configuring-storage}/assembly_configuring-red-hat-ceph-storage-as-the-backend-for-rhosp-storage#proc_ceph-configure-rgw-with-tls_ceph-back-end[Configuring RGW with TLS for an external Red Hat Ceph Storage cluster] in _{configuring-storage-t}_. - -. Apply the `rgw_ingress` spec by using the Ceph orchestrator CLI: -+ ----- -$ SPEC_DIR=${SPEC_DIR:-"$PWD/ceph_specs"} -$ cephadm shell -m ${SPEC_DIR}/rgw_ingress -- ceph orch apply -i /mnt/rgw_ingress ----- - -. Wait until the ingress is deployed and query the resulting endpoint: -+ ----- -$ sudo cephadm shell -- ceph orch ls - -NAME PORTS RUNNING REFRESHED AGE PLACEMENT -crash 6/6 6m ago 3d * -ingress.rgw.rgw 10.0.0.89:8080,8898 6/6 37s ago 60s label:rgw -mds.mds 3/3 6m ago 3d controller-0;controller-1;controller-2 -mgr 3/3 6m ago 3d controller-0;controller-1;controller-2 -mon 3/3 6m ago 3d controller-0;controller-1;controller-2 -osd.default_drive_group 15 37s ago 3d cephstorage-0;cephstorage-1;cephstorage-2 -rgw.rgw ?:8090 3/3 37s ago 4m label:rgw ----- -+ ----- -$ curl 10.0.0.89:8080 - ---- -anonymous[ceph: root@controller-0 /]# -— ----- diff --git a/docs_user/modules/proc_deploying-backend-services.adoc b/docs_user/modules/proc_deploying-backend-services.adoc deleted file mode 100644 index a1b97daf0..000000000 --- a/docs_user/modules/proc_deploying-backend-services.adoc +++ /dev/null @@ -1,660 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="deploying-backend-services_{context}"] - -= Deploying back-end services - -[role="_abstract"] -Create the `OpenStackControlPlane` custom resource (CR) with the basic back-end services deployed, and disable all the {rhos_prev_long} ({OpenStackShort}) services. This CR is the foundation of the control plane. - -.Prerequisites - -* The cloud that you want to adopt is running, and it is on {OpenStackShort} 17.1.4 or later. -* All control plane and data plane hosts of the source cloud are running, and continue to run throughout the adoption procedure. -* The `openstack-operator` is deployed, but `OpenStackControlPlane` is -not deployed. -ifeval::["{build}" != "downstream"] -+ -For developer/CI environments, the {OpenStackShort} operator can be deployed -by running `make openstack` inside -https://github.com/openstack-k8s-operators/install_yamls[install_yamls] -repo. -+ -For production environments, the deployment method will likely be -different. -endif::[] -ifeval::["{build}" == "downstream"] -* Install the OpenStack Operators. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html-single/deploying_red_hat_openstack_services_on_openshift/index#assembly_installing-and-preparing-the-OpenStack-Operator[Installing and preparing the OpenStack Operator] in _{deploying-rhoso-t}_. -endif::[] - -* If you enabled TLS everywhere (TLS-e) on the {OpenStackShort} environment, you must copy the `tls` root CA from the {OpenStackShort} environment to the `rootca-internal` issuer. - -* There are free PVs available for Galera and RabbitMQ. -ifeval::["{build}" != "downstream"] -+ -For developer/CI environments driven by install_yamls, make sure -you've run `make crc_storage`. -endif::[] -* Set the desired admin password for the control plane deployment. This can -be the admin password from your original deployment or a different password: -+ ----- -ADMIN_PASSWORD=SomePassword ----- -+ -To use the existing {OpenStackShort} deployment password: -+ ----- -declare -A TRIPLEO_PASSWORDS -TRIPLEO_PASSWORDS[default]="$HOME/overcloud-passwords.yaml" -ADMIN_PASSWORD=$(cat ${TRIPLEO_PASSWORDS[default]} | grep ' AdminPassword:' | awk -F ': ' '{ print $2; }') ----- -* Set the service password variables to match the original deployment. -Database passwords can differ in the control plane environment, but -you must synchronize the service account passwords. -+ -For example, in developer environments with {OpenStackPreviousInstaller} Standalone, the passwords can be extracted: -+ ----- -AODH_PASSWORD=$(cat ${TRIPLEO_PASSWORDS[default]} | grep ' AodhPassword:' | awk -F ': ' '{ print $2; }') -BARBICAN_PASSWORD=$(cat ${TRIPLEO_PASSWORDS[default]} | grep ' BarbicanPassword:' | awk -F ': ' '{ print $2; }') -CEILOMETER_METERING_SECRET=$(cat ${TRIPLEO_PASSWORDS[default]} | grep ' CeilometerMeteringSecret:' | awk -F ': ' '{ print $2; }') -CEILOMETER_PASSWORD=$(cat ${TRIPLEO_PASSWORDS[default]} | grep ' CeilometerPassword:' | awk -F ': ' '{ print $2; }') -CINDER_PASSWORD=$(cat ${TRIPLEO_PASSWORDS[default]} | grep ' CinderPassword:' | awk -F ': ' '{ print $2; }') -DESIGNATE_PASSWORD=$(cat ${TRIPLEO_PASSWORDS[default]} | grep ' DesignatePassword:' | awk -F ': ' '{ print $2; }') -GLANCE_PASSWORD=$(cat ${TRIPLEO_PASSWORDS[default]} | grep ' GlancePassword:' | awk -F ': ' '{ print $2; }') -HEAT_AUTH_ENCRYPTION_KEY=$(cat ${TRIPLEO_PASSWORDS[default]} | grep ' HeatAuthEncryptionKey:' | awk -F ': ' '{ print $2; }') -HEAT_PASSWORD=$(cat ${TRIPLEO_PASSWORDS[default]} | grep ' HeatPassword:' | awk -F ': ' '{ print $2; }') -HEAT_STACK_DOMAIN_ADMIN_PASSWORD=$(cat ${TRIPLEO_PASSWORDS[default]} | grep ' HeatStackDomainAdminPassword:' | awk -F ': ' '{ print $2; }') -IRONIC_PASSWORD=$(cat ${TRIPLEO_PASSWORDS[default]} | grep ' IronicPassword:' | awk -F ': ' '{ print $2; }') -MANILA_PASSWORD=$(cat ${TRIPLEO_PASSWORDS[default]} | grep ' ManilaPassword:' | awk -F ': ' '{ print $2; }') -NEUTRON_PASSWORD=$(cat ${TRIPLEO_PASSWORDS[default]} | grep ' NeutronPassword:' | awk -F ': ' '{ print $2; }') -NOVA_PASSWORD=$(cat ${TRIPLEO_PASSWORDS[default]} | grep ' NovaPassword:' | awk -F ': ' '{ print $2; }') -OCTAVIA_PASSWORD=$(cat ${TRIPLEO_PASSWORDS[default]} | grep ' OctaviaPassword:' | awk -F ': ' '{ print $2; }') -PLACEMENT_PASSWORD=$(cat ${TRIPLEO_PASSWORDS[default]} | grep ' PlacementPassword:' | awk -F ': ' '{ print $2; }') -SWIFT_PASSWORD=$(cat ${TRIPLEO_PASSWORDS[default]} | grep ' SwiftPassword:' | awk -F ': ' '{ print $2; }') ----- - -.Procedure - -. Ensure that you are using the {rhocp_long} namespace where you want the -control plane to be deployed: -+ ----- -$ oc project openstack ----- - -ifeval::["{build}" != "downstream"] -. Create the {OpenStackShort} secret. -+ -The procedure for this will vary, but in developer/CI environments -you use `install_yamls`: -+ -[source,yaml] ----- -# in install_yamls -make input ----- -endif::[] - -ifeval::["{build}" == "downstream"] -. Create the {OpenStackShort} secret. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/{rhos_curr_ver}/html-single/deploying_red_hat_openstack_services_on_openshift/index#proc_providing-secure-access-to-the-RHOSO-services_preparing[Providing secure access to the Red Hat OpenStack Services on OpenShift services] in _Deploying Red Hat OpenStack Services on OpenShift_. -endif::[] - -. If the `$ADMIN_PASSWORD` is different than the password you set -in `osp-secret`, amend the `AdminPassword` key in the `osp-secret`: -+ ----- -$ oc set data secret/osp-secret "AdminPassword=$ADMIN_PASSWORD" ----- - -. Set service account passwords in `osp-secret` to match the service -account passwords from the original deployment: -+ ----- -$ oc set data secret/osp-secret "AodhPassword=$AODH_PASSWORD" -$ oc set data secret/osp-secret "BarbicanPassword=$BARBICAN_PASSWORD" -$ oc set data secret/osp-secret "CeilometerPassword=$CEILOMETER_PASSWORD" -$ oc set data secret/osp-secret "CinderPassword=$CINDER_PASSWORD" -$ oc set data secret/osp-secret "DesignatePassword=$DESIGNATE_PASSWORD" -$ oc set data secret/osp-secret "GlancePassword=$GLANCE_PASSWORD" -$ oc set data secret/osp-secret "HeatAuthEncryptionKey=$HEAT_AUTH_ENCRYPTION_KEY" -$ oc set data secret/osp-secret "HeatPassword=$HEAT_PASSWORD" -$ oc set data secret/osp-secret "HeatStackDomainAdminPassword=$HEAT_STACK_DOMAIN_ADMIN_PASSWORD" -$ oc set data secret/osp-secret "IronicPassword=$IRONIC_PASSWORD" -$ oc set data secret/osp-secret "IronicInspectorPassword=$IRONIC_PASSWORD" -$ oc set data secret/osp-secret "ManilaPassword=$MANILA_PASSWORD" -$ oc set data secret/osp-secret "MetadataSecret=$METADATA_SECRET" -$ oc set data secret/osp-secret "NeutronPassword=$NEUTRON_PASSWORD" -$ oc set data secret/osp-secret "NovaPassword=$NOVA_PASSWORD" -$ oc set data secret/osp-secret "OctaviaPassword=$OCTAVIA_PASSWORD" -$ oc set data secret/osp-secret "PlacementPassword=$PLACEMENT_PASSWORD" -$ oc set data secret/osp-secret "SwiftPassword=$SWIFT_PASSWORD" ----- - -ifeval::["{build_variant}" != "ospdo"] -. Deploy the `OpenStackControlPlane` CR. Ensure that you only enable the DNS, Galera, Memcached, and RabbitMQ services. All other services must -be disabled: -+ -[source,shell] ----- -$ oc apply -f - < - - barbican: - enabled: false - template: - barbicanAPI: {} - barbicanWorker: {} - barbicanKeystoneListener: {} - - cinder: - enabled: false - template: - cinderAPI: {} - cinderScheduler: {} - cinderBackup: {} - cinderVolumes: {} - - dns: - template: - override: - service: - metadata: - annotations: - metallb.universe.tf/address-pool: ctlplane - metallb.universe.tf/allow-shared-ip: ctlplane - metallb.universe.tf/loadBalancerIPs: - - spec: - type: LoadBalancer - options: - - key: server - values: - - 192.168.122.1 - replicas: 1 - - glance: - enabled: false - template: - glanceAPIs: {} - - heat: - enabled: false - template: {} - - horizon: - enabled: false - template: {} - - ironic: - enabled: false - template: - ironicConductors: [] - - keystone: - enabled: false - template: {} - - manila: - enabled: false - template: - manilaAPI: {} - manilaScheduler: {} - manilaShares: {} - - galera: - enabled: true - templates: - openstack: - secret: osp-secret - replicas: 3 - storageRequest: 5G - openstack-cell1: - secret: osp-secret - replicas: 3 - storageRequest: 5G - openstack-cell2: - secret: osp-secret - replicas: 1 - storageRequest: 5G - openstack-cell3: - secret: osp-secret - replicas: 1 - storageRequest: 5G - memcached: - enabled: true - templates: - memcached: - replicas: 3 - - neutron: - enabled: false - template: {} - - nova: - enabled: false - template: {} - - ovn: - enabled: false - template: - ovnController: - networkAttachment: tenant - ovnNorthd: - replicas: 0 - ovnDBCluster: - ovndbcluster-nb: - replicas: 3 - dbType: NB - networkAttachment: internalapi - ovndbcluster-sb: - replicas: 3 - dbType: SB - networkAttachment: internalapi - - placement: - enabled: false - template: {} - - rabbitmq: - templates: - rabbitmq: - override: - service: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/loadBalancerIPs: - spec: - type: LoadBalancer - rabbitmq-cell1: - persistence: - storage: 10Gi - override: - service: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/loadBalancerIPs: - - spec: - type: LoadBalancer - rabbitmq-cell2: - persistence: - storage: 10Gi - override: - service: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/loadBalancerIPs: - spec: - type: LoadBalancer - rabbitmq-cell3: - persistence: - storage: 10Gi - override: - service: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/loadBalancerIPs: - spec: - type: LoadBalancer - telemetry: - enabled: false - tls: - podLevel: - enabled: false - ingress: - enabled: false - swift: - enabled: false - template: - swiftRing: - ringReplicas: 3 - swiftStorage: - replicas: 0 - swiftProxy: - replicas: 2 -EOF ----- -+ -where: - -:: -Specifies an existing storage class in your {OpenShiftShort} cluster. - -:: -Specifies the LoadBalancer IP address. If you use IPv6, change the load balancer IPs to the IPs in your environment, for example: -+ ----- -... -metallb.universe.tf/allow-shared-ip: ctlplane -metallb.universe.tf/loadBalancerIPs: fd00:aaaa::80 -... -metallb.universe.tf/address-pool: internalapi -metallb.universe.tf/loadBalancerIPs: fd00:bbbb::85 -... -metallb.universe.tf/address-pool: internalapi -metallb.universe.tf/loadBalancerIPs: fd00:bbbb::86 ----- - -* `galera.openstack-cell1` provides the required infrastructure database and messaging services for the Compute cells, for example, `cell1`, `cell2`, and `cell3`. Adjust the values for fields such as `replicas`, `storage`, or `storageRequest`, for each Compute cell as needed. -* `spec.tls` specifies whether TLS-e is enabled. If you enabled TLS-e in your {OpenStackShort} environment, set `tls` to the following: -+ ----- -spec: - ... - tls: - podLevel: - enabled: true - internal: - ca: - customIssuer: rootca-internal - libvirt: - ca: - customIssuer: rootca-internal - ovn: - ca: - customIssuer: rootca-internal - ingress: - ca: - customIssuer: rootca-internal - enabled: true ----- -endif::[] - -ifeval::["{build_variant}" == "ospdo"] -. Deploy the `OpenStackControlPlane` CR. Ensure that you only enable the DNS, Galera, Memcached, and RabbitMQ services. All other services must -be disabled: -+ -[source,shell] ----- -$ oc apply -f - < - - - barbican: - enabled: false - template: - barbicanAPI: {} - barbicanWorker: {} - barbicanKeystoneListener: {} - - cinder: - enabled: false - template: - cinderAPI: {} - cinderScheduler: {} - cinderBackup: {} - cinderVolumes: {} - - dns: - template: - override: - service: - metadata: - annotations: - metallb.universe.tf/address-pool: - metallb.universe.tf/allow-shared-ip: - metallb.universe.tf/loadBalancerIPs: - spec: - type: LoadBalancer - options: - - key: server - values: - - 192.168.122.1 - replicas: 1 - - glance: - enabled: false - template: - glanceAPIs: {} - - heat: - enabled: false - template: {} - - horizon: - enabled: false - template: {} - - ironic: - enabled: false - template: - ironicConductors: [] - - keystone: - enabled: false - template: {} - - manila: - enabled: false - template: - manilaAPI: {} - manilaScheduler: {} - manilaShares: {} - - galera: - enabled: true - templates: - openstack: - secret: osp-secret - replicas: 3 - storageRequest: 5G - openstack-cell1: - secret: osp-secret - replicas: 3 - storageRequest: 5G - openstack-cell2: - secret: osp-secret - replicas: 1 - storageRequest: 5G - openstack-cell3: - secret: osp-secret - replicas: 1 - storageRequest: 5G - memcached: - enabled: true - templates: - memcached: - replicas: 3 - - neutron: - enabled: false - template: {} - - nova: - enabled: false - template: {} - - ovn: - enabled: false - template: - ovnController: - networkAttachment: tenant - ovnNorthd: - replicas: 0 - ovnDBCluster: - ovndbcluster-nb: - replicas: 3 - dbType: NB - networkAttachment: - ovndbcluster-sb: - replicas: 3 - dbType: SB - networkAttachment: - - placement: - enabled: false - template: {} - - rabbitmq: - templates: - rabbitmq: - override: - service: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/loadBalancerIPs: 172.17.0.85 - spec: - type: LoadBalancer - rabbitmq-cell1: - persistence: - storage: 10Gi - override: - service: - metadata: - annotations: - metallb.universe.tf/address-pool: - metallb.universe.tf/loadBalancerIPs: - spec: - type: LoadBalancer - rabbitmq-cell2: - persistence: - storage: 10Gi - override: - service: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/loadBalancerIPs: 172.17.0.87 - spec: - type: LoadBalancer - rabbitmq-cell3: - persistence: - storage: 10Gi - override: - service: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/loadBalancerIPs: 172.17.0.88 - spec: - type: LoadBalancer - telemetry: - enabled: false - - tls: - podLevel: - enabled: false - ingress: - enabled: false - - swift: - enabled: false - template: - swiftRing: - ringReplicas: 3 - swiftStorage: - replicas: 0 - swiftProxy: - replicas: 2 -EOF ----- -+ -where: - -:: -Specifies an existing storage class in your {OpenShiftShort} cluster. - -:: -Specifies name of your network definition. - -:: -Specifies the LoadBalancer IP address. If you use IPv6, change the load balancer IPs to the IPs in your environment, for example: -+ ----- -... -metallb.universe.tf/allow-shared-ip: ctlplane -metallb.universe.tf/loadBalancerIPs: fd00:aaaa::80 -... -metallb.universe.tf/address-pool: internalapi -metallb.universe.tf/loadBalancerIPs: fd00:bbbb::85 -... -metallb.universe.tf/address-pool: internalapi -metallb.universe.tf/loadBalancerIPs: fd00:bbbb::86 ----- - -:: -Specifies the name of your network. - -* `galera.openstack-cell1` provides the required infrastructure database and messaging services for the Compute cells, for example, `cell1`, `cell2`, and `cell3`. Adjust the values for fields such as `replicas`, `storage`, or `storageRequest`, for each Compute cell as needed. -* `spec.tls` specifies whether TLS-e is enabled. If you enabled TLS-e in your {OpenStackShort} environment, set `tls` to the following: -+ ----- -spec: - ... - tls: - podLevel: - enabled: true - internal: - ca: - customIssuer: rootca-internal - libvirt: - ca: - customIssuer: rootca-internal - ovn: - ca: - customIssuer: rootca-internal - ingress: - ca: - customIssuer: rootca-internal - enabled: true ----- -endif::[] - - - -.Verification - -* Verify that the Galera and RabbitMQ status is `Running` for all defined cells: -+ ----- -$ RENAMED_CELLS="cell1 cell2 cell3" -$ oc get pod openstack-galera-0 -o jsonpath='{.status.phase}{"\n"}' -$ oc get pod rabbitmq-server-0 -o jsonpath='{.status.phase}{"\n"}' -$ for CELL in $(echo $RENAMED_CELLS); do -> oc get pod openstack-$CELL-galera-0 -o jsonpath='{.status.phase}{"\n"}' -> oc get pod rabbitmq-$CELL-server-0 -o jsonpath='{.status.phase}{"\n"}' -> done ----- -+ -The given cells names are later referred to by using the environment variable `RENAMED_CELLS`. -During the database migration procedure, the Nova cells are renamed. `RENAMED_CELLS` variable represents the new cell names used in the RHOSO deployment. - -* Ensure that the statuses of all the Rabbitmq and Galera CRs are `Setup complete`: -+ ----- -$ oc get Rabbitmqs,Galera -NAME STATUS MESSAGE -rabbitmq.rabbitmq.openstack.org/rabbitmq True Setup complete -rabbitmq.rabbitmq.openstack.org/rabbitmq-cell1 True Setup complete - -NAME READY MESSAGE -galera.mariadb.openstack.org/openstack True Setup complete -galera.mariadb.openstack.org/openstack-cell1 True Setup complete ----- - -* Verify that the `OpenStackControlPlane` CR is waiting for deployment - of the `openstackclient` pod: -+ ----- -$ oc get OpenStackControlPlane openstack -NAME STATUS MESSAGE -openstack Unknown OpenStackControlPlane Client not started ----- diff --git a/docs_user/modules/proc_deploying-file-systems-service-control-plane.adoc b/docs_user/modules/proc_deploying-file-systems-service-control-plane.adoc deleted file mode 100644 index f7b612a81..000000000 --- a/docs_user/modules/proc_deploying-file-systems-service-control-plane.adoc +++ /dev/null @@ -1,230 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="deploying-file-systems-service-control-plane_{context}"] - -= Deploying the {rhos_component_storage_file} on the control plane - -[role="_abstract"] -Copy the {rhos_component_storage_file_first_ref} configuration from the {rhos_prev_long} ({OpenStackShort}) {rhos_prev_ver} deployment, and then deploy the {rhos_component_storage_file} on the control plane. - -[NOTE] -==== -In a {rhos_prev_long} DCN deployment, the {rhos_component_storage_file} runs only at the central site and is not deployed on edge site Compute nodes. After adoption, {rhos_long} supports deploying the {rhos_component_storage_file} at edge sites if required. -==== - -.Prerequisites - -* The {rhos_component_storage_file} systemd services such as `api`, `cron`, and `scheduler` are stopped. For more information, see xref:stopping-openstack-services_migrating-databases[Stopping {rhos_prev_long} services]. -* If the deployment uses CephFS through NFS as a storage back end, the Pacemaker ordering and collocation constraints are adjusted. For more information, see xref:stopping-openstack-services_migrating-databases[Stopping {rhos_prev_long} services]. -* The {rhos_component_storage_file} Pacemaker service (`openstack-manila-share`) is stopped. For more information, see xref:stopping-openstack-services_migrating-databases[Stopping {rhos_prev_long} services]. -* The database migration is complete. For more information, see xref:migrating-databases-to-mariadb-instances_migrating-databases[Migrating databases to MariaDB instances]. -* The {rhocp_long} nodes where the `manila-share` service is to be deployed can reach the management network that the storage system is in. -* If the deployment uses CephFS through NFS as a storage back end, a new clustered Ceph NFS service is deployed on the {CephCluster} cluster with the help -of Ceph orchestrator. For more information, see xref:creating-a-ceph-nfs-cluster_ceph-prerequisites[Creating a Ceph NFS cluster]. -* Services such as the {identity_service_first_ref} and memcached are available prior to adopting the Shared File Systems services. -* If you enabled tenant-driven networking by setting `driver_handles_share_servers=True`, the {networking_first_ref} is deployed. -ifeval::["{build}" != "downstream"] -* Define the `CONTROLLER1_SSH` environment variable if it link:stop_openstack_services.md#variables[hasn't been -defined] already. Replace the following example values with values that are correct for your environment: -+ ----- -$ CONTROLLER1_SSH="ssh -i tripleo-admin@" ----- -endif::[] -ifeval::["{build}" != "upstream"] -* The `CONTROLLER1_SSH` environment variable is defined and points to the {OpenStackShort} Controller node. Replace the following example values with values that are correct for your environment: -+ ----- -$ CONTROLLER1_SSH="ssh -i tripleo-admin@" ----- -endif::[] - -.Procedure - -. Copy the configuration file from {OpenStackShort} {rhos_prev_ver} for reference: -+ ----- -$ CONTROLLER1_SSH cat /var/lib/config-data/puppet-generated/manila/etc/manila/manila.conf | awk '!/^ *#/ && NF' > ~/manila.conf ----- - -. Review the configuration file for configuration changes that were made since {OpenStackShort} {rhos_prev_ver}. For more information on preparing this file for {rhos_long}, see xref:preparing-the-shared-file-systems-service-configuration_adopting-shared-file-systems[Guidelines for preparing the {rhos_component_storage_file} configuration]. -// - TODO link config diff tables for RHOSP 17.1 (Wallaby) to RHOSP 18 (Antelope) - - -. Create a patch file for the `OpenStackControlPlane` CR to deploy the {rhos_component_storage_file}. The following example `manila.patch` file uses native CephFS: -+ ----- -$ cat << __EOF__ > ~/manila.patch -spec: - manila: - enabled: true - apiOverride: - route: {} - template: - databaseInstance: openstack - databaseAccount: manila - secret: osp-secret - manilaAPI: - replicas: 3 - customServiceConfig: | - [DEFAULT] - enabled_share_protocols = cephfs - override: - service: - internal: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/allow-shared-ip: internalapi - metallb.universe.tf/loadBalancerIPs: <172.17.0.80> - spec: - type: LoadBalancer - manilaScheduler: - replicas: 3 - manilaShares: - cephfs: - replicas: 1 - customServiceConfig: | - [DEFAULT] - enabled_share_backends = tripleo_ceph - host = hostgroup - [cephfs] - driver_handles_share_servers=False - share_backend_name=cephfs - share_driver=manila.share.drivers.cephfs.driver.CephFSDriver - cephfs_conf_path=/etc/ceph/ceph.conf - cephfs_auth_id=openstack - cephfs_cluster_name=ceph - cephfs_volume_mode=0755 - cephfs_protocol_helper_type=CEPHFS - networkAttachments: - - storage - extraMounts: - - name: v1 - region: r1 - extraVol: - - propagation: - - ManilaShare - extraVolType: Ceph - volumes: - - name: ceph - secret: - secretName: ceph-conf-files - mounts: - - name: ceph - mountPath: "/etc/ceph" - readOnly: true -__EOF__ ----- -+ -* `metallb.universe.tf/loadBalancerIPs:<172.17.0.80>` specifies the load balancer IP in your environment. If you use IPv6, change the load balancer IP to the load balancer IP in your environment, for example, `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80`. -* `share_backend_name` specifies the names of the back ends to use in {rhos_long}. Ensure that the names of the back ends are the same as they were in {OpenStackShort} {rhos_prev_ver}. -* `networkAttachments` specifies the appropriate storage management network. For example, the `manilaShares` instance with the CephFS back-end driver is connected to the `storage` network. -* `extraMounts` specifies additional files to add to any of the services. For example, when using {Ceph}, you can add the {rhos_component_storage_file} Ceph user's keyring file as well as the `ceph.conf` configuration file. -* In a DCN deployment where {Ceph} configuration files are named by cluster (for example, `central.conf` instead of `ceph.conf`), set `cephfs_conf_path` to the path of the configuration file for the cluster hosting the CephFS back end, and set `cephfs_cluster_name` to the corresponding cluster name. For example, `cephfs_conf_path=/etc/ceph/central.conf` and `cephfs_cluster_name=central`. Using `/etc/ceph/ceph.conf` when that file does not exist in the mounted secret will cause the `manila-share` service to fail with a `conf_read_file` error. -+ -The following example patch file uses CephFS through NFS: -+ ----- -$ cat << __EOF__ > ~/manila.patch -spec: - manila: - enabled: true - apiOverride: - route: {} - template: - databaseInstance: openstack - secret: osp-secret - manilaAPI: - replicas: 3 - customServiceConfig: | - [DEFAULT] - enabled_share_protocols = cephfs - override: - service: - internal: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/allow-shared-ip: internalapi - metallb.universe.tf/loadBalancerIPs: <172.17.0.80> - spec: - type: LoadBalancer - manilaScheduler: - replicas: 3 - manilaShares: - cephfs: - replicas: 1 - customServiceConfig: | - [DEFAULT] - enabled_share_backends = cephfs - host = hostgroup - [cephfs] - driver_handles_share_servers=False - share_backend_name=tripleo_ceph - share_driver=manila.share.drivers.cephfs.driver.CephFSDriver - cephfs_conf_path=/etc/ceph/ceph.conf - cephfs_auth_id=openstack - cephfs_cluster_name=ceph - cephfs_protocol_helper_type=NFS - cephfs_nfs_cluster_id=cephfs - cephfs_ganesha_server_ip=172.17.5.47 - networkAttachments: - - storage -__EOF__ ----- -+ -* Prior to adopting the `manilaShares` service for CephFS through NFS, ensure that you create a clustered Ceph NFS service. The name of the service must be `cephfs_nfs_cluster_id`. The `cephfs_nfs_cluster_id` option is set with the name of the NFS cluster created on {Ceph}. -* The `cephfs_ganesha_server_ip` option is preserved from the configuration on the {OpenStackShort} {rhos_prev_ver} environment. - -. Patch the `OpenStackControlPlane` CR: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch-file=~/ ----- -+ -* Replace `` with the name of your patch file. - -.Verification - -. Inspect the resulting {rhos_component_storage_file} pods: -+ ----- -$ oc get pods -l service=manila ----- - -. Check that the Shared File Systems API service is registered in the {identity_service_first_ref}: -+ ----- -$ openstack service list | grep manila ----- -+ ----- -$ openstack endpoint list | grep manila - -| 1164c70045d34b959e889846f9959c0e | regionOne | manila | share | True | internal | http://manila-internal.openstack.svc:8786/v1/%(project_id)s | -| 63e89296522d4b28a9af56586641590c | regionOne | manilav2 | sharev2 | True | public | https://manila-public-openstack.apps-crc.testing/v2 | -| af36c57adcdf4d50b10f484b616764cc | regionOne | manila | share | True | public | https://manila-public-openstack.apps-crc.testing/v1/%(project_id)s | -| d655b4390d7544a29ce4ea356cc2b547 | regionOne | manilav2 | sharev2 | True | internal | http://manila-internal.openstack.svc:8786/v2 | ----- - -. Test the health of the service: -+ ----- -$ openstack share service list -$ openstack share pool list --detail ----- - -. Check existing workloads: -+ ----- -$ openstack share list -$ openstack share snapshot list ----- -ifeval::["{build}" != "downstream"] -. You can create further resources: -+ ----- -$ openstack share create cephfs 10 --snapshot mysharesnap --name myshareclone -$ openstack share create nfs 10 --name mynfsshare -$ openstack share export location list mynfsshare ----- -endif::[] diff --git a/docs_user/modules/proc_deploying-the-bare-metal-provisioning-service.adoc b/docs_user/modules/proc_deploying-the-bare-metal-provisioning-service.adoc deleted file mode 100644 index ca4520678..000000000 --- a/docs_user/modules/proc_deploying-the-bare-metal-provisioning-service.adoc +++ /dev/null @@ -1,227 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="deploying-the-bare-metal-provisioning-service_{context}"] - -= Deploying the {bare_metal} - -[role="_abstract"] -Deploy the {bare_metal_first_ref} by patching the `OpenStackControlPlane` CR with the {bare_metal} disabled. The `ironic-operator` applies the configuration and starts the Bare Metal Provisioning services. The {bare_metal} then automatically polls the power state of the bare-metal nodes. - -[NOTE] -By default, {rhos_acro} versions {rhos_curr_ver} and later of the {bare_metal} include a new multitenant aware role-based access control (RBAC) model. As a result, bare-metal nodes might be missing when you run the `openstack baremetal node list` command after you adopt the {bare_metal}. Your nodes are not deleted. Due to the increased access restrictions in the RBAC model, you must identify which project owns the missing bare-metal nodes and set the `owner` field on each missing bare-metal node. - -.Prerequisites - -* You have imported the service databases into the control plane database. -* The {bare_metal} is disabled in the {rhos_acro} {rhos_curr_ver}. The following command should return a string of `false`: -+ ----- -$ oc get openstackcontrolplanes.core.openstack.org -o jsonpath='{.spec.ironic.enabled}' ----- -+ -** Replace `` with the name of your existing `OpenStackControlPlane` CR, for example, `openstack-control-plane`. -* The {identity_service_first_ref}, {networking_first_ref}, and {image_service_first_ref} are operational. -* The {networking_service} is configured with the ML2 baremetal mechanism driver. For more information, see xref:adopting-the-networking-service_adopt-control-plane[Adopting the {networking_service}]. -+ -[NOTE] -If you use the {bare_metal} in a Bare Metal as a Service configuration, do not adopt the {compute_service_first_ref} before you adopt the {bare_metal}. -* For the {bare_metal} conductor services, the services must be able to reach Baseboard Management Controllers of hardware that is configured to be managed by the {bare_metal}. If this hardware is unreachable, the nodes might enter "maintenance" state and be unavailable until connectivity is restored later. -* You have downloaded the `ironic.conf` file locally: -+ ----- -$CONTROLLER1_SSH cat /var/lib/config-data/puppet-generated/ironic/etc/ironic/ironic.conf > ironic.conf ----- -+ -[NOTE] -This configuration file must come from one of the Controller nodes and not a {OpenStackPreviousInstaller} undercloud node. The {OpenStackPreviousInstaller} undercloud node operates with different configuration that does not apply when you adopt the overcloud Ironic deployment. -* If you are adopting the Ironic Inspector service, you need the value of the `IronicInspectorSubnets` {OpenStackPreviousInstaller} parameter. Use the same values to populate the `dhcpRanges` parameter in the {rhos_acro} environment. -* You have defined the following shell variables. Replace the following example values with values that apply to your environment: -+ ----- -$ alias openstack="oc exec -t openstackclient -- openstack" ----- - -.Procedure - -. Patch the `OpenStackControlPlane` custom resource (CR) to deploy the {bare_metal}: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch ' -spec: - ironic: - enabled: true - template: - rpcTransport: oslo - databaseInstance: openstack - ironicAPI: - replicas: 1 - override: - service: - internal: - metadata: - annotations: - metallb.universe.tf/address-pool: internalapi - metallb.universe.tf/allow-shared-ip: internalapi - metallb.universe.tf/loadBalancerIPs: - spec: - type: LoadBalancer - ironicConductors: - - replicas: 1 - networkAttachments: - - baremetal - provisionNetwork: baremetal - storageRequest: 10G - customServiceConfig: | - [neutron] - cleaning_network= - provisioning_network= - rescuing_network= - inspection_network= - [conductor] - automated_clean=true - ironicInspector: - replicas: 1 - inspectionNetwork: baremetal - networkAttachments: - - baremetal - dhcpRanges: - - name: inspector-0 - cidr: 172.20.1.0/24 - start: 172.20.1.190 - end: 172.20.1.199 - gateway: 172.20.1.1 - serviceUser: ironic-inspector - databaseAccount: ironic-inspector - passwordSelectors: - database: IronicInspectorDatabasePassword - service: IronicInspectorPassword - ironicNeutronAgent: - replicas: 1 - messagingBus: - cluster: rabbitmq - secret: osp-secret -' ----- -+ -where: - -``:: -Specifies the load balancer IP in your environment. If you use IPv6, change the load balancer IP to the load balancer IP in your environment, for example, `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80`. - -`ironicConductors.provisionNetwork`:: -Ensure that the provisioning network and ctlplane network are separate networks. If the networks are shared, there is a risk of configuration conflicts between {rhocp_long} and RHOSO. - -`messagingBus.Cluster`:: -For more information about RHOSO RabbitMQ clusters, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/monitoring_high_availability_services/ref_rhoso-rabbitmq-clusters_ha-monitoring#con_understand-the-rabbitmq-interface-for-openstack-services[RHOSO RabbitMQ clusters] in _Monitoring high availability services_. - -. Wait for the {bare_metal} control plane services CRs to become ready: -+ ----- -$ oc wait --for condition=Ready --timeout=300s ironics.ironic.openstack.org ironic ----- - -. Verify that the individual services are ready: -+ ----- -$ oc wait --for condition=Ready --timeout=300s ironicapis.ironic.openstack.org ironic-api -$ oc wait --for condition=Ready --timeout=300s ironicconductors.ironic.openstack.org ironic-conductor -$ oc wait --for condition=Ready --timeout=300s ironicinspectors.ironic.openstack.org ironic-inspector -$ oc wait --for condition=Ready --timeout=300s ironicneutronagents.ironic.openstack.org ironic-ironic-neutron-agent ----- - -. Update the DNS name servers on the provisioning, cleaning, and rescue networks: -+ -[NOTE] -For name resolution to work for {bare_metal} operations, you must set the DNS name server to use the internal DNS servers in the {rhos_acro} control plane: -+ ----- -$ openstack subnet set --dns-nameserver 192.168.122.80 provisioning-subnet ----- - -. Verify that no {bare_metal} nodes are missing from the node list: -+ ----- -$ openstack baremetal node list ----- -+ -[IMPORTANT] -If the `openstack baremetal node list` command output reports an incorrect power status, wait a few minutes and re-run the command to see if the output syncs with the actual state of the hardware being managed. The time required for the {bare_metal} to review and reconcile the power state of bare-metal nodes depends on the number of operating conductors through the `replicas` parameter and which are present in the {bare_metal} deployment being adopted. - -. If any {bare_metal} nodes are missing from the `openstack baremetal node list` command, temporarily disable the new RBAC policy to see the nodes again: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch ' -spec: - ironic: - enabled: true - template: - databaseInstance: openstack - ironicAPI: - replicas: 1 - customServiceConfig: | - [oslo_policy] - enforce_scope=false - enforce_new_defaults=false -' ----- -+ -After this configuration is applied, the operator restarts the Ironic API service and disables the new RBAC policy that is enabled by default. - -. View the bare-metal nodes that do not have an owner assigned: -+ ----- -$ openstack baremetal node list --long -c UUID -c Owner -c 'Provisioning State' ----- - -. Assign all bare-metal nodes with no owner to a new project, for example, the admin project: -+ ----- -ADMIN_PROJECT_ID=$(openstack project show -c id -f value --domain default admin) -for node in $(openstack baremetal node list -f json -c UUID -c Owner | jq -r '.[] | select(.Owner == null) | .UUID'); do openstack baremetal node set --owner $ADMIN_PROJECT_ID $node; done ----- - -. Re-apply the default RBAC by removing the `customServiceConfig` section or by setting the following values in the `customServiceConfig` section to `true`. For example: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch ' -spec: - ironic: - enabled: true - template: - databaseInstance: openstack - ironicAPI: - replicas: 1 - customServiceConfig: | - [oslo_policy] - enforce_scope=true - enforce_new_defaults=true -' ----- - -.Verification - -. Verify the list of endpoints: -+ ----- -$ openstack endpoint list |grep ironic ----- - -. Verify the list of bare-metal nodes: -+ ----- -$ openstack baremetal node list ----- - -. Reset the deploy images on all bare-metal nodes to use the new centrally configured images: -+ -[NOTE] -After adoption, bare-metal nodes might still reference the old deployment's kernel and RAM disk -images in their `driver_info` fields. Resetting these values causes the {bare_metal} to use the -new centrally configured `deploy_kernel` and `deploy_ramdisk` values from the `ironic.conf` file. -+ ----- -for node in $(openstack baremetal node list -c UUID -f value); do - openstack baremetal node set $node \ - --driver-info deploy_ramdisk= \ - --driver-info deploy_kernel= -done ----- diff --git a/docs_user/modules/proc_enabling-high-availability-for-instances.adoc b/docs_user/modules/proc_enabling-high-availability-for-instances.adoc deleted file mode 100644 index 450d07379..000000000 --- a/docs_user/modules/proc_enabling-high-availability-for-instances.adoc +++ /dev/null @@ -1,102 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="enabling-high-availability-for-instances_{context}"] - -= Enabling the high availability for Compute instances service - -[role="_abstract"] -To enable the high availability for Compute instances (Instance HA) service, you create the following resources: - -* Fencing secret. -* Configuration map. You can create the configuration map manually, or the configuration map is created automatically when you deploy the Instance HA resource. However, you must create the configuration map manually if you want to disable the Instance HA service. -* Instance HA resource. - - -.Prerequisites - -* You have created the `fencing-secret.yaml` configuration file. For more information, see xref:maintaining-instance-ha-functionality-after-adoption_preparing-instance-HA[Maintaining the Instance HA functionality after adoption]. -* You have disabled Pacemaker on your Compute nodes. For more information, see xref:preventing-pacemaker-from-monitoring-compute-nodes_preparing-instance-HA[Preventing Pacemaker from monitoring Compute nodes]. - -.Procedure - -. Create the secret: -+ ----- -$ oc apply -f fencing-secret.yaml -n openstack ----- - -. Optional: Create the Instance HA configuration map and set the `DISABLED` parameter to `false`. For example: -+ ----- -$ cat << EOF > iha-cm.yaml -kind: ConfigMap -metadata: - name: instanceha-0-config - namespace: openstack -apiVersion: v1 -data: - config.yaml: | - config: - EVACUABLE_TAG: "evacuable" - TAGGED_IMAGES: "true" - TAGGED_FLAVORS: "true" - TAGGED_AGGREGATES: "true" - SMART_EVACUATION: "false" - DELTA: "30" - DELAY: "0" - POLL: "45" - THRESHOLD: "50" - WORKERS: "4" - RESERVED_HOSTS: "false" - LEAVE_DISABLED: "false" - CHECK_KDUMP: "false" - LOGLEVEL: "info" - DISABLED: "false" -EOF ----- - -.. Apply the configuration: -+ ----- -$ oc apply -f iha-cm.yaml -n openstack ----- -+ -[NOTE] -If you want to restrict which Compute nodes are evacuated, create host aggregates and set them by using the `EVACUABLE_TAG` parameter. Alternatively, you can set the `TAGGED_AGGREGATES` parameter to `false` to enable monitoring and evacuation of all your Compute nodes. For more information about Instance HA service parameters, see link:{ha-for-instances}/assembly_deploying-and-configuring-the-high-availability-for-compute-instances-service_instance-ha#proc_editing-the-instance-ha-service-parameters_instance-ha[Editing the Instance HA service parameters] in _Configuring high availability for instances_. - -. Create an Instance HA resource and reference the fencing secret and configuration map. For example: -+ ----- -$ cat << EOF > iha.yaml -apiVersion: instanceha.openstack.org/v1beta1 -kind: InstanceHa -metadata: - name: instanceha-0 - namespace: openstack -spec: - caBundleSecretName: combined-ca-bundle - instanceHaConfigMap: - fencingSecret: fencing-secret -EOF ----- -+ -* `spec.instanceHaConfigMap` defines the name of the YAML file containing the Instance HA configuration map that you created. If you do not create this file, then a YAML file called `instanceha-config` is created automatically when the Instance HA service is installed, providing the default values of the Instance HA service parameters. You can then edit the values as needed. - -. Deploy the Instance HA resource: -+ ----- -$ oc apply -f iha.yaml -n openstack ----- - -.Next steps - -* After you complete the {rhos_long_noacro} adoption, remove the Pacemaker components from the Compute nodes. You must run the following commands on each Compute node: -+ ----- -$ sudo systemctl stop pacemaker_remote -$ sudo systemctl stop pcsd -$ sudo systemctl stop pcsd-ruby.service -$ sudo systemctl disable pacemaker_remote -$ sudo systemctl disable pcsd -$ sudo systemctl disable pcsd-ruby.service -$ sudo dnf remove pacemaker pacemaker-remote pcs pcsd -y ----- diff --git a/docs_user/modules/proc_installing-the-systemd-container-package-on-compute-hosts.adoc b/docs_user/modules/proc_installing-the-systemd-container-package-on-compute-hosts.adoc deleted file mode 100644 index 3cb3e6269..000000000 --- a/docs_user/modules/proc_installing-the-systemd-container-package-on-compute-hosts.adoc +++ /dev/null @@ -1,72 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="installing-the-systemd-container-package-on-compute-hosts_{context}"] - -= Installing the `systemd-container` package on Compute hosts - -[role="_abstract"] -Before you adopt the {rhos_long} data plane, you must verify that the `systemd-container` package is installed and that `systemd-machined` is running on all the Compute hosts. You must install the `systemd-container` package on each Compute host that does not have this package. - -.Procedure - -. Log in to the Compute node host as a user with the appropriate permissions. - -. List the instances that are running on the host: -+ ----- -$ sudo machinectl list ----- -+ -Sample output:: -+ ----- -MACHINE CLASS SERVICE OS VERSION ADDRESSES -qemu-1-instance-000000b9 vm libvirt-qemu - - - -qemu-2-instance-000000c2 vm libvirt-qemu - - - - -2 machines listed. ----- - -. Verify that the `systemd-machined` service is running: -+ ----- -$ sudo systemctl status systemd-machined.service ----- -+ -Sample output:: -+ ----- -systemd-machined.service - Virtual Machine and Container Registration Service - Loaded: loaded (/usr/lib/systemd/system/systemd-machined.service; static) - Active: active (running) since Mon 2025-06-16 11:42:07 EDT; 2min 48s ago - Docs: man:systemd-machined.service(8) - man:org.freedesktop.machine1(5) - Main PID: 136614 (systemd-machine) - Status: "Processing requests..." - Tasks: 1 (limit: 838860) - Memory: 1.4M - CPU: 33ms - CGroup: /system.slice/systemd-machined.service - └─136614 /usr/lib/systemd/systemd-machined - -Jun 16 11:42:07 computehost001 systemd[1]: Starting Virtual Machine and Container Registration Service... -Jun 16 11:42:07 computehost001 systemd[1]: Started Virtual Machine and Container Registration Service. -Jun 16 11:43:44 computehost001 systemd-machined[136614]: New machine qemu-1-instance-000000b9. -Jun 16 11:43:51 computehost001 systemd-machined[136614]: New machine qemu-2-instance-000000c2. ----- -+ -[IMPORTANT] -If the `systemd-machined` service is running, skip the rest of this procedure. Ensure that you verify that the `systemd-machined` service is running each Compute node host in the cluster. - -. If the `systemd-machined` service is not running, before you can install the `systemd-container` package, live migrate all virtual machines from the host. For more information about live migration, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html/performing_a_minor_update_of_red_hat_openstack_platform/assembly_rebooting-the-overcloud_keeping-updated#proc_rebooting-compute-nodes_rebooting-the-overcloud[Rebooting Compute nodes] in _Performing a minor update of Red Hat OpenStack Platform_. - -. Install the `systemd-container` on the host: -** If you upgraded your environment from an earlier version of {rhos_prev_long}, reboot the Compute host to automatically install the `systemd-container`. -** If you deployed a new RHOSO environment, install the `systemd-container` manually by using the following command. Rebooting the Compute host is not required: -+ ----- -$ sudo dnf -y install systemd-container ----- -[NOTE] -If your Compute host is not running a virtual machine, you can install the `systemd-container` automatically or manually. - -. Repeat this procedure on each Compute host in the cluster where the `systemd-machined` service is not running. diff --git a/docs_user/modules/proc_maintaining-the-instance-ha-functionality-after-adoption.adoc b/docs_user/modules/proc_maintaining-the-instance-ha-functionality-after-adoption.adoc deleted file mode 100644 index d36dd2baa..000000000 --- a/docs_user/modules/proc_maintaining-the-instance-ha-functionality-after-adoption.adoc +++ /dev/null @@ -1,54 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="maintaining-instance-ha-functionality-after-adoption_{context}"] - -= Maintaining the Instance HA functionality after adoption - -[role="_abstract"] -To maintain the high availability for Compute instances (Instance HA) functionality after you adopt {rhos_long_noacro} {rhos_curr_ver}, create a fencing configuration file to use in your adopted environment. - -.Procedure - -. Gather the fencing information from the `fencing.yaml` file in your {rhos_prev_long} ({OpenStackShort}) {rhos_prev_ver} cluster. - -. Retrieve the {OpenStackShort} {rhos_prev_ver} stonith configuration from any of your overcloud Controller nodes: -+ ----- -$ sudo pcs config ----- -+ ----- -Stonith Devices: -... - Resource: stonith-fence_ipmilan-525400dde4f7 (class=stonith - type=fence_ipmilan) - Attributes: stonith-fence_ipmilan-525400dde4f7-instance_attributes - delay=20 - ipaddr=172.16.0.1 - ipport=6231 - lanplus=true - login=admin - passwd=password - pcmk_host_list=compute-1 - Operations: - monitor: stonith-fence_ipmilan-525400dde4f7-monitor-interval-60s - interval=60s - Resource: stonith-fence_ipmilan-525400819ad3 (class=stonith - type=fence_ipmilan) - Attributes: stonith-fence_ipmilan-525400819ad3-instance_attributes - delay=20 - ipaddr=172.16.0.1 - ipport=6230 - lanplus=true - login=admin - passwd=password - pcmk_host_list=compute-0 - Operations: - monitor: stonith-fence_ipmilan-525400819ad3-monitor-interval-60s - interval=60s -... ----- - -. Generate the fencing configuration file: -+ -* To install the script that automatically generates this file, see link:https://access.redhat.com/solutions/7123932[How do I automatically generate fencing secret for RHOSO18 instanceha from a osp17.1 cluster that I want to adopt?]. -* To create the fencing configuration file manually, see link:{ha-for-instances}/assembly_deploying-and-configuring-the-high-availability-for-compute-instances-service_instance-ha#proc_configuring-the-fencing-of-compute-nodes_instance-ha[Configuring the fencing of Compute nodes] in _Configuring high availability for instances_. diff --git a/docs_user/modules/proc_migrating-ceph-mds.adoc b/docs_user/modules/proc_migrating-ceph-mds.adoc deleted file mode 100644 index cfcfab109..000000000 --- a/docs_user/modules/proc_migrating-ceph-mds.adoc +++ /dev/null @@ -1,256 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="migrating-ceph-mds_{context}"] - -= Migrating {Ceph} MDS to new nodes within the existing cluster - -[role="_abstract"] -Migrate the MDS daemon from a hosts-based approach to a label-based approach. The Shared File Systems service (manila) must be deployed with either a cephfs-native or ceph-nfs back end. The MDS migration is performed by `cephadm`. - -ifeval::["{build}" != "upstream"] -The label-based approach ensures that you can visualize the status of the cluster and where daemons are placed by using the `ceph orch host` command. You can also have a general view of how the daemons are co-located within a given host, as described in the Red Hat Knowledgebase article https://access.redhat.com/articles/1548993[Red Hat Ceph Storage: Supported configurations]. -endif::[] -ifeval::["{build}" != "downstream"] -The label-based approach ensures that you can visualize the status of the cluster and where daemons are placed by using the `ceph orch host` command, and have a general view of how the daemons are co-located within a given host. -endif::[] - -.Prerequisites - -* Complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see xref:red-hat-ceph-storage-prerequisites_configuring-network[{Ceph} prerequisites]. - -.Procedure - -. Verify that the {CephCluster} cluster is healthy and check the MDS status: -+ ----- -$ sudo cephadm shell -- ceph fs ls -name: cephfs, metadata pool: manila_metadata, data pools: [manila_data ] - -$ sudo cephadm shell -- ceph mds stat -cephfs:1 {0=mds.controller-2.oebubl=up:active} 2 up:standby - -$ sudo cephadm shell -- ceph fs status cephfs - -cephfs - 0 clients -====== -RANK STATE MDS ACTIVITY DNS INOS DIRS CAPS - 0 active mds.controller-2.oebubl Reqs: 0 /s 696 196 173 0 - POOL TYPE USED AVAIL -manila_metadata metadata 152M 141G - manila_data data 3072M 141G - STANDBY MDS -mds.controller-0.anwiwd -mds.controller-1.cwzhog ----- - -. Retrieve more detailed information on the Ceph File System (CephFS) MDS status: -+ ----- -$ sudo cephadm shell -- ceph fs dump - -e8 -enable_multiple, ever_enabled_multiple: 1,1 -default compat: compat={},rocompat={},incompat={1=base v0.20,2=client writeable ranges,3=default file layouts on dirs,4=dir inode in separate object,5=mds uses versioned encoding,6=dirfrag is stored in omap,8=no anchor table,9=file layout v2,10=snaprealm v2} -legacy client fscid: 1 - -Filesystem 'cephfs' (1) -fs_name cephfs -epoch 5 -flags 12 joinable allow_snaps allow_multimds_snaps -created 2024-01-18T19:04:01.633820+0000 -modified 2024-01-18T19:04:05.393046+0000 -tableserver 0 -root 0 -session_timeout 60 -session_autoclose 300 -max_file_size 1099511627776 -required_client_features {} -last_failure 0 -last_failure_osd_epoch 0 -compat compat={},rocompat={},incompat={1=base v0.20,2=client writeable ranges,3=default file layouts on dirs,4=dir inode in separate object,5=mds uses versioned encoding,6=dirfrag is stored in omap,7=mds uses inline data,8=no anchor table,9=file layout v2,10=snaprealm v2} -max_mds 1 -in 0 -up {0=24553} -failed -damaged -stopped -data_pools [7] -metadata_pool 9 -inline_data disabled -balancer -standby_count_wanted 1 -[mds.mds.controller-2.oebubl{0:24553} state up:active seq 2 addr [v2:172.17.3.114:6800/680266012,v1:172.17.3.114:6801/680266012] compat {c=[1],r=[1],i=[7ff]}] - - -Standby daemons: - -[mds.mds.controller-0.anwiwd{-1:14715} state up:standby seq 1 addr [v2:172.17.3.20:6802/3969145800,v1:172.17.3.20:6803/3969145800] compat {c=[1],r=[1],i=[7ff]}] -[mds.mds.controller-1.cwzhog{-1:24566} state up:standby seq 1 addr [v2:172.17.3.43:6800/2227381308,v1:172.17.3.43:6801/2227381308] compat {c=[1],r=[1],i=[7ff]}] -dumped fsmap epoch 8 ----- - -. Check the OSD blocklist and clean up the client list: -+ ----- -$ sudo cephadm shell -- ceph osd blocklist ls -$ for item in $(sudo cephadm shell -- ceph osd blocklist ls | awk '{print $1}'); do -> sudo cephadm shell -- ceph osd blocklist rm $item; -> done ----- -+ -[NOTE] -==== -When a file system client is unresponsive or misbehaving, the access to the file system might be forcibly terminated. This process is called eviction. Evicting a CephFS client prevents it from communicating further with MDS daemons and OSD daemons. - -Ordinarily, a blocklisted client cannot reconnect to the servers; you must unmount and then remount the client. However, permitting a client that was evicted to attempt to reconnect can be useful. Because CephFS uses the RADOS OSD blocklist to control client eviction, you can permit CephFS clients to reconnect by removing them from the blocklist. -==== - -. Get the hosts that are currently part of the {Ceph} cluster: -+ ----- -[ceph: root@controller-0 /]# ceph orch host ls -HOST ADDR LABELS STATUS -cephstorage-0.redhat.local 192.168.24.25 osd -cephstorage-1.redhat.local 192.168.24.50 osd -cephstorage-2.redhat.local 192.168.24.47 osd -controller-0.redhat.local 192.168.24.24 _admin mgr mon -controller-1.redhat.local 192.168.24.42 mgr _admin mon -controller-2.redhat.local 192.168.24.37 mgr _admin mon -6 hosts in cluster ----- - -. Apply the MDS labels to the target nodes: -+ ----- -for item in $(sudo cephadm shell -- ceph orch host ls --format json | jq -r '.[].hostname'); do - sudo cephadm shell -- ceph orch host label add $item mds; -done ----- - -. Verify that all the hosts have the MDS label: -+ ----- -$ sudo cephadm shell -- ceph orch host ls - -HOST ADDR LABELS -cephstorage-0.redhat.local 192.168.24.11 osd mds -cephstorage-1.redhat.local 192.168.24.12 osd mds -cephstorage-2.redhat.local 192.168.24.47 osd mds -controller-0.redhat.local 192.168.24.35 _admin mon mgr mds -controller-1.redhat.local 192.168.24.53 mon _admin mgr mds -controller-2.redhat.local 192.168.24.10 mon _admin mgr mds ----- - -. Dump the current MDS spec: -+ ----- - -$ SPEC_DIR=${SPEC_DIR:-"$PWD/ceph_specs"} -$ mkdir -p ${SPEC_DIR} -$ sudo cephadm shell -- ceph orch ls --export mds > ${SPEC_DIR}/mds ----- - -. Edit the retrieved spec and replace the `placement.hosts` section with -`placement.label`: -+ ----- -service_type: mds -service_id: mds -service_name: mds.mds -placement: - label: mds ----- - -. Use the `ceph orchestrator` to apply the new MDS spec: -+ ----- -$ SPEC_DIR=${SPEC_DIR:-"$PWD/ceph_specs"} -$ sudo cephadm shell -m ${SPEC_DIR}/mds -- ceph orch apply -i /mnt/mds - -Scheduling new mds deployment ... ----- -+ -This results in an increased number of MDS daemons. - -. Check the new standby daemons that are temporarily added to the CephFS: -+ ----- -$ sudo cephadm shell -- ceph fs dump - -Active - -standby_count_wanted 1 -[mds.mds.controller-0.awzplm{0:463158} state up:active seq 307 join_fscid=1 addr [v2:172.17.3.20:6802/51565420,v1:172.17.3.20:6803/51565420] compat {c=[1],r=[1],i=[7ff]}] - - -Standby daemons: - -[mds.mds.cephstorage-1.jkvomp{-1:463800} state up:standby seq 1 join_fscid=1 addr [v2:172.17.3.135:6820/2075903648,v1:172.17.3.135:6821/2075903648] compat {c=[1],r=[1],i=[7ff]}] -[mds.mds.controller-2.gfrqvc{-1:475945} state up:standby seq 1 addr [v2:172.17.3.114:6800/2452517189,v1:172.17.3.114:6801/2452517189] compat {c=[1],r=[1],i=[7ff]}] -[mds.mds.cephstorage-0.fqcshx{-1:476503} state up:standby seq 1 join_fscid=1 addr [v2:172.17.3.92:6820/4120523799,v1:172.17.3.92:6821/4120523799] compat {c=[1],r=[1],i=[7ff]}] -[mds.mds.cephstorage-2.gnfhfe{-1:499067} state up:standby seq 1 addr [v2:172.17.3.79:6820/2448613348,v1:172.17.3.79:6821/2448613348] compat {c=[1],r=[1],i=[7ff]}] -[mds.mds.controller-1.tyiziq{-1:499136} state up:standby seq 1 addr [v2:172.17.3.43:6800/3615018301,v1:172.17.3.43:6801/3615018301] compat {c=[1],r=[1],i=[7ff]}] ----- - -. To migrate MDS to the target nodes, set the MDS affinity that manages the MDS failover: -+ -[NOTE] -It is possible to elect a dedicated MDS as "active" for a particular file system. To configure this preference, `CephFS` provides a configuration option for MDS called `mds_join_fs`, which enforces this affinity. -When failing over MDS daemons, cluster monitors prefer standby daemons with `mds_join_fs` equal to the file system name with the failed rank. If no standby exists with `mds_join_fs` equal to the file system name, it chooses an unqualified standby as a replacement. -+ ----- -$ sudo cephadm shell -- ceph config set mds.mds.cephstorage-0.fqcshx mds_join_fs cephfs ----- - -* Replace `mds.mds.cephstorage-0.fqcshx` with the daemon deployed on - `cephstorage-0` that was retrieved from the previous step. - -. Remove the labels from the Controller nodes and force the MDS failover to the -target node: -+ ----- -$ for i in 0 1 2; do sudo cephadm shell -- ceph orch host label rm "controller-$i.redhat.local" mds; done - -Removed label mds from host controller-0.redhat.local -Removed label mds from host controller-1.redhat.local -Removed label mds from host controller-2.redhat.local ----- -+ -The switch to the target node happens in the background. The new active MDS is the one that you set by using the `mds_join_fs` command. - -. Check the result of the failover and the new deployed daemons: -+ ----- -$ sudo cephadm shell -- ceph fs dump -… -… -standby_count_wanted 1 -[mds.mds.cephstorage-0.fqcshx{0:476503} state up:active seq 168 join_fscid=1 addr [v2:172.17.3.92:6820/4120523799,v1:172.17.3.92:6821/4120523799] compat {c=[1],r=[1],i=[7ff]}] - - -Standby daemons: - -[mds.mds.cephstorage-2.gnfhfe{-1:499067} state up:standby seq 1 addr [v2:172.17.3.79:6820/2448613348,v1:172.17.3.79:6821/2448613348] compat {c=[1],r=[1],i=[7ff]}] -[mds.mds.cephstorage-1.jkvomp{-1:499760} state up:standby seq 1 join_fscid=1 addr [v2:172.17.3.135:6820/452139733,v1:172.17.3.135:6821/452139733] compat {c=[1],r=[1],i=[7ff]}] - - -$ sudo cephadm shell -- ceph orch ls - -NAME PORTS RUNNING REFRESHED AGE PLACEMENT -crash 6/6 10m ago 10d * -mds.mds 3/3 10m ago 32m label:mds - - -$ sudo cephadm shell -- ceph orch ps | grep mds - - -mds.mds.cephstorage-0.fqcshx cephstorage-0.redhat.local running (79m) 3m ago 79m 27.2M - 17.2.6-100.el9cp 1af7b794f353 2a2dc5ba6d57 -mds.mds.cephstorage-1.jkvomp cephstorage-1.redhat.local running (79m) 3m ago 79m 21.5M - 17.2.6-100.el9cp 1af7b794f353 7198b87104c8 -mds.mds.cephstorage-2.gnfhfe cephstorage-2.redhat.local running (79m) 3m ago 79m 24.2M - 17.2.6-100.el9cp 1af7b794f353 f3cb859e2a15 ----- - -ifeval::["{build}" != "downstream"] -[role="_additional-resources"] -.Additional resources -* https://docs.ceph.com/en/reef/cephfs/eviction[cephfs - eviction] -* https://docs.ceph.com/en/reef/cephfs/standby/#configuring-mds-file-system-affinity[ceph mds - affinity] -endif::[] diff --git a/docs_user/modules/proc_migrating-ceph-post.adoc b/docs_user/modules/proc_migrating-ceph-post.adoc deleted file mode 100644 index 389d549e3..000000000 --- a/docs_user/modules/proc_migrating-ceph-post.adoc +++ /dev/null @@ -1,31 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="updating-the-cluster-dashboard-configuration_{context}"] - -= Updating the {CephCluster} cluster Ceph Dashboard configuration - -[role="_abstract"] -If the Ceph Dashboard is part of the enabled Ceph Manager modules, you need to -reconfigure the failover settings. - -.Procedure - -. Regenerate the following {Ceph} configuration keys to point to the right - `mgr` container: -+ ----- -mgr advanced mgr/dashboard/controller-0.ycokob/server_addr 172.17.3.33 -mgr advanced mgr/dashboard/controller-1.lmzpuc/server_addr 172.17.3.147 -mgr advanced mgr/dashboard/controller-2.xpdgfl/server_addr 172.17.3.138 ----- -+ ----- -$ sudo cephadm shell -$ ceph orch ps | awk '/mgr./ {print $1}' ----- - -. For each retrieved `mgr` daemon, update the corresponding entry in the {Ceph} - configuration: -+ ----- -$ ceph config set mgr mgr/dashboard/<>/server_addr/ ----- diff --git a/docs_user/modules/proc_migrating-databases-to-mariadb-instances.adoc b/docs_user/modules/proc_migrating-databases-to-mariadb-instances.adoc deleted file mode 100644 index 67b551e2d..000000000 --- a/docs_user/modules/proc_migrating-databases-to-mariadb-instances.adoc +++ /dev/null @@ -1,422 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="migrating-databases-to-mariadb-instances_{context}"] - -= Migrating databases to MariaDB instances - -[role="_abstract"] -Migrate your databases from the original {rhos_prev_long} ({OpenStackShort}) deployment to the MariaDB instances in the {rhocp_long} cluster. - -//[NOTE] -//TOD(bogdando): For OSPDo, this example scenario describes a simple single-cell setup. -//TODO(kgilliga): I hid the same note in the Compute adoption procedure. Will likely reinstate this after multi-cell is released. -//kgilliga: The following text was below step 5. I'm preserving it here: + -//Note filtering the information and performance schema tables. -//Gnocchi is no longer used as a metric store as well - -.Prerequisites - -* Ensure that the control plane MariaDB and RabbitMQ are running, and that no other control plane services are running. -* Retrieve the topology-specific service configuration. For more information, see xref:proc_retrieving-topology-specific-service-configuration_migrating-databases[Retrieving topology-specific service configuration]. -* Stop the {OpenStackShort} services. For more information, see xref:stopping-openstack-services_{context}[Stopping {rhos_prev_long} services]. -* Ensure that there is network routability between the original MariaDB and the MariaDB for the control plane. -* Define the following shell variables. Replace the following example values with values that are correct for your environment: -+ ----- -ifeval::["{build}" != "downstream"] -$ STORAGE_CLASS=local-storage -$ MARIADB_IMAGE=quay.io/podified-antelope-centos9/openstack-mariadb:current-podified -endif::[] -ifeval::["{build}" == "downstream"] -$ STORAGE_CLASS=local-storage -$ MARIADB_IMAGE=registry.redhat.io/rhoso/openstack-mariadb-rhel9:18.0 -endif::[] - -ifeval::["{build_variant}" == "ospdo"] -$ OSPDO_MARIADB_CLIENT_ANNOTATIONS='[{"name": "internalapi-static","ips": ["172.17.0.99/24"]}]' -$ MARIADB_RUN_OVERRIDES="$OSPDO_MARIADB_CLIENT_ANNOTATIONS" -endif::[] - -$ CELLS="default cell1 cell2" -$ DEFAULT_CELL_NAME="cell3" -$ RENAMED_CELLS="cell1 cell2 $DEFAULT_CELL_NAME" - -$ CHARACTER_SET=utf8 # -$ COLLATION=utf8_general_ci - -$ declare -A PODIFIED_DB_ROOT_PASSWORD -$ for CELL in $(echo "super $RENAMED_CELLS"); do -> PODIFIED_DB_ROOT_PASSWORD[$CELL]=$(oc get -o json secret/osp-secret | jq -r .data.DbRootPassword | base64 -d) -> done - -$ declare -A PODIFIED_MARIADB_IP -$ for CELL in $(echo "super $RENAMED_CELLS"); do -> if [ "$CELL" = "super" ]; then -> PODIFIED_MARIADB_IP[$CELL]=$(oc get svc --selector "mariadb/name=openstack" -ojsonpath='{.items[0].spec.clusterIP}') -> else -> PODIFIED_MARIADB_IP[$CELL]=$(oc get svc --selector "mariadb/name=openstack-$CELL" -ojsonpath='{.items[0].spec.clusterIP}') -> fi -> done - -$ declare -A TRIPLEO_PASSWORDS -$ for CELL in $(echo $CELLS); do -> if [ "$CELL" = "default" ]; then -> TRIPLEO_PASSWORDS[default]="$HOME/overcloud-passwords.yaml" -> else -> # in a split-stack source cloud, it should take a stack-specific passwords file instead -> TRIPLEO_PASSWORDS[$CELL]="$HOME/overcloud-passwords.yaml" -> fi -> done - -$ declare -A SOURCE_DB_ROOT_PASSWORD -$ for CELL in $(echo $CELLS); do -> SOURCE_DB_ROOT_PASSWORD[$CELL]=$(cat ${TRIPLEO_PASSWORDS[$CELL]} | grep ' MysqlRootPassword:' | awk -F ': ' '{ print $2; }') -> done - -$ declare -A SOURCE_MARIADB_IP -$ SOURCE_MARIADB_IP[default]=** -$ SOURCE_MARIADB_IP[cell1]=** -$ SOURCE_MARIADB_IP[cell2]=** -# ... - -$ declare -A SOURCE_GALERA_MEMBERS_DEFAULT -$ SOURCE_GALERA_MEMBERS_DEFAULT=( -> ["standalone.localdomain"]=172.17.0.100 -> # [...]=... -> ) -$ declare -A SOURCE_GALERA_MEMBERS_CELL1 -$ SOURCE_GALERA_MEMBERS_CELL1=( -> # ... -> ) -$ declare -A SOURCE_GALERA_MEMBERS_CELL2 -$ SOURCE_GALERA_MEMBERS_CELL2=( -> # ... -> ) ----- -+ -** `CELLS` and `RENAMED_CELLS` represent changes that are going to be made after you import the databases. The `default` cell takes a new name from `DEFAULT_CELL_NAME`. In a multi-cell adoption scenario, `default` cell might retain its original 'default' name as well. -** `CHARACTER_SET` and `COLLATION` should match the source database. If they do not match, then foreign key relationships break for any tables that are created in the future as part of the database sync. -** `SOURCE_MARIADB_IP[X]= ...` includes the data for each cell that is defined in `CELLS`. Provide records for the cell names and VIP addresses of MariaDB Galera clusters. -** `` defines the VIP of your galera cell1 cluster. -** `` defines the VIP of your galera cell2 cluster, and so on. -** `SOURCE_GALERA_MEMBERS_CELL`, defines the names of the MariaDB Galera cluster members and their IP address for each cell defined in `CELLS`. Replace `["standalone.localdomain"]="172.17.0.100"` with the real hosts data. - -[NOTE] -A standalone {OpenStackPreviousInstaller} environment only creates a 'default' cell, which should be the only `CELLS` value in this case. The `DEFAULT_CELL_NAME` value should be `cell1`. - -[NOTE] -The `super` is the top-scope Nova API upcall database instance. A super conductor connects to that database. In subsequent examples, the upcall and cells databases use the same password that is defined in `osp-secret`. Old passwords are only needed to prepare the data exports. - -* To get the values for `SOURCE_MARIADB_IP`, query the puppet-generated configurations in the Controller and CellController nodes: -+ ----- -$ sudo grep -rI 'listen mysql' -A10 /var/lib/config-data/puppet-generated/ | grep bind ----- - -* To get the values for `SOURCE_GALERA_MEMBERS_*`, query the puppet-generated configurations in the Controller and CellController nodes: -+ ----- -$ sudo grep -rI 'listen mysql' -A10 /var/lib/config-data/puppet-generated/ | grep server ----- -+ -The source cloud always uses the same password for cells databases. For that reason, the same passwords file is used for all cells stacks. However, split-stack topology allows using different passwords files for each stack. - -* Prepare the MariaDB adoption helper pod: - -. Create a temporary volume claim and a pod for the database data copy. Edit the volume claim storage request if necessary, to give it enough space for the overcloud databases: -+ ----- -$ oc apply -f - < -endif::[] - containers: - - image: $MARIADB_IMAGE - command: [ "sh", "-c", "sleep infinity"] - name: adoption - volumeMounts: - - mountPath: /backup - name: mariadb-data - securityContext: - allowPrivilegeEscalation: false - capabilities: - drop: ALL - runAsNonRoot: true - seccompProfile: - type: RuntimeDefault - volumes: - - name: mariadb-data - persistentVolumeClaim: - claimName: mariadb-data -EOF ----- - -. Wait for the pod to be ready: -+ ----- -$ oc wait --for condition=Ready pod/mariadb-copy-data --timeout=30s ----- - -.Procedure - -. Wait for the `mariadb-copy-data` pod to reach the source TripleO Galera databases: -+ ----- -for CELL in $(echo $CELLS); do - MEMBERS=SOURCE_GALERA_MEMBERS_$(echo ${CELL}|tr '[:lower:]' '[:upper:]')[@] - for i in "${!MEMBERS}"; do - echo "Checking connectivity to the database node $i" - oc rsh mariadb-copy-data mysql \ - -h "$i" -uroot -p"${SOURCE_DB_ROOT_PASSWORD[$CELL]}" -e 'select 1;' - done -done ----- -+ -[NOTE] -==== -For BGP-enabled environments, this command might take a few moments to succeed while the route to the `mariadb-copy-data` pod is advertised and propagated through the network via BGP. If the command fails, wait a few seconds and retry. The connection should succeed once the BGP route advertisement is complete. - -For standard deployments, this command should succeed immediately. -==== - -. Check that the source Galera database clusters in each cell have its members online and synced: -+ ----- -for CELL in $(echo $CELLS); do - MEMBERS=SOURCE_GALERA_MEMBERS_$(echo ${CELL}|tr '[:lower:]' '[:upper:]')[@] - for i in "${!MEMBERS}"; do - echo "Checking for the database node $i WSREP status Synced" - oc rsh mariadb-copy-data mysql \ - -h "$i" -uroot -p"${SOURCE_DB_ROOT_PASSWORD[$CELL]}" \ - -e "show global status like 'wsrep_local_state_comment'" | \ - grep -qE "\bSynced\b" - done -done ----- -+ -[NOTE] -Each additional {compute_service_first_ref} v2 cell runs a dedicated Galera database cluster, so the command checks each cell. - -. Get the count of source databases with the `NOK` (not-OK) status: -+ ----- -for CELL in $(echo $CELLS); do - oc rsh mariadb-copy-data mysql -h "${SOURCE_MARIADB_IP[$CELL]}" -uroot -p"${SOURCE_DB_ROOT_PASSWORD[$CELL]}" -e "SHOW databases;" -done ----- - -. Check that `mysqlcheck` had no errors: -+ ----- -for CELL in $(echo $CELLS); do - set +u - . ~/.source_cloud_exported_variables_$CELL - set -u - test -z "${PULL_OPENSTACK_CONFIGURATION_MYSQLCHECK_NOK[$CELL]}" || [ "${PULL_OPENSTACK_CONFIGURATION_MYSQLCHECK_NOK[$CELL]}" = " " ] && echo "OK" || echo "CHECK FAILED" -done ----- - -. Wait for the `mariadb-copy-data` pod to reach the podified MariaDB: -+ ----- -$ oc rsh mariadb-copy-data mysql -rsh "${PODIFIED_MARIADB_IP['super']}" \ - -uroot -p"${PODIFIED_DB_ROOT_PASSWORD['super']}" -e 'select 1;' ----- -+ -[NOTE] -==== -For BGP-enabled environments, this command might take a few moments to succeed while the route to the `mariadb-copy-data` pod is advertised and propagated through the network via BGP. If the command fails, wait a few seconds and retry. The connection should succeed once the BGP route advertisement is complete. - -For IPv6 environments, this command might take a few moments to succeed while the network IPv6 stack completes its setup. If the command fails, wait a few seconds and retry. - -For standard deployments, such as non-BGP deployments or IPv4 deployments, this command should succeed immediately. -==== - -. Test the connection to the control plane upcall and cells databases: -+ ----- -for CELL in $(echo "super $RENAMED_CELLS"); do - oc rsh mariadb-copy-data mysql -rsh "${PODIFIED_MARIADB_IP[$CELL]}" -uroot -p"${PODIFIED_DB_ROOT_PASSWORD[$CELL]}" -e 'SHOW databases;' -done ----- -+ -[NOTE] -You must transition Compute services that you import later into a superconductor architecture by deleting the old service records in the cell databases, starting with `cell1`. New records are registered with different hostnames that are provided by the {compute_service} operator. All Compute services, except the Compute agent, have no internal state, and you can safely delete their service records. You also need to rename the former `default` cell to `DEFAULT_CELL_NAME`. - -. Create a dump of the original databases: -+ ----- -for CELL in $(echo $CELLS); do - oc rsh mariadb-copy-data << EOF - mysql -h"${SOURCE_MARIADB_IP[$CELL]}" -uroot -p"${SOURCE_DB_ROOT_PASSWORD[$CELL]}" \ - -N -e "show databases" | grep -E -v "schema|mysql|gnocchi|aodh" | \ - while read dbname; do - echo "Dumping $CELL cell \${dbname}"; - mysqldump -h"${SOURCE_MARIADB_IP[$CELL]}" -uroot -p"${SOURCE_DB_ROOT_PASSWORD[$CELL]}" \ - --single-transaction --complete-insert --skip-lock-tables --lock-tables=0 \ - "\${dbname}" > /backup/"${CELL}.\${dbname}".sql; - done -EOF -done ----- - -. Restore the databases from `.sql` files into the control plane MariaDB: -+ ----- -for CELL in $(echo $CELLS); do - RCELL=$CELL - [ "$CELL" = "default" ] && RCELL=$DEFAULT_CELL_NAME - oc rsh mariadb-copy-data << EOF - declare -A db_name_map - db_name_map['nova']="nova_$RCELL" - db_name_map['ovs_neutron']='neutron' - db_name_map['ironic-inspector']='ironic_inspector' - declare -A db_cell_map - db_cell_map['nova']="nova_$DEFAULT_CELL_NAME" - db_cell_map["nova_$RCELL"]="nova_$RCELL" - declare -A db_server_map - db_server_map['default']=${PODIFIED_MARIADB_IP['super']} - db_server_map["nova"]=${PODIFIED_MARIADB_IP[$DEFAULT_CELL_NAME]} - db_server_map["nova_$RCELL"]=${PODIFIED_MARIADB_IP[$RCELL]} - declare -A db_server_password_map - db_server_password_map['default']=${PODIFIED_DB_ROOT_PASSWORD['super']} - db_server_password_map["nova"]=${PODIFIED_DB_ROOT_PASSWORD[$DEFAULT_CELL_NAME]} - db_server_password_map["nova_$RCELL"]=${PODIFIED_DB_ROOT_PASSWORD[$RCELL]} - cd /backup - for db_file in \$(ls ${CELL}.*.sql); do - db_name=\$(echo \${db_file} | awk -F'.' '{ print \$2; }') - [[ "$CELL" != "default" && ! -v "db_cell_map[\${db_name}]" ]] && continue - if [[ "$CELL" == "default" && -v "db_cell_map[\${db_name}]" ]] ; then - target=$DEFAULT_CELL_NAME - elif [[ "$CELL" == "default" && ! -v "db_cell_map[\${db_name}]" ]] ; then - target=super - else - target=$RCELL - fi - renamed_db_file="\${target}_new.\${db_name}.sql" - mv -f \${db_file} \${renamed_db_file} - if [[ -v "db_name_map[\${db_name}]" ]]; then - echo "renaming $CELL cell \${db_name} to \$target \${db_name_map[\${db_name}]}" - db_name=\${db_name_map[\${db_name}]} - fi - db_server=\${db_server_map["default"]} - if [[ -v "db_server_map[\${db_name}]" ]]; then - db_server=\${db_server_map[\${db_name}]} - fi - db_password=\${db_server_password_map['default']} - if [[ -v "db_server_password_map[\${db_name}]" ]]; then - db_password=\${db_server_password_map[\${db_name}]} - fi - echo "creating $CELL cell \${db_name} in \$target \${db_server}" - mysql -h"\${db_server}" -uroot "-p\${db_password}" -e \ - "CREATE DATABASE IF NOT EXISTS \${db_name} DEFAULT \ - CHARACTER SET ${CHARACTER_SET} DEFAULT COLLATE ${COLLATION};" - echo "importing $CELL cell \${db_name} into \$target \${db_server} from \${renamed_db_file}" - mysql -h "\${db_server}" -uroot "-p\${db_password}" "\${db_name}" < "\${renamed_db_file}" - done - if [ "$CELL" = "default" ] ; then - mysql -h "\${db_server_map['default']}" -uroot -p"\${db_server_password_map['default']}" -e \ - "update nova_api.cell_mappings set name='$DEFAULT_CELL_NAME' where name='default';" - fi - mysql -h "\${db_server_map["nova_$RCELL"]}" -uroot -p"\${db_server_password_map["nova_$RCELL"]}" -e \ - "delete from nova_${RCELL}.services where host not like '%nova_${RCELL}-%' and services.binary != 'nova-compute';" -EOF -done ----- -+ -* `db_name_map` defines which common databases to rename when importing them. -* `db_cell_map` defines which cells databases to import, and how to rename them, if needed. -* `db_cell_map["nova_$RCELL"]="nova_$RCELL"` omits importing special `cell0` databases of the cells, as its contents cannot be consolidated during adoption. -* `db_server_map` defines which databases to import into which servers, usually dedicated for cells. -* `db_server_password_map` defines the root passwords map for database servers. You can only use the same password for now. -* `renamed_db_file="\${target}_new.\${db_name}.sql"` assigns which databases to import into which hosts when extracting databases from the `default` cell. - -.Verification - -Compare the following outputs with the topology-specific service configuration. -For more information, see xref:proc_retrieving-topology-specific-service-configuration_migrating-databases[Retrieving topology-specific service configuration]. - -. Check that the databases are imported correctly: -+ ----- -$ set +u -$ . ~/.source_cloud_exported_variables_default -$ set -u -$ dbs=$(oc exec openstack-galera-0 -c galera -- mysql -rs -uroot -p"${PODIFIED_DB_ROOT_PASSWORD['super']}" -e 'SHOW databases;') -$ echo $dbs | grep -Eq '\bkeystone\b' && echo "OK" || echo "CHECK FAILED" -$ echo $dbs | grep -Eq '\bneutron\b' && echo "OK" || echo "CHECK FAILED" -$ echo "${PULL_OPENSTACK_CONFIGURATION_DATABASES[@]}" | grep -Eq '\bovs_neutron\b' && echo "OK" || echo "CHECK FAILED" -$ novadb_mapped_cells=$(oc exec openstack-galera-0 -c galera -- mysql -rs -uroot -p"${PODIFIED_DB_ROOT_PASSWORD['super']}" \ -> nova_api -e 'select uuid,name,transport_url,database_connection,disabled from cell_mappings;') -> uuidf='\S{8,}-\S{4,}-\S{4,}-\S{4,}-\S{12,}' -> default=$(printf "%s\n" "$PULL_OPENSTACK_CONFIGURATION_NOVADB_MAPPED_CELLS" | sed -rn "s/^($uuidf)\s+default\b.*$/\1/p") -> difference=$(diff -ZNua \ -> <(printf "%s\n" "$PULL_OPENSTACK_CONFIGURATION_NOVADB_MAPPED_CELLS") \ -> <(printf "%s\n" "$novadb_mapped_cells")) || true -> if [ "$DEFAULT_CELL_NAME" != "default" ]; then -> printf "%s\n" "$difference" | grep -qE "^\-$default\s+default\b" && echo "OK" || echo "CHECK FAILED" -> printf "%s\n" "$difference" | grep -qE "^\+$default\s+$DEFAULT_CELL_NAME\b" && echo "OK" || echo "CHECK FAILED" -> [ $(grep -E "^[-\+]$uuidf" <<<"$difference" | wc -l) -eq 2 ] && echo "OK" || echo "CHECK FAILED" -> else -> [ "x$difference" = "x" ] && echo "OK" || echo "CHECK FAILED" -> fi -> for CELL in $(echo $RENAMED_CELLS); do -> RCELL=$CELL -> [ "$CELL" = "$DEFAULT_CELL_NAME" ] && RCELL=default -> set +u -> . ~/.source_cloud_exported_variables_$RCELL -> set -u -> c1dbs=$(oc exec openstack-$CELL-galera-0 -c galera -- mysql -rs -uroot -p${PODIFIED_DB_ROOT_PASSWORD[$CELL]} -e 'SHOW databases;') -> echo $c1dbs | grep -Eq "\bnova_${CELL}\b" && echo "OK" || echo "CHECK FAILED" -> novadb_svc_records=$(oc exec openstack-$CELL-galera-0 -c galera -- mysql -rs -uroot -p${PODIFIED_DB_ROOT_PASSWORD[$CELL]} \ -> nova_$CELL -e "select host from services where services.binary='nova-compute' and deleted=0 order by host asc;") -> diff -Z <(echo "x$novadb_svc_records") <(echo "x${PULL_OPENSTACK_CONFIGURATION_NOVA_COMPUTE_HOSTNAMES[@]}") && echo "OK" || echo "CHECK FAILED" -> done ----- -+ -* `echo "${PULL_OPENSTACK_CONFIGURATION_DATABASES[@]}" | grep -Eq '\bovs_neutron\b' && echo "OK" || echo "CHECK FAILED"` ensures that the {networking_first_ref} database is renamed from `ovs_neutron`. -* `nova_api -e 'select uuid,name,transport_url,database_connection,disabled from cell_mappings;')` ensures that the `default` cell is renamed to `$DEFAULT_CELL_NAME`, and the cell UUIDs are retained. -* `for CELL in $(echo $RENAMED_CELLS); do` ensures that the registered Compute services names have not changed. -* `c1dbs=$(oc exec openstack-$CELL-galera-0 -c galera -- mysql -rs -uroot -p${PODIFIED_DB_ROOT_PASSWORD[$CELL]} -e 'SHOW databases;')` ensures {compute_service} cells databases are extracted to separate database servers, and renamed from `nova` to `nova_cell`. -* `diff -Z <(echo "x$novadb_svc_records") <(echo "x${PULL_OPENSTACK_CONFIGURATION_NOVA_COMPUTE_HOSTNAMES[@]}") && echo "OK" || echo "CHECK FAILED"` ensures that the registered {compute_service} name has not changed. - -. Delete the `mariadb-data` pod and the `mariadb-copy-data` persistent volume claim that contains the database backup: -+ -[NOTE] -Consider taking a snapshot of them before deleting. -+ ----- -$ oc delete pod mariadb-copy-data -$ oc delete pvc mariadb-data ----- - -[NOTE] -During the pre-checks and post-checks, the `mariadb-client` pod might return a pod security warning related to the `restricted:latest` security context constraint. This warning is due to default security context constraints and does not prevent the admission controller from creating a pod. You see a warning for the short-lived pod, but it does not interfere with functionality. -For more information, see link:https://learn.redhat.com/t5/DO280-Red-Hat-OpenShift/About-pod-security-standards-and-warnings/m-p/32502[About pod security standards and warnings]. diff --git a/docs_user/modules/proc_migrating-existing-daemons-to-target-nodes.adoc b/docs_user/modules/proc_migrating-existing-daemons-to-target-nodes.adoc deleted file mode 100644 index 4d3a5b1f9..000000000 --- a/docs_user/modules/proc_migrating-existing-daemons-to-target-nodes.adoc +++ /dev/null @@ -1,142 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="migrating-existing-daemons-to-target-nodes_{context}"] - -= Migrating the existing daemons to the target nodes - -[role="_abstract"] -The following procedure is an example of an environment with 3 {Ceph} nodes or ComputeHCI nodes. This scenario extends the monitoring labels to all the {Ceph} or ComputeHCI nodes that are part of the cluster. This means that you keep 3 placements for the target nodes. - -.Prerequisites -* Confirm that the firewall rules are in place and the ports are open for a given monitoring stack service. - -.Procedure - -. Add the monitoring label to all the {CephCluster} or ComputeHCI nodes in the cluster: -+ ----- -for item in $(sudo cephadm shell -- ceph orch host ls --format json | jq -r '.[].hostname'); do - sudo cephadm shell -- ceph orch host label add $item monitoring; -done ----- - -. Verify that all the hosts on the target nodes have the monitoring label: -+ ----- -[tripleo-admin@controller-0 ~]$ sudo cephadm shell -- ceph orch host ls - -HOST ADDR LABELS -cephstorage-0.redhat.local 192.168.24.11 osd monitoring -cephstorage-1.redhat.local 192.168.24.12 osd monitoring -cephstorage-2.redhat.local 192.168.24.47 osd monitoring -controller-0.redhat.local 192.168.24.35 _admin mon mgr monitoring -controller-1.redhat.local 192.168.24.53 mon _admin mgr monitoring -controller-2.redhat.local 192.168.24.10 mon _admin mgr monitoring ----- - -. Remove the labels from the Controller nodes: -+ ----- -$ for i in 0 1 2; do sudo cephadm shell -- ceph orch host label rm "controller-$i.redhat.local" monitoring; done - -Removed label monitoring from host controller-0.redhat.local -Removed label monitoring from host controller-1.redhat.local -Removed label monitoring from host controller-2.redhat.local ----- - -. Dump the current monitoring stack spec: -+ ----- -function export_spec { - local component="$1" - local target_dir="$2" - sudo cephadm shell -- ceph orch ls --export "$component" > "$target_dir/$component" -} - -SPEC_DIR=${SPEC_DIR:-"$PWD/ceph_specs"} -mkdir -p ${SPEC_DIR} -for m in grafana prometheus alertmanager; do - export_spec "$m" "$SPEC_DIR" -done ----- - -. For each daemon, edit the current spec and replace the `placement.hosts:` section with the `placement.label:` section, for example: -+ -[source,yaml] ----- -service_type: grafana -service_name: grafana -placement: - label: monitoring -networks: -- 172.17.3.0/24 -spec: - port: 3100 ----- -+ -This step also applies to Prometheus and Alertmanager specs. - -. Apply the new monitoring spec to relocate the monitoring stack daemons: -+ ----- -SPEC_DIR=${SPEC_DIR:-"$PWD/ceph_specs"} -function migrate_daemon { - local component="$1" - local target_dir="$2" - sudo cephadm shell -m "$target_dir" -- ceph orch apply -i /mnt/ceph_specs/$component -} -for m in grafana prometheus alertmanager; do - migrate_daemon "$m" "$SPEC_DIR" -done ----- - -. Verify that the daemons are deployed on the expected nodes: -+ ----- -[ceph: root@controller-0 /]# ceph orch ps | grep -iE "(prome|alert|grafa)" -alertmanager.cephstorage-2 cephstorage-2.redhat.local 172.17.3.144:9093,9094 -grafana.cephstorage-0 cephstorage-0.redhat.local 172.17.3.83:3100 -prometheus.cephstorage-1 cephstorage-1.redhat.local 172.17.3.53:9092 ----- -+ -[NOTE] -After you migrate the monitoring stack, you lose high availability. The monitoring stack daemons no longer have a Virtual IP address and HAProxy anymore. Node exporters are still running on all the nodes. - -. Review the {Ceph} configuration to ensure that it aligns with the configuration on the target nodes. In particular, focus on the following configuration entries: -+ ----- -[ceph: root@controller-0 /]# ceph config dump | grep -i dashboard -... -mgr advanced mgr/dashboard/ALERTMANAGER_API_HOST http://172.17.3.83:9093 -mgr advanced mgr/dashboard/GRAFANA_API_URL https://172.17.3.144:3100 -mgr advanced mgr/dashboard/PROMETHEUS_API_HOST http://172.17.3.83:9092 -mgr advanced mgr/dashboard/controller-0.ycokob/server_addr 172.17.3.33 -mgr advanced mgr/dashboard/controller-1.lmzpuc/server_addr 172.17.3.147 -mgr advanced mgr/dashboard/controller-2.xpdgfl/server_addr 172.17.3.138 ----- - -. Verify that the `API_HOST/URL` of the `grafana`, `alertmanager` and `prometheus` services points to the IP addresses on the storage network of the node where each daemon is relocated: -+ ----- -[ceph: root@controller-0 /]# ceph orch ps | grep -iE "(prome|alert|grafa)" -alertmanager.cephstorage-0 cephstorage-0.redhat.local 172.17.3.83:9093,9094 -alertmanager.cephstorage-1 cephstorage-1.redhat.local 172.17.3.53:9093,9094 -alertmanager.cephstorage-2 cephstorage-2.redhat.local 172.17.3.144:9093,9094 -grafana.cephstorage-0 cephstorage-0.redhat.local 172.17.3.83:3100 -grafana.cephstorage-1 cephstorage-1.redhat.local 172.17.3.53:3100 -grafana.cephstorage-2 cephstorage-2.redhat.local 172.17.3.144:3100 -prometheus.cephstorage-0 cephstorage-0.redhat.local 172.17.3.83:9092 -prometheus.cephstorage-1 cephstorage-1.redhat.local 172.17.3.53:9092 -prometheus.cephstorage-2 cephstorage-2.redhat.local 172.17.3.144:9092 ----- -+ ----- -[ceph: root@controller-0 /]# ceph config dump -... -... -mgr advanced mgr/dashboard/ALERTMANAGER_API_HOST http://172.17.3.83:9093 -mgr advanced mgr/dashboard/PROMETHEUS_API_HOST http://172.17.3.83:9092 -mgr advanced mgr/dashboard/GRAFANA_API_URL https://172.17.3.144:3100 ----- -+ -[NOTE] -The Ceph Dashboard, as the service provided by the Ceph `mgr`, is not impacted by the relocation. You might experience an impact when the active `mgr` daemon is migrated or is force-failed. However, you can define 3 replicas in the Ceph Manager configuration to redirect requests to a different instance. diff --git a/docs_user/modules/proc_migrating-mgr-from-controller-nodes.adoc b/docs_user/modules/proc_migrating-mgr-from-controller-nodes.adoc deleted file mode 100644 index 79a73d61f..000000000 --- a/docs_user/modules/proc_migrating-mgr-from-controller-nodes.adoc +++ /dev/null @@ -1,119 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="migrating-ceph-mgr-daemons-to-ceph-nodes_{context}"] - -= Migrating Ceph Manager daemons to {Ceph} nodes - -[role="_abstract"] -Migrate Ceph Manager daemons from {rhos_prev_long} Controller nodes to a set of existing {Ceph} nodes, or Compute nodes if {Ceph} is deployed by {OpenStackPreviousInstaller} with a Hyperconverged Infrastructure (HCI) topology. - -[NOTE] -The following procedure uses `cephadm` and the Ceph Orchestrator to drive the Ceph Manager migration, and the Ceph spec to modify the placement and reschedule the Ceph Manager daemons. Ceph Manager is run in an active/passive state. It also provides many modules, including the Ceph Orchestrator. Every potential module, such as the Ceph Dashboard, that is provided by `ceph-mgr` is implicitly migrated with Ceph Manager. - -.Procedure - -. SSH into the target node and enable the firewall rules that are required to reach a Ceph Manager service: -+ ----- -dports="6800:7300" -ssh heat-admin@ sudo iptables -I INPUT \ - -p tcp --match multiport --dports $dports -j ACCEPT; ----- -+ -* Replace `` with the hostname of the hosts that are listed in the {Ceph} environment. Run `ceph orch host ls` to see the list of the hosts. -+ -Repeat this step for each target node. - -. Check that the rules are properly applied to the target node and persist them: -+ ----- -$ sudo iptables-save -$ sudo systemctl restart iptables ----- -+ -[NOTE] -The default dashboard port for `ceph-mgr` in a greenfield deployment is 8443. With director-deployed {Ceph}, the default port is 8444 because the service ran on the Controller node, and it was necessary to use this port to avoid a conflict. For adoption, update the dashboard port to 8443 in the `ceph-mgr` configuration and firewall rules. - -. Log in to `controller-0` and update the dashboard port in the `ceph-mgr` configuration to 8443: -+ ----- -$ sudo cephadm shell -$ ceph config set mgr mgr/dashboard/server_port 8443 -$ ceph config set mgr mgr/dashboard/ssl_server_port 8443 -$ ceph mgr module disable dashboard -$ ceph mgr module enable dashboard ----- -. If `nftables` is used in the existing deployment, edit `/etc/nftables/tripleo-rules.nft` -and add the following content: -+ -[source,yaml] ----- -# 113 ceph_mgr {'dport': ['6800-7300', 8443]} -add rule inet filter TRIPLEO_INPUT tcp dport { 6800-7300,8443 } ct state new counter accept comment "113 ceph_mgr" ----- - -. Save the file. - -. Restart the `nftables` service: -+ ----- -$ sudo systemctl restart nftables ----- - -. Verify that the rules are applied: -+ ----- -$ sudo nft list ruleset | grep ceph_mgr ----- -. Prepare the target node to host the new Ceph Manager daemon, and add the `mgr` -label to the target node: -+ ----- -$ sudo cephadm shell -- ceph orch host label add mgr ----- - -. Repeat steps 1-7 for each target node that hosts a Ceph Manager daemon. - -. Get the Ceph Manager spec: -+ ----- - -$ SPEC_DIR=${SPEC_DIR:-"$PWD/ceph_specs"} -$ mkdir -p ${SPEC_DIR} -$ sudo cephadm shell -- ceph orch ls --export mgr > ${SPEC_DIR}/mgr ----- - -. Edit the retrieved spec and add the `label: mgr` section to the `placement` -section: -+ -[source,yaml] ----- -service_type: mgr -service_id: mgr -placement: - label: mgr ----- - -. Save the spec. -. Apply the spec with `cephadm` by using the Ceph Orchestrator: -+ ----- -$ SPEC_DIR=${SPEC_DIR:-"$PWD/ceph_specs"} -$ sudo cephadm shell -m ${SPEC_DIR}/mgr -- ceph orch apply -i /mnt/mgr ----- - -.Verification - -. Verify that the new Ceph Manager daemons are created in the target nodes: -+ ----- -$ sudo cephadm shell -- ceph orch ps | grep -i mgr -$ sudo cephadm shell -- ceph -s ----- -+ -The Ceph Manager daemon count should match the number of hosts where the `mgr` label is added. -+ -[NOTE] -The migration does not shrink the Ceph Manager daemons. The count grows by -the number of target nodes, and migrating Ceph Monitor daemons to {Ceph} nodes -decommissions the stand-by Ceph Manager instances. For more information, see -xref:migrating-mon-from-controller-nodes_migrating-ceph-rbd[Migrating Ceph Monitor daemons to {Ceph} nodes]. diff --git a/docs_user/modules/proc_migrating-mon-from-controller-nodes-config-target-nodes.adoc b/docs_user/modules/proc_migrating-mon-from-controller-nodes-config-target-nodes.adoc deleted file mode 100644 index bb46f732a..000000000 --- a/docs_user/modules/proc_migrating-mon-from-controller-nodes-config-target-nodes.adoc +++ /dev/null @@ -1,174 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="configuring-target-nodes-for-ceph-monitor-migration_{context}"] - -= Configuring target nodes for Ceph Monitor migration - -[role="_abstract"] -Prepare the target {Ceph} nodes for the Ceph Monitor migration by performing the following actions: - -. Enable firewall rules in a target node and persist them. -. Create a spec that is based on labels and apply it by using `cephadm`. -. Ensure that the Ceph Monitor quorum is maintained during the migration process. - -.Procedure - -. SSH into the target node and enable the firewall rules that are required to -reach a Ceph Monitor service: -+ ----- -$ for port in 3300 6789; { - ssh heat-admin@ sudo iptables -I INPUT \ - -p tcp -m tcp --dport $port -m conntrack --ctstate NEW \ - -j ACCEPT; -} ----- -+ -* Replace `` with the hostname of the node that hosts the new Ceph Monitor. - -. Check that the rules are properly applied to the target node and persist them: -+ ----- -$ sudo iptables-save -$ sudo systemctl restart iptables ----- - -. If `nftables` is used in the existing deployment, edit `/etc/nftables/tripleo-rules.nft` -and add the following content: -+ -[source,yaml] ----- -# 110 ceph_mon {'dport': [6789, 3300, '9100']} -add rule inet filter TRIPLEO_INPUT tcp dport { 6789,3300,9100 } ct state new counter accept comment "110 ceph_mon" ----- - -. Save the file. - -. Restart the `nftables` service: -+ ----- -$ sudo systemctl restart nftables ----- - -. Verify that the rules are applied: -+ ----- -$ sudo nft list ruleset | grep ceph_mon ----- - -. To migrate the existing Ceph Monitors to the target {Ceph} nodes, retrieve the {Ceph} mon spec from the first Ceph Monitor, or the first Controller node: -+ ----- -$ SPEC_DIR=${SPEC_DIR:-"$PWD/ceph_specs"} -$ mkdir -p ${SPEC_DIR} -$ sudo cephadm shell -- ceph orch ls --export mon > ${SPEC_DIR}/mon ----- - -. Add the `label:mon` section to the `placement` section: -+ ----- -service_type: mon -service_id: mon -placement: - label: mon ----- - -. Save the spec. - -. Apply the spec with `cephadm` by using the Ceph Orchestrator: -+ ----- -$ SPEC_DIR=${SPEC_DIR:-"$PWD/ceph_specs"} -$ sudo cephadm shell -m ${SPEC_DIR}/mon -- ceph orch apply -i /mnt/mon ----- - -. Extend the `mon` label to the remaining {Ceph} target nodes to ensure that -quorum is maintained during the migration process: -+ ----- -for item in $(sudo cephadm shell -- ceph orch host ls --format json | jq -r '.[].hostname'); do - sudo cephadm shell -- ceph orch host label add $item mon; - sudo cephadm shell -- ceph orch host label add $item _admin; -done ----- -+ -[NOTE] -Applying the `mon` spec allows the existing strategy to use `labels` instead of `hosts`. -As a result, any node with the `mon` label can host a Ceph Monitor daemon. -Perform this step only once to avoid multiple iterations when multiple Ceph Monitors are migrated. - -. Check the status of the {CephCluster} and the Ceph Orchestrator daemons list. -Ensure that Ceph Monitors are in a quorum and listed by the `ceph orch` command: -+ ----- -$ sudo cephadm shell -- ceph -s - cluster: - id: f6ec3ebe-26f7-56c8-985d-eb974e8e08e3 - health: HEALTH_OK - - services: - mon: 6 daemons, quorum controller-0,controller-1,controller-2,ceph-0,ceph-1,ceph-2 (age 19m) - mgr: controller-0.xzgtvo(active, since 32m), standbys: controller-1.mtxohd, controller-2.ahrgsk - osd: 8 osds: 8 up (since 12m), 8 in (since 18m); 1 remapped pgs - - data: - pools: 1 pools, 1 pgs - objects: 0 objects, 0 B - usage: 43 MiB used, 400 GiB / 400 GiB avail - pgs: 1 active+clean ----- -+ ----- -$ sudo cephadm shell -- ceph orch host ls -HOST ADDR LABELS STATUS -ceph-0 192.168.24.14 osd mon mgr _admin -ceph-1 192.168.24.7 osd mon mgr _admin -ceph-2 192.168.24.8 osd mon mgr _admin -controller-0 192.168.24.15 _admin mgr mon -controller-1 192.168.24.23 _admin mgr mon -controller-2 192.168.24.13 _admin mgr mon ----- - -. Set up a Ceph client on the first Controller node that is used during the rest -of the procedure to interact with {Ceph}. Set up an additional IP address on the -storage network that is used to interact with {Ceph} when the first Controller -node is decommissioned: - -.. Back up the content of `/etc/ceph` in the `ceph_client_backup` directory. -+ ----- -$ mkdir -p $HOME/ceph_client_backup -$ sudo cp -R /etc/ceph/* $HOME/ceph_client_backup ----- - -.. Edit `/etc/os-net-config/config.yaml` and add `- ip_netmask: 172.17.3.200` - after the IP address on the VLAN that belongs to the storage network. Replace - `172.17.3.200` with any other available IP address on the storage network - that can be statically assigned to `controller-0`. - -.. Save the file and refresh the `controller-0` network configuration: -+ ----- -$ sudo os-net-config -c /etc/os-net-config/config.yaml ----- - -.. Verify that the IP address is present in the Controller node: -+ ----- -$ ip -o a | grep 172.17.3.200 ----- - -.. Ping the IP address and confirm that it is reachable: -+ ----- -$ ping -c 3 172.17.3.200 ----- - -.. Verify that you can interact with the {Ceph} cluster: -+ ----- -$ sudo cephadm shell -c $HOME/ceph_client_backup/ceph.conf -k $HOME/ceph_client_backup/ceph.client.admin.keyring -- ceph -s ----- - -.Next steps - -Proceed to the next step xref:draining-the-source-node_{context}[Draining the source node]. diff --git a/docs_user/modules/proc_migrating-mon-from-controller-nodes-drain-host.adoc b/docs_user/modules/proc_migrating-mon-from-controller-nodes-drain-host.adoc deleted file mode 100644 index 999ef89b8..000000000 --- a/docs_user/modules/proc_migrating-mon-from-controller-nodes-drain-host.adoc +++ /dev/null @@ -1,93 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="draining-the-source-node_{context}"] - -= Draining the source node - -[role="_abstract"] -Drain the source node and remove the source node host from the {CephCluster} cluster. - -.Procedure - -. On the source node, back up the `/etc/ceph/` directory to run `cephadm` and get a shell for the {Ceph} cluster from the source node: -+ ----- -$ mkdir -p $HOME/ceph_client_backup -$ sudo cp -R /etc/ceph $HOME/ceph_client_backup ----- - -. Identify the active `ceph-mgr` instance: -+ ----- -$ sudo cephadm shell -- ceph mgr stat ----- - -. Fail the `ceph-mgr` if it is active on the source node: -+ ----- -$ sudo cephadm shell -- ceph mgr fail ----- -+ -* Replace `` with the Ceph Manager daemon to fail. - -. From the `cephadm` shell, remove the labels on the source node: -+ ----- -$ for label in mon mgr _admin; do - sudo cephadm shell -- ceph orch host label rm $label; -done ----- -+ -* Replace `` with the hostname of the source node. - -. Optional: Ensure that you remove the Ceph Monitor daemon from the source node if it is still running: -+ ----- -$ sudo cephadm shell -- ceph orch daemon rm mon. --force ----- - -. Drain the source node to remove any leftover daemons: -+ ----- -$ sudo cephadm shell -- ceph orch host drain ----- - -. Remove the source node host from the {CephCluster} cluster: -+ ----- -$ sudo cephadm shell -- ceph orch host rm --force ----- -+ -[NOTE] -==== -The source node is not part of the cluster anymore, and should not appear in -the {Ceph} host list when you run `sudo cephadm shell -- ceph orch host ls`. -However, if you run `sudo podman ps` in the source node, the list might show -that both Ceph Monitors and Ceph Managers are still running. - ----- -[root@controller-1 ~]# sudo podman ps -CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES -ifeval::["{build}" != "downstream"] -5c1ad36472bc quay.io/ceph/daemon@sha256:320c364dcc8fc8120e2a42f54eb39ecdba12401a2546763b7bef15b02ce93bc4 -n mon.contro... 35 minutes ago Up 35 minutes ago ceph-f6ec3ebe-26f7-56c8-985d-eb974e8e08e3-mon-controller-1 -3b14cc7bf4dd quay.io/ceph/daemon@sha256:320c364dcc8fc8120e2a42f54eb39ecdba12401a2546763b7bef15b02ce93bc4 -n mgr.contro... 35 minutes ago Up 35 minutes ago ceph-f6ec3ebe-26f7-56c8-985d-eb974e8e08e3-mgr-controller-1-mtxohd -endif::[] -ifeval::["{build}" == "downstream"] -5c1ad36472bc registry.redhat.io/ceph/rhceph@sha256:320c364dcc8fc8120e2a42f54eb39ecdba12401a2546763b7bef15b02ce93bc4 -n mon.contro... 35 minutes ago Up 35 minutes ago ceph-f6ec3ebe-26f7-56c8-985d-eb974e8e08e3-mon-controller-1 -3b14cc7bf4dd registry.redhat.io/ceph/rhceph@sha256:320c364dcc8fc8120e2a42f54eb39ecdba12401a2546763b7bef15b02ce93bc4 -n mgr.contro... 35 minutes ago Up 35 minutes ago ceph-f6ec3ebe-26f7-56c8-985d-eb974e8e08e3-mgr-controller-1-mtxohd -endif::[] ----- -ifeval::["{build}" == "downstream"] -To clean up the existing containers and remove the `cephadm` data from the source node, contact Red Hat Support. -endif::[] -==== - -. Confirm that mons are still in quorum: -+ ----- -$ sudo cephadm shell -- ceph -s -$ sudo cephadm shell -- ceph orch ps | grep -i mon ----- - -.Next steps - -Proceed to the next step xref:migrating-the-ceph-monitor-ip-address_{context}[Migrating the Ceph Monitor IP address]. diff --git a/docs_user/modules/proc_migrating-mon-from-controller-nodes-network.adoc b/docs_user/modules/proc_migrating-mon-from-controller-nodes-network.adoc deleted file mode 100644 index 2af951d78..000000000 --- a/docs_user/modules/proc_migrating-mon-from-controller-nodes-network.adoc +++ /dev/null @@ -1,78 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="migrating-the-ceph-monitor-ip-address_{context}"] - -= Migrating the Ceph Monitor IP address - -[role="_abstract"] -You must migrate your Ceph Monitor IP addresses to the target {Ceph} nodes. The -IP address migration assumes that the target nodes are originally deployed by -{OpenStackPreviousInstaller} and that the network configuration is managed by -`os-net-config`. - -// NOTE (fpantano): we need to document the same ip address migration procedure -// w/ an EDPM node that has already been adopted. -.Procedure - -. Get the original Ceph Monitor IP addresses from `$HOME/ceph_client_backup/ceph.conf` file on the `mon_host` line, for example: -+ ----- -mon_host = [v2:172.17.3.60:3300/0,v1:172.17.3.60:6789/0] [v2:172.17.3.29:3300/0,v1:172.17.3.29:6789/0] [v2:172.17.3.53:3300/0,v1:172.17.3.53:6789/0] ----- - -. Match the IP address retrieved in the previous step with the storage network IP addresses on the source node, and find the Ceph Monitor IP address: -+ ----- -[tripleo-admin@controller-0 ~]$ ip -o -4 a | grep 172.17.3 -9: vlan30 inet 172.17.3.60/24 brd 172.17.3.255 scope global vlan30\ valid_lft forever preferred_lft forever -9: vlan30 inet 172.17.3.13/32 brd 172.17.3.255 scope global vlan30\ valid_lft forever preferred_lft forever ----- - -. Confirm that the Ceph Monitor IP address is present in the `os-net-config` configuration that is located in the `/etc/os-net-config` directory on the source node: -+ ----- -[tripleo-admin@controller-0 ~]$ grep "172.17.3.60" /etc/os-net-config/config.yaml - - ip_netmask: 172.17.3.60/24 ----- - -. Edit the `/etc/os-net-config/config.yaml` file and remove the `ip_netmask` line. - -. Save the file and refresh the node network configuration: -+ ----- -$ sudo os-net-config -c /etc/os-net-config/config.yaml ----- - -. Verify that the IP address is not present in the source node anymore, for example: -+ ----- -[controller-0]$ ip -o a | grep 172.17.3.60 ----- - -. SSH into the target node, for example `cephstorage-0`, and add the IP address -for the new Ceph Monitor. - -. On the target node, edit `/etc/os-net-config/config.yaml` and -add the `- ip_netmask: 172.17.3.60` line that you removed in the source node. - -. Save the file and refresh the node network configuration: -+ ----- -$ sudo os-net-config -c /etc/os-net-config/config.yaml ----- - -. Verify that the IP address is present in the target node. -+ ----- -$ ip -o a | grep 172.17.3.60 ----- - -. From the Ceph client node, `controller-0`, ping the IP address that is - migrated to the target node and confirm that it is still reachable: -+ ----- -[controller-0]$ ping -c 3 172.17.3.60 ----- - -.Next steps - -Proceed to the next step xref:redeploying-a-ceph-monitor-on-the-target-node_{context}[Redeploying the Ceph Monitor on the target node]. diff --git a/docs_user/modules/proc_migrating-mon-from-controller-nodes-redeploy-mon.adoc b/docs_user/modules/proc_migrating-mon-from-controller-nodes-redeploy-mon.adoc deleted file mode 100644 index 3ed6082ec..000000000 --- a/docs_user/modules/proc_migrating-mon-from-controller-nodes-redeploy-mon.adoc +++ /dev/null @@ -1,107 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="redeploying-a-ceph-monitor-on-the-target-node_{context}"] - -= Redeploying a Ceph Monitor on the target node - -[role="_abstract"] -You use the IP address that you migrated to the target node to redeploy the -Ceph Monitor on the target node. - -.Procedure - -. From the Ceph client node, for example `controller-0`, get the Ceph mon spec: -+ ----- -$ SPEC_DIR=${SPEC_DIR:-"$PWD/ceph_specs"} -$ sudo cephadm shell -- ceph orch ls --export mon > ${SPEC_DIR}/mon ----- - -. Edit the retrieved spec and add the `unmanaged: true` keyword: -+ -[source,yaml] ----- -service_type: mon -service_id: mon -placement: - label: mon -unmanaged: true ----- - -. Save the spec. - -. Apply the spec with `cephadm` by using the Ceph Orchestrator: -+ ----- -$ SPEC_DIR=${SPEC_DIR:-"$PWD/ceph_specs"} -$ sudo cephadm shell -m ${SPEC_DIR}/mon -- ceph orch apply -i /mnt/mon ----- -+ -The Ceph Monitor daemons are marked as `unmanaged`, and you can now redeploy the existing daemon and bind it to the migrated IP address. - -. Delete the existing Ceph Monitor on the target node: -+ ----- -$ sudo cephadm shell -- ceph orch daemon rm mon. --force ----- -+ -* Replace `` with the hostname of the target node that is included in the {Ceph} cluster. - -. Redeploy the new Ceph Monitor on the target node by using the migrated IP address: -+ ----- -$ sudo cephadm shell -- ceph orch daemon add mon : ----- -+ -* Replace `` with the IP address of the migrated IP address. - -. Get the Ceph Monitor spec: -+ ----- -$ SPEC_DIR=${SPEC_DIR:-"$PWD/ceph_specs"} -$ sudo cephadm shell -- ceph orch ls --export mon > ${SPEC_DIR}/mon ----- - -. Edit the retrieved spec and set the `unmanaged` keyword to `false`: -+ -[source,yaml] ----- -service_type: mon -service_id: mon -placement: - label: mon -unmanaged: false ----- - -. Save the spec. - -. Apply the spec with `cephadm` by using the Ceph Orchestrator: -+ ----- -$ SPEC_DIR=${SPEC_DIR:-"$PWD/ceph_specs"} -$ sudo cephadm shell -m ${SPEC_DIR}/mon -- ceph orch apply -i /mnt/mon ----- -+ -The new Ceph Monitor runs on the target node with the original IP address. - -. Identify the running `mgr`: -+ ----- -$ sudo cephadm shell -- ceph mgr stat ----- -+ -. Refresh the Ceph Manager information by force-failing it: -+ ----- -$ sudo cephadm shell -- ceph mgr fail ----- -+ -. Refresh the `OSD` information: -+ ----- -$ sudo cephadm shell -- ceph orch reconfig osd.default_drive_group ----- - -.Next steps - -Repeat the procedure starting from step xref:draining-the-source-node_{context}[Draining the source node] for each node that you want to decommission. -Proceed to the next step xref:verifying-the-cluster-after-ceph-mon-migration_{context}[Verifying the {CephCluster} cluster after Ceph Monitor migration]. diff --git a/docs_user/modules/proc_migrating-mon-from-controller-nodes-verification.adoc b/docs_user/modules/proc_migrating-mon-from-controller-nodes-verification.adoc deleted file mode 100644 index 5987d9039..000000000 --- a/docs_user/modules/proc_migrating-mon-from-controller-nodes-verification.adoc +++ /dev/null @@ -1,28 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="verifying-the-cluster-after-ceph-mon-migration_{context}"] - -= Verifying the {CephCluster} cluster after Ceph Monitor migration - -[role="_abstract"] -After you finish migrating your Ceph Monitor daemons to the target nodes, verify that the the {CephCluster} cluster is healthy. - -.Procedure - -. Verify that the {CephCluster} cluster is healthy: -+ ----- -$ ceph -s - cluster: - id: f6ec3ebe-26f7-56c8-985d-eb974e8e08e3 - health: HEALTH_OK -... -... ----- - -. Verify that the {CephCluster} mons are running with the old IP addresses. SSH - into the target nodes and verify that the Ceph Monitor daemons are bound to - the expected IP and port: -+ ----- -$ netstat -tulpn | grep 3300 ----- diff --git a/docs_user/modules/proc_migrating-object-storage-data-to-rhoso-nodes.adoc b/docs_user/modules/proc_migrating-object-storage-data-to-rhoso-nodes.adoc deleted file mode 100644 index e4f42547b..000000000 --- a/docs_user/modules/proc_migrating-object-storage-data-to-rhoso-nodes.adoc +++ /dev/null @@ -1,175 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="migrating-object-storage-data-to-rhoso-nodes_{context}"] - -= Migrating the {object_storage} data from {OpenStackShort} to {rhos_acro} nodes - -[role="_abstract"] -The {object_storage_first_ref} migration involves the following steps: - -. Add new nodes to the {object_storage} rings. -. Set weights of existing nodes to 0. -. Rebalance rings by moving one replica. -. Copy rings to old nodes and restart services. -. Check replication status and repeat the previous two steps until the old nodes are drained. -. Remove the old nodes from the rings. - -.Prerequisites - -* Adopt the {object_storage}. For more information, see xref:adopting-the-object-storage-service_adopt-control-plane[Adopting the {object_storage}]. -* For DNS servers, ensure that all existing nodes are able to resolve the hostnames of the {rhocp_long} pods, for example, by using the external IP of the DNSMasq service as the nameserver in `/etc/resolv.conf`: -+ ----- -$ oc get service dnsmasq-dns -o jsonpath="{.status.loadBalancer.ingress[0].ip}" | $CONTROLLER1_SSH sudo tee /etc/resolv.conf ----- -* Track the current status of the replication by using the `swift-dispersion` tool: -+ ----- -$ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-dispersion-populate' ----- -+ -The command might need a few minutes to complete. It creates 0-byte objects that are distributed across the {object_storage} deployment, and you can use the `swift-dispersion-report` afterward to show the current replication status: -+ ----- -$ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-dispersion-report' ----- -+ -The output of the `swift-dispersion-report` command looks similar to the following: -+ ----- -Queried 1024 containers for dispersion reporting, 5s, 0 retries -100.00% of container copies found (3072 of 3072) -Sample represents 100.00% of the container partition space -Queried 1024 objects for dispersion reporting, 4s, 0 retries -There were 1024 partitions missing 0 copies. -100.00% of object copies found (3072 of 3072) -Sample represents 100.00% of the object partition space ----- - -.Procedure - -. Add new nodes by scaling up the SwiftStorage resource from 0 to 3: -// TODO add paragraph / link on EDPM node usage for Swift -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge -p='{"spec":{"swift":{"template":{"swiftStorage":{"replicas": 3}}}}}' ----- -+ -This command creates three storage instances on the {rhocp_long} cluster that use Persistent Volume Claims. - -. Wait until all three pods are running and the rings include the new devices: -+ ----- -$ oc wait pods --for condition=Ready -l component=swift-storage -$ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-ring-builder object.builder search --device pv' ----- - -. From the current rings, get the storage management IP addresses of the nodes to drain: -+ ----- -$ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-ring-builder object.builder search _' | tail -n +2 | awk '{print $4}' | sort -u - ----- -+ -The output looks similar to the following: -+ ----- -172.20.0.100 -swift-storage-0.swift-storage.openstack.svc -swift-storage-1.swift-storage.openstack.svc -swift-storage-2.swift-storage.openstack.svc ----- - -. Drain the old nodes. In the following example, the old node `172.20.0.100` is drained: -+ ----- -$ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c ' -> swift-ring-tool get -> swift-ring-tool drain 172.20.0.100 -> swift-ring-tool rebalance -> swift-ring-tool push' ----- -+ -Depending on your deployment, you might have more nodes to include in the command. - -. Copy and apply the updated rings to the original nodes. Run the -ssh commands for your existing nodes that store the {object_storage} data: -+ ----- -$ oc extract --confirm cm/swift-ring-files -$ $CONTROLLER1_SSH "tar -C /var/lib/config-data/puppet-generated/swift/etc/swift/ -xzf -" < swiftrings.tar.gz -$ $CONTROLLER1_SSH "systemctl restart tripleo_swift_*" -$ $CONTROLLER2_SSH "tar -C /var/lib/config-data/puppet-generated/swift/etc/swift/ -xzf -" < swiftrings.tar.gz -$ $CONTROLLER2_SSH "systemctl restart tripleo_swift_*" -$ $CONTROLLER3_SSH "tar -C /var/lib/config-data/puppet-generated/swift/etc/swift/ -xzf -" < swiftrings.tar.gz -$ $CONTROLLER3_SSH "systemctl restart tripleo_swift_*" ----- - -. Track the replication progress by using the `swift-dispersion-report` tool: -+ ----- -$ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c "swift-ring-tool get && swift-dispersion-report" ----- -+ -The output shows less than 100% of copies found. Repeat the command until all container and object copies are found: -+ ----- -Queried 1024 containers for dispersion reporting, 6s, 0 retries -There were 5 partitions missing 1 copy. -99.84% of container copies found (3067 of 3072) -Sample represents 100.00% of the container partition space -Queried 1024 objects for dispersion reporting, 7s, 0 retries -There were 739 partitions missing 1 copy. -There were 285 partitions missing 0 copies. -75.94% of object copies found (2333 of 3072) -Sample represents 100.00% of the object partition space ----- - -+ -[NOTE] -The rebalance command moves only one replica at a time to ensure that data is available continuously. This requires running the rebalance command multiple times to complete the full rebalance operation. -Additionally, a minimum wait time of one hour between consecutive rebalance commands is -enforced to prevent moving multiple replicas at the same time. Running the -rebalance again before this period elapses has no effect. -+ - -. Move the next replica to the new nodes by rebalancing and distributing the rings: -+ ----- -$ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c ' -> swift-ring-tool get -> swift-ring-tool rebalance -> swift-ring-tool push' - -$ oc extract --confirm cm/swift-ring-files -$ $CONTROLLER1_SSH "tar -C /var/lib/config-data/puppet-generated/swift/etc/swift/ -xzf -" < swiftrings.tar.gz -$ $CONTROLLER1_SSH "systemctl restart tripleo_swift_*" ----- -+ -Monitor the `swift-dispersion-report` output again, wait until all copies are found, and then repeat this step until all your replicas are moved to the new nodes. - -. Remove the nodes from the rings: -+ ----- -$ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c ' -> swift-ring-tool get -> swift-ring-tool remove 172.20.0.100 -> swift-ring-tool rebalance -> swift-ring-tool push' ----- -+ -[NOTE] -Even if all replicas are on the new nodes and the `swift-dispersion-report` command reports 100% of the copies found, there might still be data on the old nodes. The replicators remove this data, but it might take more time. - -.Verification - -. Check the disk usage of all disks in the cluster: -+ ----- -$ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-recon -d' ----- - -. Confirm that there are no more `\*.db` or `*.data` files in the `/srv/node` directory on the nodes: -+ ----- -$CONTROLLER1_SSH "find /srv/node/ -type f -name '*.db' -o -name '*.data' | wc -l" ----- diff --git a/docs_user/modules/proc_migrating-ovn-data.adoc b/docs_user/modules/proc_migrating-ovn-data.adoc deleted file mode 100644 index 12b4edd93..000000000 --- a/docs_user/modules/proc_migrating-ovn-data.adoc +++ /dev/null @@ -1,325 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="migrating-ovn-data_{context}"] - -= Migrating OVN data - -[role="_abstract"] -Migrate the data in the OVN databases from the original {rhos_prev_long} deployment to `ovsdb-server` instances that are running in the {rhocp_long} cluster. - -.Prerequisites - -* The `OpenStackControlPlane` resource is created. -* `NetworkAttachmentDefinition` custom resources (CRs) for the original cluster are defined. Specifically, the `internalapi` network is defined. -* The original {networking_first_ref} and OVN `northd` are not running. -* The cloud is migrated to the Modular Layer 2 plug-in with Open Virtual Networking (ML2/OVN) mechanism driver. -* SSH access is available to the original {rhos_prev_long} Controller nodes to allow direct access to database files. -* Define the following shell variables. Replace the example values with values that are correct for your environment: -+ ----- -ifeval::["{build}" != "downstream"] -STORAGE_CLASS_NAME=local-storage -OVSDB_IMAGE=quay.io/podified-antelope-centos9/openstack-ovn-base:current-podified -endif::[] -ifeval::["{build}" == "downstream"] -STORAGE_CLASS=local-storage -OVSDB_IMAGE=registry.redhat.io/rhoso/openstack-ovn-base-rhel9:18.0 -endif::[] ----- -+ -ifeval::["{build_variant}" == "ospdo"] -[NOTE] -If you use a disconnected environment director Operator deployment, use -`OVSDB_IMAGE=registry.redhat.io/rhoso/openstack-ovn-base-rhel9@sha256:967046c6bdb8f55c236085b5c5f9667f0dbb9f3ac52a6560dd36a6bfac051e1f`. -For more information, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html-single/deploying_an_overcloud_in_a_red_hat_openshift_container_platform_cluster_with_director_operator/index#proc_configuring-an-airgapped-environment_air-gapped-environment[Configuring an airgapped environment] in _Deploying an overcloud in a Red Hat OpenShift Container Platform cluster with director Operator_. -endif::[] -* Ensure that you have SSH access to the original {rhos_prev_long} Controller nodes to extract database files directly from the Controller file system. - -.Procedure -ifeval::["{build_variant}" == "ospdo"] -. Get the {OpenShiftShort} master node that contains the {OpenStackShort} Controller node: -+ ----- -$ oc get vmi -n $ -o jsonpath='{.items[0].metadata.labels.kubevirt\.io/nodeName}' ----- -+ -* Replace `` with your OSPdO namespace. -endif::[] -. Convert the OVN cluster databases to standalone format on the Controller node and copy them to the local system: -+ ----- -# Set up variables for the controller SSH connection -CONTROLLER1_SSH="ssh -i ~/.ssh/id_rsa heat-admin@$CONTROLLER_IP" - -# Create working directory on controller and convert databases -$CONTROLLER1_SSH sudo mkdir -p /tmp/ovn_standalone_conversion -$CONTROLLER1_SSH sudo ovsdb-tool cluster-to-standalone /tmp/ovn_standalone_conversion/ovnnb_db.db /var/lib/openvswitch/ovn/ovnnb_db.db -$CONTROLLER1_SSH sudo ovsdb-tool cluster-to-standalone /tmp/ovn_standalone_conversion/ovnsb_db.db /var/lib/openvswitch/ovn/ovnsb_db.db -$CONTROLLER1_SSH sudo chmod 644 /tmp/ovn_standalone_conversion/ovn*.db - -# Create local directory and copy converted databases -# Note: brackets around the address are required so that IPv6 colons -# are not confused with the scp host:path separator. -mkdir -p /tmp/ovn_adoption_dbs -CONTROLLER1_SCP=$(echo "$CONTROLLER1_SSH" | sed -e 's/^ssh/scp/' -e 's/ [^ ]*$//') -CONTROLLER1_USERHOST=$(echo "$CONTROLLER1_SSH" | awk '{print $NF}') -CONTROLLER1_SCP_DEST=$(echo "$CONTROLLER1_USERHOST" | sed 's/@\(.*\)/@[\1]/') -${CONTROLLER1_SCP} ${CONTROLLER1_SCP_DEST}:/tmp/ovn_standalone_conversion/ovnnb_db.db /tmp/ovn_adoption_dbs/ -${CONTROLLER1_SCP} ${CONTROLLER1_SCP_DEST}:/tmp/ovn_standalone_conversion/ovnsb_db.db /tmp/ovn_adoption_dbs/ - -# Cleanup on controller -$CONTROLLER1_SSH sudo rm -rf /tmp/ovn_standalone_conversion ----- -+ - -. Create the `PersistentVolumeClaim` resources that will be used by the OVN database pods: -+ ----- -ifeval::["{build_variant}" != "ospdo"] -$ oc apply -f - < -f - < -f - < --timeout=30s -endif::[] ----- - -. Copy the converted standalone databases to the PVCs: -+ ----- -ifeval::["{build_variant}" != "ospdo"] -$ oc cp /tmp/ovn_adoption_dbs/ovnnb_db.db ovn-copy-data:/nb-data/ovnnb_db.db -$ oc cp /tmp/ovn_adoption_dbs/ovnsb_db.db ovn-copy-data:/sb-data/ovnsb_db.db -endif::[] -ifeval::["{build_variant}" == "ospdo"] -$ oc cp /tmp/ovn_adoption_dbs/ovnnb_db.db ovn-copy-data:/nb-data/ovnnb_db.db -n $ -$ oc cp /tmp/ovn_adoption_dbs/ovnsb_db.db ovn-copy-data:/sb-data/ovnsb_db.db -n $ -endif::[] ----- - -. Remove the helper pod now that the data is in the PVCs: -+ ----- -ifeval::["{build_variant}" != "ospdo"] -$ oc delete pod ovn-copy-data -endif::[] -ifeval::["{build_variant}" == "ospdo"] -$ oc delete pod ovn-copy-data -n $ -endif::[] ----- - -. Clean up the local temporary files: -+ ----- -$ rm -f /tmp/ovn_adoption_dbs/ovn*.db -$ rmdir /tmp/ovn_adoption_dbs ----- - -. Start the control plane OVN database services. The databases will automatically load the converted data that was populated in the PVCs: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch ' -spec: - ovn: - enabled: true - template: - ovnDBCluster: - ovndbcluster-nb: - replicas: 3 - dbType: NB - storageRequest: 10G - networkAttachment: internalapi - ovndbcluster-sb: - replicas: 3 - dbType: SB - storageRequest: 10G - networkAttachment: internalapi -' ----- -+ -[NOTE] -The OVN database pods will automatically handle schema conversion during startup and form a proper 3-replica cluster with the preserved data. - -. Wait for the OVN database services to start up: -+ ----- -$ oc wait pod --for condition=Ready --selector=service=ovsdbserver-nb --timeout=300s -$ oc wait pod --for condition=Ready --selector=service=ovsdbserver-sb --timeout=300s ----- - -. Verify that the data was successfully migrated: -+ ----- -$ oc exec -it ovsdbserver-nb-0 -- ovn-nbctl show -$ oc exec -it ovsdbserver-sb-0 -- ovn-sbctl show -$ oc exec -it ovsdbserver-sb-0 -- ovn-sbctl list Chassis ----- - -. Start the control plane `ovn-northd` service to keep both OVN databases in sync: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch ' -spec: - ovn: - enabled: true - template: - ovnNorthd: - replicas: 1 -' ----- - -. If you are running OVN gateway services on {OpenShiftShort} nodes, enable the control plane `ovn-controller` service: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch ' -spec: - ovn: - enabled: true - template: - ovnController: - nicMappings: - physNet: NIC -' ----- -+ -* `physNet` defines the name of your physical network. `NIC` is the name of the physical interface that is connected to your physical network. -+ -[NOTE] -Running OVN gateways on {OpenShiftShort} nodes might be prone to data plane downtime during Open vSwitch upgrades. Consider running OVN gateways on dedicated `Networker` data plane nodes for production deployments instead. - -. The migration is now complete. - -+ -[NOTE] -The OVN databases now contain the migrated data with preserved UUIDs. Consider taking a snapshot of the database PVCs for backup purposes. For more information, see link:{defaultOCPURL}/storage/index#lvms-about-volume-snapsot_logical-volume-manager-storage[About volume snapshots] in _OpenShift Container Platform storage overview_. - -. Stop the adopted OVN database servers: -+ ----- -ServicesToStop=("tripleo_ovn_cluster_north_db_server.service" - "tripleo_ovn_cluster_south_db_server.service") - -echo "Stopping systemd OpenStack services" -for service in ${ServicesToStop[*]}; do -ifeval::["{build_variant}" != "ospdo"] - for i in {1..3}; do - SSH_CMD=CONTROLLER${i}_SSH -endif::[] -ifeval::["{build_variant}" == "ospdo"] - SSH_CMD=CONTROLLER_SSH -endif::[] - if [ ! -z "${!SSH_CMD}" ]; then - echo "Stopping the $service in controller $i" - if ${!SSH_CMD} sudo systemctl is-active $service; then - ${!SSH_CMD} sudo systemctl stop $service - fi - fi -ifeval::["{build_variant}" != "ospdo"] - done -endif::[] -done - -echo "Checking systemd OpenStack services" -for service in ${ServicesToStop[*]}; do -ifeval::["{build_variant}" != "ospdo"] - for i in {1..3}; do - SSH_CMD=CONTROLLER${i}_SSH -endif::[] -ifeval::["{build_variant}" == "ospdo"] - SSH_CMD=CONTROLLER_SSH -endif::[] - if [ ! -z "${!SSH_CMD}" ]; then - if ! ${!SSH_CMD} systemctl show $service | grep ActiveState=inactive >/dev/null; then - echo "ERROR: Service $service still running on controller $i" - else - echo "OK: Service $service is not running on controller $i" - fi - fi -ifeval::["{build_variant}" != "ospdo"] - done -endif::[] -done ----- diff --git a/docs_user/modules/proc_migrating-the-rgw-backends.adoc b/docs_user/modules/proc_migrating-the-rgw-backends.adoc deleted file mode 100644 index 558278dd8..000000000 --- a/docs_user/modules/proc_migrating-the-rgw-backends.adoc +++ /dev/null @@ -1,178 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="migrating-the-rgw-backends_{context}"] - -= Migrating the {Ceph} RGW back ends - -[role="_abstract"] -Migrate Ceph Object Gateway (RGW) back ends from Controller nodes to {Ceph} nodes. To distribute the correct amount of services to your available nodes, use `cephadm` labels to refer to a group of nodes where a given daemon type is deployed. - -For more information about the cardinality diagram, see xref:ceph-daemon-cardinality_migrating-ceph[{Ceph} daemon cardinality]. - -The following procedure assumes that you have three target nodes, `cephstorage-0`, `cephstorage-1`, `cephstorage-2`. - -.Procedure - -. Add the RGW label to the {Ceph} nodes that you want to migrate your RGW back ends to: -+ ----- -$ sudo cephadm shell -- ceph orch host label add cephstorage-0 rgw; -$ sudo cephadm shell -- ceph orch host label add cephstorage-1 rgw; -$ sudo cephadm shell -- ceph orch host label add cephstorage-2 rgw; - -Added label rgw to host cephstorage-0 -Added label rgw to host cephstorage-1 -Added label rgw to host cephstorage-2 - -$ sudo cephadm shell -- ceph orch host ls - -HOST ADDR LABELS STATUS -cephstorage-0 192.168.24.54 osd rgw -cephstorage-1 192.168.24.44 osd rgw -cephstorage-2 192.168.24.30 osd rgw -controller-0 192.168.24.45 _admin mon mgr -controller-1 192.168.24.11 _admin mon mgr -controller-2 192.168.24.38 _admin mon mgr - -6 hosts in cluster ----- - -ifeval::["{build}" != "downstream"] -. During the overcloud deployment, a `cephadm`-compatible spec is generated in - `/home/ceph-admin/specs/rgw`. Find and patch the RGW spec, specify the right placement by using labels, - and change the RGW back-end port to `8090` to avoid conflicts with the Ceph ingress daemon front-end port. -endif::[] -ifeval::["{build}" != "upstream"] -. Locate the RGW spec and dump in the spec directory: -endif::[] -+ ----- -$ SPEC_DIR=${SPEC_DIR:-"$PWD/ceph_specs"} -$ mkdir -p ${SPEC_DIR} -$ sudo cephadm shell -- ceph orch ls --export rgw > ${SPEC_DIR}/rgw -$ cat ${SPEC_DIR}/rgw ----- -+ ----- -networks: -- 172.17.3.0/24 -placement: - hosts: - - controller-0 - - controller-1 - - controller-2 -service_id: rgw -service_name: rgw.rgw -service_type: rgw -spec: - rgw_frontend_port: 8080 - rgw_realm: default - rgw_zone: default ----- -+ -This example assumes that `172.17.3.0/24` is the `storage` network. - -. In the `placement` section, ensure that the `label` and `rgw_frontend_port` values are set: -+ ----- ---- -networks: -- 172.17.3.0/24 -placement: - label: rgw -service_id: rgw -service_name: rgw.rgw -service_type: rgw -spec: - rgw_frontend_port: 8090 - rgw_realm: default - rgw_zone: default - rgw_frontend_ssl_certificate: ... - ssl: true ----- -+ -* `networks` defines the storage network where the RGW back ends are deployed. -* `placement.label: rgw` replaces the Controller nodes with the `rgw` label. -* `spec.rgw_frontend_port` specifies the value as `8090` to avoid conflicts with the Ceph ingress daemon. -* `spec.rgw_frontend_ssl_certificate` defines the SSL certificate and key concatenation if TLS is enabled as described in link:{configuring-storage}/assembly_configuring-red-hat-ceph-storage-as-the-backend-for-rhosp-storage#proc_ceph-configure-rgw-with-tls_ceph-back-end[Configuring RGW with TLS for an external Red Hat Ceph Storage cluster] in _{configuring-storage-t}_. - -. Apply the new RGW spec by using the orchestrator CLI: -+ ----- -$ SPEC_DIR=${SPEC_DIR:-"$PWD/ceph_specs"} -$ sudo cephadm shell -m ${SPEC_DIR}/rgw -- ceph orch apply -i /mnt/rgw ----- -+ -This command triggers the redeploy, for example: -+ ----- -... -osd.9 cephstorage-2 -rgw.rgw.cephstorage-0.wsjlgx cephstorage-0 172.17.3.23:8090 starting -rgw.rgw.cephstorage-1.qynkan cephstorage-1 172.17.3.26:8090 starting -rgw.rgw.cephstorage-2.krycit cephstorage-2 172.17.3.81:8090 starting -rgw.rgw.controller-1.eyvrzw controller-1 172.17.3.146:8080 running (5h) -rgw.rgw.controller-2.navbxa controller-2 172.17.3.66:8080 running (5h) - -... -osd.9 cephstorage-2 -rgw.rgw.cephstorage-0.wsjlgx cephstorage-0 172.17.3.23:8090 running (19s) -rgw.rgw.cephstorage-1.qynkan cephstorage-1 172.17.3.26:8090 running (16s) -rgw.rgw.cephstorage-2.krycit cephstorage-2 172.17.3.81:8090 running (13s) ----- - -. Ensure that the new RGW back ends are reachable on the new ports, so you can enable an ingress daemon on port `8080` later. Log in to each {CephCluster} node that includes RGW and add the `iptables` rule to allow connections to both 8080 and 8090 ports in the {CephCluster} nodes: -+ ----- -$ iptables -I INPUT -p tcp -m tcp --dport 8080 -m conntrack --ctstate NEW -m comment --comment "ceph rgw ingress" -j ACCEPT -$ iptables -I INPUT -p tcp -m tcp --dport 8090 -m conntrack --ctstate NEW -m comment --comment "ceph rgw backends" -j ACCEPT -$ sudo iptables-save -$ sudo systemctl restart iptables ----- - -. If `nftables` is used in the existing deployment, edit `/etc/nftables/tripleo-rules.nft` -and add the following content: -+ -[source,yaml] ----- -# 100 ceph_rgw {'dport': ['8080','8090']} -add rule inet filter TRIPLEO_INPUT tcp dport { 8080,8090 } ct state new counter accept comment "100 ceph_rgw" ----- - -. Save the file. - -. Restart the `nftables` service: -+ ----- -$ sudo systemctl restart nftables ----- - -. Verify that the rules are applied: -+ ----- -$ sudo nft list ruleset | grep ceph_rgw ----- - -. From a Controller node, such as `controller-0`, try to reach the RGW back ends: -+ ----- -$ curl http://cephstorage-0.storage:8090; ----- -+ -You should observe the following output: -+ ----- -anonymous ----- -+ -Repeat the verification for each node where a RGW daemon is deployed. - -. If you migrated RGW back ends to the {Ceph} nodes, there is no `internalAPI` network, except in the case of HCI nodes. You must reconfigure the RGW keystone endpoint to point to the external network that you propagated: -+ ----- -[ceph: root@controller-0 /]# ceph config dump | grep keystone -global basic rgw_keystone_url http://172.16.1.111:5000 - -[ceph: root@controller-0 /]# ceph config set global rgw_keystone_url http://:5000 ----- -+ -* Replace `` with the {identity_service_first_ref} internal endpoint of the service that is deployed in the `OpenStackControlPlane` CR when you adopt the {identity_service}. For more information, see xref:adopting-the-identity-service_adopt-control-plane[Adopting the {identity_service}]. diff --git a/docs_user/modules/proc_migrating-tls-everywhere.adoc b/docs_user/modules/proc_migrating-tls-everywhere.adoc deleted file mode 100644 index 05d314a05..000000000 --- a/docs_user/modules/proc_migrating-tls-everywhere.adoc +++ /dev/null @@ -1,155 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="migrating-tls-everywhere_{context}"] - -= Migrating TLS-e to the {rhos_acro} deployment - -[role="_abstract"] -If you enabled TLS everywhere (TLS-e) in your {rhos_prev_long} ({OpenStackShort}) {rhos_prev_ver} deployment, you must migrate TLS-e to the {rhos_long} deployment. - -The {rhos_acro} deployment uses the cert-manager operator to issue, track, and renew the certificates. In the following procedure, you extract the CA signing certificate from the FreeIPA instance that you use to provide the certificates in the {OpenStackShort} environment, and then import them into cert-manager in the {rhos_acro} environment. As a result, you minimize the disruption on the Compute nodes because you do not need to install a new chain of trust. - -You then decommission the previous FreeIPA node and no longer use it to issue certificates. This might not be possible if you use the IPA server to issue certificates for non-{OpenStackShort} systems. - -[NOTE] -==== -* The following procedure was reproduced on a FreeIPA 4.10.1 server. The location of the files and directories might change depending on the version. - -* If the signing keys are stored in an hardware security module (HSM) instead of an NSS shared database (NSSDB), and the keys are retrievable, special HSM utilities might be required. -==== - -.Prerequisites - -* Your {OpenStackShort} deployment is using TLS-e. -* Ensure that the back-end services on the new deployment are not started yet. -* Define the following shell variables. The values are examples and refer to a single-node standalone {OpenStackPreviousInstaller} deployment. Replace these example values with values that are correct for your environment: -+ -ifeval::["{build}" != "downstream"] ----- -IPA_SSH="ssh -i ~/install_yamls/out/edpm/ansibleee-ssh-key-id_rsa root@192.168.122.100 podman exec -ti freeipa-server" ----- -+ -In this example the FreeIPA instance is running on a separate host, in a container. -endif::[] -ifeval::["{build}" == "downstream"] ----- -IPA_SSH="ssh -i @ sudo" ----- -endif::[] - - -.Procedure - -ifeval::["{build_variant}" != "ospdo"] -. To locate the CA certificate and key, list all the certificates inside your NSSDB: -+ ----- -$IPA_SSH certutil -L -d /etc/pki/pki-tomcat/alias ----- -+ -* The `-L` option lists all certificates. -* The `-d` option specifies where the certificates are stored. -+ -The command produces an output similar to the following example: -+ ----- -Certificate Nickname Trust Attributes - SSL,S/MIME,JAR/XPI - -caSigningCert cert-pki-ca CTu,Cu,Cu -ocspSigningCert cert-pki-ca u,u,u -Server-Cert cert-pki-ca u,u,u -subsystemCert cert-pki-ca u,u,u -auditSigningCert cert-pki-ca u,u,Pu ----- -endif::[] -ifeval::["{build_variant}" == "ospdo"] -. To locate the CA certificate and key, list all the certificates inside your NSSDB. If you installed OSPdO by using director-dev-tools, the server host runs the freeipa server as a container: -+ ----- -$IPA_SSH certutil -L -d /etc/pki/pki-tomcat/alias ----- -+ -* The `-L` option lists all certificates. -* The `-d` option specifies where the certificates are stored. -+ -The command produces an output similar to the following example: -+ ----- -Certificate Nickname Trust Attributes - SSL,S/MIME,JAR/XPI - -caSigningCert cert-pki-ca CTu,Cu,Cu -ocspSigningCert cert-pki-ca u,u,u -Server-Cert cert-pki-ca u,u,u -subsystemCert cert-pki-ca u,u,u -auditSigningCert cert-pki-ca u,u,Pu ----- -endif::[] -. Export the certificate and key from the `/etc/pki/pki-tomcat/alias` directory. The following example uses the `caSigningCert cert-pki-ca` certificate: -+ ----- -$IPA_SSH pk12util -o /tmp/freeipa.p12 -n 'caSigningCert\ cert-pki-ca' -d /etc/pki/pki-tomcat/alias -k /etc/pki/pki-tomcat/alias/pwdfile.txt -w /etc/pki/pki-tomcat/alias/pwdfile.txt ----- -+ -[NOTE] -==== -The command generates a P12 file with both the certificate and the key. The `/etc/pki/pki-tomcat/alias/pwdfile.txt` file contains the password that protects the key. You can use the password to both extract the key and generate the new file, `/tmp/freeipa.p12`. You can also choose another password. If you choose a different password for the new file, replace the parameter of the `-w` option, or use the `-W` option followed by the password, in clear text. - -With that file, you can also get the certificate and the key by using the `openssl pkcs12` command. -==== - -. Create the secret that contains the root CA: -+ ----- -$ oc create secret generic rootca-internal ----- - -. Import the certificate and the key from FreeIPA: -+ ----- -$ oc patch secret rootca-internal -p="{\"data\":{\"ca.crt\": \"`$IPA_SSH openssl pkcs12 -in /tmp/freeipa.p12 -passin file:/etc/pki/pki-tomcat/alias/pwdfile.txt -nokeys | openssl x509 | base64 -w 0`\"}}" - -$ oc patch secret rootca-internal -p="{\"data\":{\"tls.crt\": \"`$IPA_SSH openssl pkcs12 -in /tmp/freeipa.p12 -passin file:/etc/pki/pki-tomcat/alias/pwdfile.txt -nokeys | openssl x509 | base64 -w 0`\"}}" - -$ oc patch secret rootca-internal -p="{\"data\":{\"tls.key\": \"`$IPA_SSH openssl pkcs12 -in /tmp/freeipa.p12 -passin file:/etc/pki/pki-tomcat/alias/pwdfile.txt -nocerts -noenc | openssl rsa | base64 -w 0`\"}}" ----- - -. Create the cert-manager issuer and reference the secret: -+ ----- -$ oc apply -f - < temp/ssh.private - $OS_CLIENT cat /home/cloud-admin/.ssh/id_rsa.pub > temp/ssh.pub - echo "SSH private and public keys saved in temp/ssh.private and temp/ssh.pub" ----- -. Get the OVN configuration from each Compute node role, `OpenStackBaremetalSet`. This configuration is used later to build the `OpenStackDataPlaneNodeSet`(s). Repeat the following step for each `OpenStackBaremetalSet`: -+ ----- - # Make temp directory if doesn't exist - mkdir -p temp - # - # Query the first node in OSBMS - # - IP=$(oc -n "${OSPDO_NAMESPACE}" get openstackbaremetalsets.osp-director.openstack.org <> -ojson | jq -r '.status.baremetalHosts| keys[] as $k | .[$k].ipaddresses["ctlplane"]'| awk -F'/' '{print $1}') - # Get the OVN parameters - oc -n "${OSPDO_NAMESPACE}" exec -c openstackclient openstackclient -- \ - ssh cloud-admin@${IP} sudo ovs-vsctl -f json --columns=external_ids list Open | - jq -r '.data[0][0][1][]|join("=")' | sed -n -E 's/^(ovn.*)+=(.*)+/edpm_\1: \2/p' | - grep -v -e ovn-remote -e encap-tos -e openflow -e ofctrl > temp/<>.txt ----- -+ ----- - # Create temp directory if it does not exist - mkdir -p temp - for name in $(oc -n "${OSPDO_NAMESPACE}" get openstackbaremetalsets.osp-director.openstack.org | awk 'NR > 1 {print $1}'); do - oc -n "${OSPDO_NAMESPACE}" get openstackbaremetalsets.osp-director.openstack.org $name -ojson | - jq -r '.status.baremetalHosts| "nodes:", keys[] as $k | .[$k].ipaddresses as $a | - " \($k):", - " hostName: \($k)", - " ansible:", - " ansibleHost: \($a["ctlplane"] | sub("/\\d+"; ""))", - " networks:", ($a | to_entries[] | " - name: \(.key) \n fixedIP: \(.value | sub("/\\d+"; ""))\n subnetName: subnet1")' > temp/${name}-nodes.txt - done ----- -. Remove the conflicting repositories and packages from all Compute hosts. Define the OSPdO and {OpenStackShort} {rhos_prev_ver} Pacemaker services that must be stopped: -+ ----- -PacemakerResourcesToStop_dataplane=( - "galera-bundle" - "haproxy-bundle" - "rabbitmq-bundle") - -# Stop these PCM services after adopting control -# plane, but before starting deletion of OSPD0 (osp17) env - echo "Stopping pacemaker OpenStack services" - SSH_CMD=CONTROLLER_SSH - if [ -n "${!SSH_CMD}" ]; then - echo "Using controller 0 to run pacemaker commands " - for resource in "${PacemakerResourcesToStop_dataplane[@]}"; do - if ${!SSH_CMD} sudo pcs resource config "$resource" &>/dev/null; then - echo "Stopping $resource" - ${!SSH_CMD} sudo pcs resource disable "$resource" - else - echo "Service $resource not present" - fi - done - fi ----- -. Scale down the {rhos_acro} OpenStack Operator `controller-manager` to 0 replicas and temporarily delete the `OpenStackControlPlane` `OpenStackClient` pod, so that you can use the OSPdO `controller-manager` to clean up some of its resources. The cleanup is needed to avoid a pod name collision between the OSPdO OpenStackClient and the {rhos_acro} OpenStackClient. -+ ----- -$ oc patch csv -n openstack-operators openstack-operator.v1.0.5 --type json -p="[{"op": "replace", "path": "/spec/install/spec/deployments/0/spec/replicas", "value": "0"}]" -$ oc delete openstackclients.client.openstack.org --all ----- -+ -* Replace the CSV version with the CSV version that is deployed in the cluster. -. Delete the OSPdO `OpenStackControlPlane` custom resource (CR): -+ ----- -$ oc delete openstackcontrolplanes.osp-director.openstack.org -n "${OSPDO_NAMESPACE}" --all ----- -. Delete the OSPdO `OpenStackNetConfig` CR to remove the associated node network configuration policies: -+ ----- -$ oc delete osnetconfig -n "${OSPDO_NAMESPACE}" --all ----- -. Label the {OpenShiftShort} node that contains the OSPdO virtual machine (VM): -+ ----- -$ oc label nodes type=openstack ----- -+ -* Replace `` with the remaining master node that contains the OSPdO VM. - -. Create a node network configuration policy for the third {OpenShiftShort} node. For example: -+ ----- -$ cat << EOF > /tmp/node3_nncp.yaml -apiVersion: nmstate.io/v1 -kind: NodeNetworkConfigurationPolicy -metadata: - labels: - osp/interface: enp7s0 - name: -spec: - desiredState: - dns-resolver: - config: - search: [] - server: - - 172.22.0.1 - interfaces: - - description: internalapi vlan interface - name: enp7s0.20 - state: up - type: vlan - vlan: - base-iface: enp7s0 - id: 20 - reorder-headers: true - ipv4: - address: - - ip: 172.17.0.7 - prefix-length: 24 - enabled: true - dhcp: false - ipv6: - enabled: false - - description: storage vlan interface - name: enp7s0.30 - state: up - type: vlan - vlan: - base-iface: enp7s0 - id: 30 - reorder-headers: true - ipv4: - address: - - ip: 172.18.0.7 - prefix-length: 24 - enabled: true - dhcp: false - ipv6: - enabled: false - - description: storagemgmt vlan interface - name: enp7s0.40 - state: up - type: vlan - vlan: - base-iface: enp7s0 - id: 40 - reorder-headers: true - ipv4: - address: - - ip: 172.19.0.7 - prefix-length: 24 - enabled: true - dhcp: false - ipv6: - enabled: false - - description: tenant vlan interface - name: enp7s0.50 - state: up - type: vlan - vlan: - base-iface: enp7s0 - id: 50 - reorder-headers: true - ipv4: - address: - - ip: 172.20.0.7 - prefix-length: 24 - enabled: true - dhcp: false - ipv6: - enabled: false - - description: Configuring Bridge br-ctlplane with interface enp7s0 - name: br-ctlplane - mtu: 1500 - type: linux-bridge - state: up - bridge: - options: - stp: - enabled: false - port: - - name: enp1s0 - vlan: {} - ipv4: - address: - - ip: 172.22.0.53 - prefix-length: 24 - enabled: true - dhcp: false - ipv6: - enabled: false - - bridge: - options: - stp: - enabled: false - port: - - name: enp6s0 - description: Linux bridge with enp6s0 as a port - ipv4: - enabled: false - ipv6: - enabled: false - mtu: 1500 - name: br-external - state: up - type: linux-bridge - nodeSelector: - kubernetes.io/hostname: - node-role.kubernetes.io/worker: "" -EOF - -$ oc apply -f /tmp/node3_nncp.yaml ----- - -. Delete the remaining OSPdO resources. Do not delete the `OpenStackBaremetalSets` and `OpenStackProvisionServer` resources: -+ ----- -$ for i in $(oc get crd | grep osp-director | grep -v baremetalset | grep -v provisionserver | awk {'print $1'}); do echo Deleting $i...; oc delete $i -n "${OSPDO_NAMESPACE}" --all; done ----- - -. Scale down OSPdO to 0 replicas: -+ ----- -$ ospdo_csv_ver=$(oc get csv -n "${OSPDO_NAMESPACE}" -l operators.coreos.com/osp-director-operator.openstack -o json | jq -r '.items[0].metadata.name') -$ oc patch csv -n "${OSPDO_NAMESPACE}" $ospdo_csv_ver --type json -p="[{"op": "replace", "path": "/spec/install/spec/deployments/0/spec/replicas", "value": "0"}]" ----- - -. Remove the webhooks from OSPdO: -+ ----- -$ oc patch csv $ospdo_csv_ver -n "${OSPDO_NAMESPACE}" --type json -p="[{"op": "remove", "path": "/spec/webhookdefinitions"}]" ----- - -. Remove the finalizer from the OSPdO `OpenStackBaremetalSet` resource: -+ ----- -$ oc patch openstackbaremetalsets.osp-director.openstack.org -n "${OSPDO_NAMESPACE}" compute --type json -p="[{"op": "remove", "path": "/metadata/finalizers"}]" ----- - -. Delete the `OpenStackBaremetalSet` and `OpenStackProvisionServer` resources: -+ ----- -$ oc delete openstackbaremetalsets.osp-director.openstack.org -n "${OSPDO_NAMESPACE}" --all -$ oc delete openstackprovisionservers.osp-director.openstack.org -n "${OSPDO_NAMESPACE}" --all ----- - -. Annotate each {OpenStackShort} Compute `BareMetalHost` resource so that Metal3 does not start the node: -+ ----- -$ compute_bmh_list=$(oc get bmh -n openshift-machine-api |grep compute|awk '{printf $1 " "}') -$ for bmh_compute in $compute_bmh_list;do oc annotate bmh -n openshift-machine-api $bmh_compute baremetalhost.metal3.io/detached="";\ - oc -n openshift-machine-api wait bmh/$bmh_compute --for=jsonpath='{.status.operationalStatus}'=detached --timeout=30s || { - echo "ERROR: BMH did not enter detatched state" - exit 1 - } -done ----- -. Delete the `BareMetalHost` resource after its operational status is detached: -+ ----- - for bmh_compute in $compute_bmh_list;do \ - oc -n openshift-machine-api delete bmh $bmh_compute; \ - done ----- - -. Delete the OSPdO Operator Lifecycle Manager resources to remove OSPdO: -+ ----- -$ oc delete subscription osp-director-operator -n "${OSPDO_NAMESPACE}" -$ oc delete operatorgroup osp-director-operator -n "${OSPDO_NAMESPACE}" -$ oc delete catalogsource osp-director-operator-index -n "${OSPDO_NAMESPACE}" -$ oc delete csv $ospdo_csv_ver -n "${OSPDO_NAMESPACE}" ----- - -. Scale up the {rhos_acro} OpenStack Operator `controller-manager` to 1 replica so that the associated `OpenStackControlPlane` CR is reconciled and its `OpenStackClient` pod is recreated: -+ ----- -$ oc patch csv -n "${OSPDO_NAMESPACE}"-operators openstack-operator.v0.0.1 --type json -p="[{"op": "replace", "path": "/spec/install/spec/deployments/0/spec/replicas", "value": "1"}]" ----- diff --git a/docs_user/modules/proc_performing-a-fast-forward-upgrade-on-compute-services.adoc b/docs_user/modules/proc_performing-a-fast-forward-upgrade-on-compute-services.adoc deleted file mode 100644 index bc1573cde..000000000 --- a/docs_user/modules/proc_performing-a-fast-forward-upgrade-on-compute-services.adoc +++ /dev/null @@ -1,193 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="performing-a-fast-forward-upgrade-on-compute-services_{context}"] - -= Performing a fast-forward upgrade on Compute services - -[role="_abstract"] -You must upgrade the Compute services from {rhos_prev_long} {rhos_prev_ver} to {rhos_long} {rhos_curr_ver} on the control plane and data plane by completing the following tasks: - -* Update the cell1 Compute data plane services version. -* Remove pre-fast-forward upgrade workarounds from the Compute control plane services and Compute data plane services. -* Run Compute database online migrations to update live data. - -.Prerequisites - -* Define the shell variables necessary to apply the fast-forward upgrade commands for each {compute_service} cell. - -+ ----- -DEFAULT_CELL_NAME="cell1" -RENAMED_CELLS="$DEFAULT_CELL_NAME" - -declare -A PODIFIED_DB_ROOT_PASSWORD -for CELL in $(echo "super $RENAMED_CELLS"); do - PODIFIED_DB_ROOT_PASSWORD[$CELL]=$(oc get -o json secret/osp-secret | jq -r .data.DbRootPassword | base64 -d) -done ----- - -* Complete the steps in xref:adopting-compute-services-to-the-data-plane_data-plane[Adopting Compute services to the {rhos_acro} data plane]. - -.Procedure - -. Wait for the {compute_service} data plane services version to update for all the cells: -+ ----- -for CELL in $(echo $RENAMED_CELLS); do -oc exec openstack-$CELL-galera-0 -c galera -- mysql -rs -uroot -p"{PODIFIED_DB_ROOT_PASSWORD[$CELL]}" \ - -e "select a.version from nova_${CELL}.services a join nova_${CELL}.services b where a.version!=b.version and a.binary='nova-compute' and a.deleted=0;" -done ----- -+ -[NOTE] -==== -The query returns an empty result when the update is completed. No downtime is expected for virtual machine (VM) workloads. - -Review any errors in the nova Compute agent logs on the data plane, and the `nova-conductor` journal records on the control plane. -==== - -. Patch the `OpenStackControlPlane` CR to remove the pre-fast-forward upgrade workarounds from the Compute control plane services: -+ ----- -$ rm -f celltemplates -$ for CELL in $(echo $RENAMED_CELLS); do -$ cat >> celltemplates << EOF - ${CELL}: - metadataServiceTemplate: - customServiceConfig: | - [workarounds] - disable_compute_service_check_for_ffu=false - conductorServiceTemplate: - customServiceConfig: | - [workarounds] - disable_compute_service_check_for_ffu=false -EOF -done - -$ cat > oscp-patch.yaml << EOF -spec: - nova: - template: - apiServiceTemplate: - customServiceConfig: | - [workarounds] - disable_compute_service_check_for_ffu=false - metadataServiceTemplate: - customServiceConfig: | - [workarounds] - disable_compute_service_check_for_ffu=false - schedulerServiceTemplate: - customServiceConfig: | - [workarounds] - disable_compute_service_check_for_ffu=false - cellTemplates: - cell0: - conductorServiceTemplate: - customServiceConfig: | - [workarounds] - disable_compute_service_check_for_ffu=false -EOF -$ cat celltemplates >> oscp-patch.yaml ----- -+ -* If you are adopting the {compute_service} with the {bare_metal_first_ref}, append the following `novaComputeTemplates` in the `cell` section of the {compute_service} CR patch: -+ -[source,yaml] ----- - cell: - novaComputeTemplates: - : - customServiceConfig: | - [DEFAULT] - host = - [workarounds] - disable_compute_service_check_for_ffu=true - computeDriver: ironic.IronicDriver - ... ----- -+ -where: - -:: -Specifies the hostname of the node that is running the `ironic` Compute driver in the source cloud of `cell`. - -. Apply the patch file: -+ ----- -$ oc patch openstackcontrolplane openstack --type=merge --patch-file=oscp-patch.yaml ----- - -. Wait until the Compute control plane services CRs are ready: -+ ----- -$ oc wait --for condition=Ready --timeout=300s Nova/nova ----- - -. Remove the pre-fast-forward upgrade workarounds from the Compute data plane services: -+ ----- -$ oc patch cm nova-cells-global-config --type=json -p='[{"op": "replace", "path": "/data/99-nova-compute-cells-workarounds.conf", "value": "[workarounds]\n"}]' -$ for CELL in $(echo $RENAMED_CELLS); do -$ oc get Openstackdataplanenodeset openstack-${CELL} || continue -$ oc apply -f - <&1 || echo FAIL ----- - -.. Verify if the Compute services can stop the existing test VM instance: -+ ----- -${BASH_ALIASES[openstack]} server list -c Name -c Status -f value | grep -qF "test ACTIVE" && ${BASH_ALIASES[openstack]} server stop test || echo PASS -${BASH_ALIASES[openstack]} server list -c Name -c Status -f value | grep -qF "test SHUTOFF" || echo FAIL -${BASH_ALIASES[openstack]} server --os-compute-api-version 2.48 show --diagnostics test 2>&1 || echo PASS ----- - -.. Verify if the Compute services can start the existing test VM instance: -+ ----- -${BASH_ALIASES[openstack]} server list -c Name -c Status -f value | grep -qF "test SHUTOFF" && ${BASH_ALIASES[openstack]} server start test || echo PASS -${BASH_ALIASES[openstack]} server list -c Name -c Status -f value | grep -qF "test ACTIVE" && \ - ${BASH_ALIASES[openstack]} server --os-compute-api-version 2.48 show --diagnostics test --fit-width -f json | jq -r '.state' | grep running || echo FAIL ----- - -.Next steps -After the data plane adoption, the Compute hosts continue to run Red Hat Enterprise Linux (RHEL) {rhel_prev_ver}. To take advantage of RHEL {rhel_curr_ver}, perform a minor update procedure after finishing the adoption procedure. diff --git a/docs_user/modules/proc_performing-post-adoption-cleanup-of-load-balancers.adoc b/docs_user/modules/proc_performing-post-adoption-cleanup-of-load-balancers.adoc deleted file mode 100644 index ea32ce63b..000000000 --- a/docs_user/modules/proc_performing-post-adoption-cleanup-of-load-balancers.adoc +++ /dev/null @@ -1,70 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="performing-post-adoption-cleanup-of-load-balancers_{context}"] - -= Post-adoption tasks for the {loadbalancer_service} - -[role="_abstract"] -If you adopted the {loadbalancer_first_ref}, after you complete the data plane adoption, you must perform the following tasks: - -* Upgrade the amphorae virtual machines to the new images. -* Remove obsolete resources from your existing load balancers. - -.Prerequisites -* You have adopted the {loadbalancer_service}. For more information, see xref:adopting-the-loadbalancer-service_troubleshooting-hsm[Adopting the {loadbalancer_service}]. - -.Procedure - -. Ensure that the connectivity between the new control plane and the adopted Compute nodes is functional by creating a new load balancer and checking that its `provisioning_status` becomes `ACTIVE`: -+ ----- -$ alias openstack="oc exec -t openstackclient -- openstack" -$ openstack loadbalancer create --vip-subnet-id public-subnet --name lb-post-adoption --wait ----- - -. Trigger a failover for all existing amphora load balancers to upgrade the amphorae virtual machines to use the new image and to establish connectivity with the new control plane: -+ ----- -$ openstack loadbalancer list -f value -c id --provider amphora | \ - xargs -r -n1 -P4 ${BASH_ALIASES[openstack]} loadbalancer failover --wait ----- -+ -[NOTE] -Failover does not apply to OVN load balancers. As native components of the OVN infrastructure, they do not require actions during upgrades and updates. - -. Delete old flavors that were migrated to the new control plane: -+ ----- -$ openstack flavor delete octavia_65 -# The following flavors might not exist in OSP 17.1 deployments -$ openstack flavor show octavia_amphora-mvcpu-ha && \ - openstack flavor delete octavia_amphora-mvcpu-ha -$ openstack loadbalancer flavor show octavia_amphora-mvcpu-ha && \ - openstack loadbalancer flavor delete octavia_amphora-mvcpu-ha -$ openstack loadbalancer flavorprofile show octavia_amphora-mvcpu-ha_profile && \ - openstack loadbalancer flavorprofile delete octavia_amphora-mvcpu-ha_profile ----- -+ -[NOTE] -Some flavors might still be used by load balancers and cannot be deleted. - -. Delete the old management network and its ports: -+ ----- -$ for net_id in $(openstack network list -f value -c ID --name lb-mgmt-net); do \ - desc=$(openstack network show "$net_id" -f value -c description); \ - [ -z "$desc" ] && WALLABY_LB_MGMT_NET_ID="$net_id" ; \ - done -$ for id in $(openstack port list --network "$WALLABY_LB_MGMT_NET_ID" -f value -c ID); do \ - openstack port delete "$id" ; \ - done -$ openstack network delete "$WALLABY_LB_MGMT_NET_ID" ----- - -. Verify that only one `lb-mgmt-net` and one `lb-mgmt-subnet` exists: -+ ----- -$ openstack network list | grep lb-mgmt-net -| fe470c29-0482-4809-9996-6d636e3feea3 | lb-mgmt-net | 6a881091-097d-441c-937b-5a23f4f243b7 | -$ openstack subnet list | grep lb-mgmt-subnet -| 6a881091-097d-441c-937b-5a23f4f243b7 | lb-mgmt-subnet | fe470c29-0482-4809-9996-6d636e3feea3 | 172.24.0.0/16 | ----- diff --git a/docs_user/modules/proc_preparing-RHOSO-for-director-operator-adoption.adoc b/docs_user/modules/proc_preparing-RHOSO-for-director-operator-adoption.adoc deleted file mode 100644 index 1dad070b1..000000000 --- a/docs_user/modules/proc_preparing-RHOSO-for-director-operator-adoption.adoc +++ /dev/null @@ -1,325 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="preparing-RHOSO-for-director-operator-adoption_{context}"] - -= Preparing RHOSO for director Operator adoption - -[role="_abstract"] -When you deploy a {rhos_long} environment by using two {rhocp_long} master nodes, you must perform the following actions: - -* Create a new namespace for {rhos_acro} installation. -* Create custom node network configuration policies. -* Create `NetworkAttachmentDefinition` custom resources for each isolated network. -* Install {rhos_acro} operators. - -.Procedure - -. Save the hostnames of the remaining two nodes to the `RHOSO_NODES` variable: -+ ----- -$ RHOSO_NODES=$(oc get nodes -o name | grep -v $CONTROLLER_NODE | sed 's#node/##g' | tr '\n' ' ') ----- -. Extract nodes to be used for {rhos_acro} installation and label nodes: -+ ----- -$ export RHOSO18_NODE1=$(echo "${RHOSO_NODES}" | cut -d ' ' -f 1) -$ export RHOSO18_NODE2=$(echo "${RHOSO_NODES}" | cut -d ' ' -f 2) -$ oc label nodes "${RHOSO18_NODE1}" type=openstack -$ oc label nodes "${RHOSO18_NODE2}" type=openstack ----- - -. Create a new namespace to use to install {rhos_acro}. You must install {rhos_acro} in a different namespace from director Operator (OSPdO): -+ ----- -$ oc get namespace ${RHOSO18_NAMESPACE} 2>/dev/null || { - oc create namespace ${RHOSO18_NAMESPACE} || { - echo "Failed to create namespace ${RHOSO18_NAMESPACE}" - exit 1 - } - oc project ${RHOSO18_NAMESPACE} -} ----- - -. Create custom node network configuration policies for {rhos_acro}: -+ -[NOTE] -The node network configuration policies use the `nodeSelector` attribute to be constrained to `OSP18_NODE1/2`. The new node network configuration policy mirrors the existing node network configuration policies. In the following example, the subnets ranges are reused. In addition, the OSPdO use of bridges for the control and external interfaces is duplicated. -+ ----- -$ oc apply -f - < -spec: - desiredState: - dns-resolver: - config: - search: [] - server: - - 172.22.0.1 - interfaces: - - description: internalapi vlan interface - name: enp7s0.20 - state: up - type: vlan - vlan: - base-iface: enp7s0 - id: 20 - reorder-headers: true - ipv4: - address: - - ip: 172.17.0.5 - prefix-length: 24 - enabled: true - dhcp: false - ipv6: - enabled: false - - description: storage vlan interface - name: enp7s0.30 - state: up - type: vlan - vlan: - base-iface: enp7s0 - id: 30 - reorder-headers: true - ipv4: - address: - - ip: 172.18.0.5 - prefix-length: 24 - enabled: true - dhcp: false - ipv6: - enabled: false - - description: tenant vlan interface - name: enp7s0.50 - state: up - type: vlan - vlan: - base-iface: enp7s0 - id: 50 - reorder-headers: true - ipv4: - address: - - ip: 172.19.0.5 - prefix-length: 24 - enabled: true - dhcp: false - ipv6: - enabled: false - - description: storagemgmt vlan interface - name: enp7s0.40 - state: up - type: vlan - vlan: - base-iface: enp7s0 - id: 40 - reorder-headers: true - ipv4: - address: - - ip: 172.20.0.5 - prefix-length: 24 - enabled: true - dhcp: false - ipv6: - enabled: false - - description: Configuring Bridge ospbr with interface enp1s0 - name: br-ctlplane - mtu: 1500 - type: linux-bridge - state: up - bridge: - options: - stp: - enabled: false - port: - - name: enp1s0 - vlan: {} - ipv4: - address: - - ip: 172.22.0.51 - prefix-length: 24 - enabled: true - dhcp: false - ipv6: - enabled: false - - description: external bridge - name: br-external - type: linux-bridge - mtu: 1500 - ipv6: - enabled: false - ipv4: - enabled: false - bridge: - options: - stp: - enabled: false - port: - - name: enp6s0 - nodeSelector: - kubernetes.io/hostname: - node-role.kubernetes.io/worker: "" -EOF ----- - -* Replace `` with the name of your node. -+ -. Apply a `NetworkAttachmentDefinition` custom resource for {rhos_acro} for each isolated network to attach the service pods to the networks: -+ ----- -$ oc apply -f - <` with your OpenStack 18 namespace. - -. Ensure that the `OVNKubernetes IPForwarding` field is set to `enabled`: -+ ----- -$ oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}' --type=merge ----- - -. Extract and save passwords from OSPdO: -+ ----- -$ oc get secret tripleo-passwords -n $OSPDO_NAMESPACE -o json | jq -r '.data["tripleo-overcloud-passwords.yaml"]' | base64 -d >"${PASSWORD_FILE}" || { - echo "ERROR: Failed to extract passwords from OSPdO" - exit 1 -} ----- - -. Install the {rhos_acro} operators. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html-single/deploying_red_hat_openstack_services_on_openshift/index#assembly_installing-and-preparing-the-OpenStack-Operator[Installing and preparing the OpenStack Operator] in _{deploying-rhoso-t}_. -+ - - -. Apply the `IPAddressPool` resource that matches the new OpenStack 18 deployment to configure which IPs can be used as virtual IPs (VIPs): -+ ----- -$ oc apply -f - < ----- -+ -* Replace `` and `` with the names of the Controller nodes in your environment. - -.. Update the quorum for single node: -+ ----- -$CONTROLLER1_SSH sudo systemctl stop corosync -$CONTROLLER2_SSH sudo systemctl stop corosync -$CONTROLLER3_SSH sudo systemctl stop corosync -$CONTROLLER1_SSH sudo pcs quorum update last_man_standing=1 wait_for_all=1 -$CONTROLLER1_SSH sudo systemctl restart corosync ----- -.. Restart the Pacemaker cluster: -+ ----- -$CONTROLLER1_SSH sudo pcs cluster stop -$CONTROLLER1_SSH sudo pcs cluster start ----- -+ -.. Check that only Controller-0 is started and that the other 2 Controllers are stopped: -+ ----- -$CONTROLLER_SSH sudo pcs status ----- -.. Check if the {OpenStackShort} control plane is still operational: -+ ----- -$OS_CLIENT openstack compute service list ----- -+ -[NOTE] -You might need to wait a few minutes for the control plane to get operational. The control plane response slows down after this point. -.. When Pacemaker is only managing one of the Controllers, delete 2 of the Controller VMs. The following example specifies Controller-1 and Controller-2 VMs for deletion: -+ ----- -$ oc -n "${OSPDO_NAMESPACE}"annotate vm controller-1 osp-director.openstack.org/delete-host=true -$ oc -n "${OSPDO_NAMESPACE}"annotate vm controller-2 osp-director.openstack.org/delete-host=true ----- -.. Reduce the `roleCount` for the Controller role in the `OpenStackControlPlane` CR to `1`: -+ ----- -$ oc -n "${OSPDO_NAMESPACE}"patch OpenStackControlPlane overcloud --type json -p '[{"op": "replace", "path":"/spec/virtualMachineRoles/controller/roleCount", "value": 1}]' ----- -.. Ensure that the `OpenStackClient` pod is running on the same {OpenShiftShort} nodes as the remaining Controller VM. If the `OpenStackClient` pod is not on the same node, then move it by cordoning off the two nodes that have been freed up for {rhos_acro}. Then you delete the `OpenStackClient` pod so that it gets rescheduled on the {OpenShiftShort} node that has the remaining Controller VM. After the pod is moved to the correct node, uncordon all the nodes: -+ ----- -$ oc adm cordon $OSP18_NODE1 -$ oc adm cordon $OSP18_NODE2 -$ oc delete pod openstackclient -$ oc adm uncordon $OSP18_NODE1 -$ oc adm uncordon $OSP18_NODE2 ----- -.. Remove the OSPdO node network configuration policies from the other two nodes that are not running the Controller VM by placing a `nodeSelector` on the {OpenShiftShort} node that contains the Controller VM: -+ ----- -$ for i in br-ctlplane br-ex br-osp; do oc patch osnetconfig openstacknetconfig --type json -p '[{"op": "replace", "path": "/spec/attachConfigurations/'$i'/nodeNetworkConfigurationPolicy/nodeSelector", "value": {"kubernetes.io/hostname": "'$CONTROLLER_NODE'"}}]'; done ----- diff --git a/docs_user/modules/proc_preventing-pacemaker-from-monitoring-compute-nodes.adoc b/docs_user/modules/proc_preventing-pacemaker-from-monitoring-compute-nodes.adoc deleted file mode 100644 index aa98ab450..000000000 --- a/docs_user/modules/proc_preventing-pacemaker-from-monitoring-compute-nodes.adoc +++ /dev/null @@ -1,49 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="preventing-pacemaker-from-monitoring-compute-nodes_{context}"] - -= Preventing Pacemaker from monitoring Compute nodes - -[role="_abstract"] -You must disable Pacemaker so that it does not monitor your Compute nodes during the adoption. For example, if a network issue occurs during the adoption, Pacemaker attempts to reboot the Compute nodes to recover them, which breaks the adoption. - -.Procedure - -. Retrieve the names of the Compute remote resources: -+ ----- -$ sudo pcs stonith |grep -B1 stonith-fence_compute-fence-nova |grep Target |awk -F ': ' '{print $2}' ----- - -. Disable the stonith and `pacemaker_remote` resources on each Compute remote resource: -+ ----- -$ sudo pcs property set stonith-enabled=false -$ sudo pcs resource disable ----- -+ -where: - -``:: Specifies the name of the Compute remote resource in your environment. - -. Retrieve the name of the Compute stonith resources: -+ ----- -$ sudo pcs stonith |grep Level |grep fence_compute |awk '{print $4}' |awk -F ',' '{print $1}' |sort |uniq ----- - -. Remove the Compute node `pacemaker_remote` and fencing resources: -+ ----- -$ sudo pcs stonith disable stonith-fence_compute-fence-nova -$ sudo pcs stonith disable -$ sudo pcs stonith delete -$ sudo pcs resource delete -$ sudo pcs resource disable compute-unfence-trigger-clone -$ sudo pcs resource delete compute-unfence-trigger-clone -$ sudo pcs resource disable nova-evacuate -$ sudo pcs resource delete nova-evacuate ----- -+ -where: - -``:: Specifies the name of the Compute stonith resource in your environment. diff --git a/docs_user/modules/proc_pulling-configuration-from-a-tripleo-deployment.adoc b/docs_user/modules/proc_pulling-configuration-from-a-tripleo-deployment.adoc deleted file mode 100644 index a6b8d4837..000000000 --- a/docs_user/modules/proc_pulling-configuration-from-a-tripleo-deployment.adoc +++ /dev/null @@ -1,167 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="pulling-configuration-from-tripleo-deployment_{context}"] - -= Pulling the configuration from a {OpenStackPreviousInstaller} deployment - -[role="_abstract"] -Before you start the data plane adoption workflow, back up the configuration from the {rhos_prev_long} ({OpenStackShort}) services and {OpenStackPreviousInstaller}. You can then use the files during the configuration of the adopted services to ensure that nothing is missed or misconfigured. - -.Prerequisites - -* The os-diff tool is installed and configured. For more information, see -xref:comparing-configuration-files-between-deployments_configuring-network[Comparing configuration files between deployments]. - -ifeval::["{build}" != "downstream"] -All the services are describes in a yaml file: - -https://github.com/openstack-k8s-operators/os-diff/blob/main/config.yaml[service config parameters] -endif::[] - -.Procedure - -. Update your ssh parameters according to your environment in the `os-diff.cfg`. Os-diff uses the ssh parameters to connect to your {OpenStackPreviousInstaller} node, and then query and download the configuration files: -+ ----- -ssh_cmd=ssh -F ssh.config standalone -container_engine=podman -connection=ssh -remote_config_path=/tmp/tripleo ----- -+ -Ensure that the ssh command you provide in `ssh_cmd` parameter is correct and includes key authentication. - -. Enable the services that you want to include in the `/etc/os-diff/config.yaml` file, and disable the services that you want to exclude from the file. Ensure that you have the correct permissions to edit the file: -+ ----- -$ chown ospng:ospng /etc/os-diff/config.yaml ----- -+ -The following example enables the default {identity_service_first_ref} to be included in the `/etc/os-diff/config.yaml` file: -+ -[source,yaml] ----- -# service name and file location -services: - # Service name - keystone: - # Bool to enable/disable a service (not implemented yet) - enable: true - # Pod name, in both OCP and podman context. - # It could be strict match or will only just grep the podman_name - # and work with all the pods which matched with pod_name. - # To enable/disable use strict_pod_name_match: true/false - podman_name: keystone - pod_name: keystone - container_name: keystone-api - # pod options - # strict match for getting pod id in TripleO and podman context - strict_pod_name_match: false - # Path of the config files you want to analyze. - # It could be whatever path you want: - # /etc/ or /etc or /usr/share/ or even / - # @TODO: need to implement loop over path to support multiple paths such as: - # - /etc - # - /usr/share - path: - - /etc/ - - /etc/keystone - - /etc/keystone/keystone.conf - - /etc/keystone/logging.conf ----- -+ -Repeat this step for each {OpenStackShort} service that you want to disable or enable. - -. If you use non-containerized services, such as the `ovs-external-ids`, pull the configuration or the command output. For example: -+ ----- -services: - ovs_external_ids: - hosts: - - standalone - service_command: "ovs-vsctl list Open_vSwitch . | grep external_ids | awk -F ': ' '{ print $2; }'" - cat_output: true - path: - - ovs_external_ids.json - config_mapping: - ovn-bridge-mappings: edpm_ovn_bridge_mappings - ovn-bridge: edpm_ovn_bridge - ovn-encap-type: edpm_ovn_encap_type - ovn-monitor-all: ovn_monitor_all - ovn-remote-probe-interval: edpm_ovn_remote_probe_interval - ovn-ofctrl-wait-before-clear: edpm_ovn_ofctrl_wait_before_clear ----- -+ -[NOTE] -You must correctly configure an SSH configuration file or equivalent for non-standard services, such as OVS. The `ovs_external_ids` service does not run in a container, and the OVS data is stored on each host of your cloud, for example, `controller_1/controller_2/`, and so on. -+ -* `hosts` specifies the list of hosts, for example, `compute-1`, `compute-2`. -* `service_command: "ovs-vsctl list Open_vSwitch . | grep external_ids | awk -F ': ' '{ print $2; }'"` runs against the hosts. -* `cat_output: true` provides os-diff with the output of the command and stores the output in a file that is specified by the key path. -* `config_mapping` provides a mapping between, in this example, the data plane custom resource definition and the `ovs-vsctl` output. -* `ovn-bridge-mappings: edpm_ovn_bridge_mappings` must be a list of strings, for example, `["datacentre:br-ex"]`. - -.. Compare the values: -+ ----- -$ os-diff diff ovs_external_ids.json edpm.crd --crd --service ovs_external_ids ----- -+ -For example, to check the `/etc/yum.conf` on every host, you must put the following statement in the `config.yaml` file. The following example uses a file called `yum_config`: -+ ----- -services: - yum_config: - hosts: - - undercloud - - controller_1 - - compute_1 - - compute_2 - service_command: "cat /etc/yum.conf" - cat_output: true - path: - - yum.conf ----- - -. Pull the configuration: -+ -[NOTE] -==== -The following command pulls all the configuration files that are included in the `/etc/os-diff/config.yaml` file. You can configure os-diff to update this file automatically according to your running environment by using the `--update` or `--update-only` option. These options set the podman information into the `config.yaml` for all running containers. The podman information can be useful later, when all the {rhos_prev_long} services are turned off. - -Note that when the `config.yaml` file is populated automatically you must provide the configuration paths manually for each service. -==== -+ -[source,yaml] ----- -# will only update the /etc/os-diff/config.yaml -os-diff pull --update-only ----- -+ -[source,yaml] ----- -# will update the /etc/os-diff/config.yaml and pull configuration -os-diff pull --update ----- -+ -[source,yaml] ----- -# will update the /etc/os-diff/config.yaml and pull configuration -os-diff pull ----- -+ -The configuration is pulled and stored by default in the following directory: -+ ----- -/tmp/tripleo/ ----- - -.Verification - -* Verify that you have a directory for each service configuration in your local path: -+ ----- - ▾ tmp/ - ▾ tripleo/ - ▾ glance/ - ▾ keystone/ ----- diff --git a/docs_user/modules/proc_relocating-one-instance-of-a-monitoring-stack-to-migrate-daemons-to-target-nodes.adoc b/docs_user/modules/proc_relocating-one-instance-of-a-monitoring-stack-to-migrate-daemons-to-target-nodes.adoc deleted file mode 100644 index 165ff5994..000000000 --- a/docs_user/modules/proc_relocating-one-instance-of-a-monitoring-stack-to-migrate-daemons-to-target-nodes.adoc +++ /dev/null @@ -1,182 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="relocating-one-instance-of-a-monitoring-stack-to-migrate-daemons-to-target-nodes_{context}"] - -= Scenario 2: Relocating one instance of a monitoring stack to migrate daemons to target nodes - -[role="_abstract"] -Instead of adding a single `monitoring` label to all the target nodes, it is -possible to relocate one instance of each monitoring stack daemon on a -particular node. - -.Prerequisites -* Confirm that the firewall rules are in place and the ports are open for a given monitoring stack service. - -.Procedure - -. Set each of your nodes to host a particular daemon instance, for example, if you have three target nodes: -+ ----- -[tripleo-admin@controller-0 ~]$ sudo cephadm shell -- ceph orch host ls | grep -i cephstorage - -HOST ADDR LABELS -cephstorage-0.redhat.local 192.168.24.11 osd ---> grafana -cephstorage-1.redhat.local 192.168.24.12 osd ---> prometheus -cephstorage-2.redhat.local 192.168.24.47 osd ---> alertmanager ----- - -. Add the appropriate labels to the target nodes: -+ ----- -declare -A target_nodes - -target_nodes[grafana]=cephstorage-0 -target_nodes[prometheus]=cephstorage-1 -target_nodes[alertmanager]=cephstorage-2 - -for label in "${!target_nodes[@]}"; do - ceph orch host label add ${target_nodes[$label]} $label -done ----- - -. Verify that the labels are properly applied to the target nodes: -+ ----- -[tripleo-admin@controller-0 ~]$ sudo cephadm shell -- ceph orch host ls | grep -i cephstorage - -HOST ADDR LABELS STATUS -cephstorage-0.redhat.local 192.168.24.11 osd grafana -cephstorage-1.redhat.local 192.168.24.12 osd prometheus -cephstorage-2.redhat.local 192.168.24.47 osd alertmanager ----- - -. Dump the current monitoring stack spec: -+ ----- -function export_spec { - local component="$1" - local target_dir="$2" - sudo cephadm shell -- ceph orch ls --export "$component" > "$target_dir/$component" -} - -SPEC_DIR=${SPEC_DIR:-"$PWD/ceph_specs"} -for m in grafana prometheus alertmanager; do - export_spec "$m" "$SPEC_DIR" -done ----- - -. For each daemon, edit the current spec and replace the placement/hosts section -with the placement/label section, for example: -+ -[source,yaml] ----- -service_type: grafana -service_name: grafana -placement: - label: grafana -networks: -- 172.17.3.0/24 -spec: - port: 3100 ----- -+ -The same procedure applies to Prometheus and Alertmanager specs. - -. Apply the new monitoring spec to relocate the monitoring stack daemons: -+ ----- -SPEC_DIR=${SPEC_DIR:-"$PWD/ceph_specs"} -function migrate_daemon { - local component="$1" - local target_dir="$2" - sudo cephadm shell -m "$target_dir" -- ceph orch apply -i /mnt/ceph_specs/$component -} -for m in grafana prometheus alertmanager; do - migrate_daemon "$m" "$SPEC_DIR" -done ----- - -. Verify that the daemons are deployed on the expected nodes: -+ ----- -[ceph: root@controller-0 /]# ceph orch ps | grep -iE "(prome|alert|grafa)" -alertmanager.cephstorage-2 cephstorage-2.redhat.local 172.17.3.144:9093,9094 -grafana.cephstorage-0 cephstorage-0.redhat.local 172.17.3.83:3100 -prometheus.cephstorage-1 cephstorage-1.redhat.local 172.17.3.53:9092 ----- -+ -[NOTE] -With the procedure described above we lose High Availability: the monitoring -stack daemons have no VIP and haproxy anymore; Node exporters are still -running on all the nodes: instead of using labels we keep the current approach -as we want to not reduce the monitoring space covered. -+ -//kgilliga: What does "the procedure described above" refer to? -. Update the Ceph Dashboard Manager configuration. An important aspect that should be considered at this point is to replace and -verify that the {Ceph} configuration is aligned with the relocation you just made. Run the `ceph config dump` command and review the current config. -In particular, focus on the following configuration entries: -//kgilliga: If we're saying that customers should consider this aspect, is this step optional? -+ ----- -[ceph: root@controller-0 /]# ceph config dump -... -mgr advanced mgr/dashboard/ALERTMANAGER_API_HOST http://172.17.3.83:9093 -mgr advanced mgr/dashboard/GRAFANA_API_URL https://172.17.3.144:3100 -mgr advanced mgr/dashboard/PROMETHEUS_API_HOST http://172.17.3.83:9092 -mgr advanced mgr/dashboard/controller-0.ycokob/server_addr 172.17.3.33 -mgr advanced mgr/dashboard/controller-1.lmzpuc/server_addr 172.17.3.147 -mgr advanced mgr/dashboard/controller-2.xpdgfl/server_addr 172.17.3.138 ----- -+ -. Verify that `grafana`, `alertmanager` and `prometheus` `API_HOST/URL` point to -the IP addresses (on the storage network) of the node where each daemon has been -relocated. This should be automatically addressed by cephadm and it shouldn’t -require any manual action. -+ ----- -[ceph: root@controller-0 /]# ceph orch ps | grep -iE "(prome|alert|grafa)" -alertmanager.cephstorage-0 cephstorage-0.redhat.local 172.17.3.83:9093,9094 -alertmanager.cephstorage-1 cephstorage-1.redhat.local 172.17.3.53:9093,9094 -alertmanager.cephstorage-2 cephstorage-2.redhat.local 172.17.3.144:9093,9094 -grafana.cephstorage-0 cephstorage-0.redhat.local 172.17.3.83:3100 -grafana.cephstorage-1 cephstorage-1.redhat.local 172.17.3.53:3100 -grafana.cephstorage-2 cephstorage-2.redhat.local 172.17.3.144:3100 -prometheus.cephstorage-0 cephstorage-0.redhat.local 172.17.3.83:9092 -prometheus.cephstorage-1 cephstorage-1.redhat.local 172.17.3.53:9092 -prometheus.cephstorage-2 cephstorage-2.redhat.local 172.17.3.144:9092 ----- -+ ----- -[ceph: root@controller-0 /]# ceph config dump -... -... -mgr advanced mgr/dashboard/ALERTMANAGER_API_HOST http://172.17.3.83:9093 -mgr advanced mgr/dashboard/PROMETHEUS_API_HOST http://172.17.3.83:9092 -mgr advanced mgr/dashboard/GRAFANA_API_URL https://172.17.3.144:3100 ----- -+ -. The Ceph Dashboard (mgr module plugin) has not been impacted at all by this -relocation. The service is provided by the Ceph Manager daemon, hence we might -experience an impact when the active mgr is migrated or is force-failed. -However, having three replicas definition allows to redirect requests to a -different instance (it’s still an A/P model), hence the impact should be -limited. -.. When the RBD migration is over, the following {Ceph} config keys must -be regenerated to point to the right mgr container: -//kgilliga: Is the assumption that customers have already done the RBD migration before doing this procedure? RBD migration comes before this chapter in the adoption guide. -+ ----- -mgr advanced mgr/dashboard/controller-0.ycokob/server_addr 172.17.3.33 -mgr advanced mgr/dashboard/controller-1.lmzpuc/server_addr 172.17.3.147 -mgr advanced mgr/dashboard/controller-2.xpdgfl/server_addr 172.17.3.138 ----- -+ ----- -$ sudo cephadm shell -$ ceph orch ps | awk '/mgr./ {print $1}' ----- - -.. For each retrieved mgr, update the entry in the {Ceph} configuration: -+ ----- -$ ceph config set mgr mgr/dashboard/<>/server_addr/ ----- diff --git a/docs_user/modules/proc_resolving-HSM-secret-creation-failures.adoc b/docs_user/modules/proc_resolving-HSM-secret-creation-failures.adoc deleted file mode 100644 index 64a0ac233..000000000 --- a/docs_user/modules/proc_resolving-HSM-secret-creation-failures.adoc +++ /dev/null @@ -1,41 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="resolving-HSM-secret-creation-failures_{context}"] - -= Resolving HSM secret creation failures - -[role="_abstract"] -If hardware security module (HSM) secrets cannot be created in the target environment, check whether you need to update the names of your secrets in your source configuration file. - -Example error: - ----- -TASK [Create HSM secrets in target environment] **** -fatal: [localhost]: FAILED! => { - "msg": "Failed to create secret proteccio-data" -} ----- - -.Procedure - -. Verify target environment access: -+ -[source,bash] ----- -$ export KUBECONFIG=/path/to/.kube/config -$ oc get secrets -n openstack ----- - -. Check if secrets already exist: -+ -[source,bash] ----- -$ oc get secret proteccio-data hsm-login -n openstack ----- - -. If secrets exist with different names, update the configuration variables: -+ -[source,yaml] ----- -proteccio_login_secret_name: "your-hsm-login-secret" -proteccio_client_data_secret_name: "your-proteccio-data-secret" ----- diff --git a/docs_user/modules/proc_resolving-adoption-verification-failures.adoc b/docs_user/modules/proc_resolving-adoption-verification-failures.adoc deleted file mode 100644 index ce3a3d929..000000000 --- a/docs_user/modules/proc_resolving-adoption-verification-failures.adoc +++ /dev/null @@ -1,41 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="resolving-adoption-verification-failures_{context}"] - -= Resolving adoption verification failures - -[role="_abstract"] -If the secrets from the source environment are not accessible after adoption, verify that the database import completed successfully, test API connectivity, and check for schema adoption issues. - -Example error: - ----- -$ openstack secret list -# Returns empty list or HTTP 500 errors ----- - -.Procedure - -. Verify that the database import completed successfully: -+ ----- -$ oc exec openstack-galera-0 -n openstack -- mysql -u root -p barbican -e "SELECT COUNT(*) FROM secrets;" ----- -+ -where: - -``:: -Specifies your database password. - -. Check for schema adoption issues: -+ ----- -$ oc logs job.batch/barbican-db-sync -n openstack ----- - -. Test API connectivity: -+ ----- -$ oc exec openstackclient -n openstack -- curl -s -k -H "X-Auth-Token: $(openstack token issue -f value -c id)" https://barbican-internal.openstack.svc:9311/v1/secrets ----- - -. Verify that projects and users were adopted correctly, as secrets are project-scoped. diff --git a/docs_user/modules/proc_resolving-config-validation-failures.adoc b/docs_user/modules/proc_resolving-config-validation-failures.adoc deleted file mode 100644 index ce0d8d368..000000000 --- a/docs_user/modules/proc_resolving-config-validation-failures.adoc +++ /dev/null @@ -1,28 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="resolving-configuration-validation-failures_{context}"] - -= Resolving configuration validation failures - -[role="_abstract"] -If the adoption fails with validation errors about placeholder values, replace the placeholder values with your environment's actual configuration values. - -Example error: - ----- -TASK [Validate all required variables are set] **** -fatal: [localhost]: FAILED! => { - "msg": "Required variable proteccio_certs_path contains placeholder value." -} ----- - -.Procedure - -. Check the `OpenStackControlPlane` custom resource (CR) patch and the Kubernetes secrets that you created during the adoption procedure. - -. Verify that the following configuration values are correct for your environment and do not contain placeholder values: -+ -* The HSM PKCS#11 PIN in the `hsm-login` secret -* The HSM partition name, MKEK label, and HMAC label in the `customServiceConfig` section of the `OpenStackControlPlane` CR patch -* The Proteccio client certificate, client key, server certificate, and `proteccio.rc` configuration file in the `proteccio-data` secret - -. Verify that no placeholder values remain in your configuration before you re-run the adoption. diff --git a/docs_user/modules/proc_resolving-connectivity-issues.adoc b/docs_user/modules/proc_resolving-connectivity-issues.adoc deleted file mode 100644 index 9d6b4cc99..000000000 --- a/docs_user/modules/proc_resolving-connectivity-issues.adoc +++ /dev/null @@ -1,38 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="resolving-source-environment-connectivity-issues_{context}"] - -= Resolving source environment connectivity issues - -[role="_abstract"] -If the adoption cannot connect to the source {rhos_prev_long} environment to extract the configuration, check your SSH connectivity to the source Controller node and update the configuration if needed. - -Example error: - ----- -TASK [detect source environment HSM configuration] **** -fatal: [localhost]: FAILED! => { - "msg": "SSH connection to source environment failed" -} ----- - -.Procedure - -. Verify SSH connectivity to the source Controller node: -+ -[source,bash] ----- -$ ssh -o StrictHostKeyChecking=no tripleo-admin@controller-0.ctlplane ----- - -. Update the `controller1_ssh` variable if needed: -+ ----- -$ controller1_ssh: "ssh -o StrictHostKeyChecking=no tripleo-admin@" ----- -+ -where: - -``:: -Specifies the IP address of your Controller node. - -. Ensure that the SSH keys are properly configured for passwordless access. diff --git a/docs_user/modules/proc_resolving-custom-image-pull-failures.adoc b/docs_user/modules/proc_resolving-custom-image-pull-failures.adoc deleted file mode 100644 index c9d9e44ee..000000000 --- a/docs_user/modules/proc_resolving-custom-image-pull-failures.adoc +++ /dev/null @@ -1,46 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="resolving-custom-image-pull-failures_{context}"] - -= Resolving custom image pull failures - -[role="_abstract"] -If Proteccio custom images fail to pull or start, verify image registry access, image pull secrets, and registry authentication. - -Example error: - ----- -Failed to pull image "": rpc error -Pod has unbound immediate PersistentVolumeClaims ----- - -.Procedure - -. Verify image registry access: -+ ----- -$ podman pull ----- -+ -where: - -``:: -Specifies your custom pod image and the image tag. - - -. Check image pull secrets and registry authentication: -+ ----- -$ oc get secrets -n openstack | grep pull -$ oc describe pod -n openstack ----- -+ -where: - -``:: -Specifies your Barbican pod name. - -. Verify that the `OpenStackVersion` resource was applied correctly: -+ ----- -$ oc get openstackversion openstack -n openstack -o yaml ----- diff --git a/docs_user/modules/proc_resolving-custom-image-registry-issues.adoc b/docs_user/modules/proc_resolving-custom-image-registry-issues.adoc deleted file mode 100644 index 6d815fd2e..000000000 --- a/docs_user/modules/proc_resolving-custom-image-registry-issues.adoc +++ /dev/null @@ -1,59 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="resolving-custom-image-registry-issues_{context}"] - -= Resolving custom image registry issues - -[role="_abstract"] -If custom Barbican images cannot be pushed to or pulled from the configured registry, you can verify the authentication, test image push permissions, and then update the configuration as needed. - -Example error: - ----- -TASK [Create Proteccio-enabled Barbican images] **** -fatal: [localhost]: FAILED! => { - "msg": "Failed to push image to registry" -} ----- - -.Procedure - -. Verify registry authentication: -+ -[source,bash] ----- -$ podman login ----- -+ -where: - -``:: -Specifies the URL of your configured registry. - -. Test image push permissions: -+ -[source,bash] ----- -$ podman tag hello-world //test:latest -$ podman push //test:latest ----- -+ -where: - -``:: -Specifies the name of your registry server. -``:: -Specifies the namespace of your container image. - -. If needed, verify that the custom {key_manager} images with Proteccio client libraries are available in the registry: -+ -[source,bash] ----- -$ podman search //barbican --list-tags ----- -+ -where: - -``:: -Specifies the name of your registry server. -``:: -Specifies the namespace of your container image. diff --git a/docs_user/modules/proc_resolving-database-import-failures.adoc b/docs_user/modules/proc_resolving-database-import-failures.adoc deleted file mode 100644 index fc112fed5..000000000 --- a/docs_user/modules/proc_resolving-database-import-failures.adoc +++ /dev/null @@ -1,39 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="resolving-database-import-failures_{context}"] - -= Resolving database import failures - -[role="_abstract"] -If the source database export or import fails, check the the source Galera container, database connectivity, and the source {key_manager_first_ref} configuration. - -Example error: - ----- -Error: no container with name or ID "galera-bundle-podman-0" found -mysqldump: Got error: 1045: "Access denied for user 'barbican'@'localhost'" ----- - -.Procedure - -. Verify that the source Galera container is running: -+ ----- -$ sudo ssh -t YOUR_UNDERCLOUD_HOST 'sudo -u stack ssh -t tripleo-admin@YOUR_CONTROLLER_HOST.ctlplane "sudo podman ps | grep galera"' ----- - -. Test database connectivity with the extracted credentials: -+ ----- -$ sudo ssh -t YOUR_UNDERCLOUD_HOST 'sudo -u stack ssh -t tripleo-admin@YOUR_CONTROLLER_HOST.ctlplane "sudo podman exec galera-bundle-podman-0 mysql -u barbican -p -e \"SELECT 1;\""' ----- -+ -where: - -``:: -Specifies your database password. - -. Check the source {key_manager} configuration for the correct database password: -+ ----- -$ sudo ssh -t YOUR_UNDERCLOUD_HOST 'sudo -u stack ssh -t tripleo-admin@YOUR_CONTROLLER_HOST.ctlplane "sudo grep connection /var/lib/config-data/puppet-generated/barbican/etc/barbican/barbican.conf"' ----- diff --git a/docs_user/modules/proc_resolving-database-migration-issues.adoc b/docs_user/modules/proc_resolving-database-migration-issues.adoc deleted file mode 100644 index 103fb3bd4..000000000 --- a/docs_user/modules/proc_resolving-database-migration-issues.adoc +++ /dev/null @@ -1,35 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="resolving-database-migration-issues_{context}"] - -= Resolving database migration issues - -[role="_abstract"] -If hardware security module (HSM) metadata is not preserved during database migration, check the database logs for any errors and verify that the source database includes the HSM secrets. - -Example error: - ----- -TASK [Verify database migration preserves HSM references] **** -ok: [localhost] => { - "msg": "HSM secrets found in migrated database: 0" -} ----- - -.Procedure - -. Verify that the source database contains the HSM secrets: -+ -[source,bash] ----- -$ ssh tripleo-admin@controller-0.ctlplane \ - "sudo mysql barbican -e 'SELECT COUNT(*) FROM secret_store_metadata WHERE key=\"plugin_name\" AND value=\"PKCS11\";'" ----- - -. Check the database migration logs for errors: -+ -[source,bash] ----- -$ oc logs deployment/barbican-api | grep -i migration ----- - -. If the migration failed, restore the database from backup and retry. diff --git a/docs_user/modules/proc_resolving-hsm-backend-detection-failures.adoc b/docs_user/modules/proc_resolving-hsm-backend-detection-failures.adoc deleted file mode 100644 index b13562924..000000000 --- a/docs_user/modules/proc_resolving-hsm-backend-detection-failures.adoc +++ /dev/null @@ -1,33 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="resolving-HSM-back-end-detection-failures_{context}"] - -= Resolving HSM back-end detection failures - -[role="_abstract"] -If the {key_manager_first_ref} does not detect the hardware security module (HSM) configuration after adoption, verify that the HSM configuration exists in the source environment and that the `OpenStackControlPlane` custom resource (CR) includes the correct HSM settings. - -.Procedure - -. Verify that the HSM configuration exists in the source environment: -+ -[source,bash] ----- -$ ssh tripleo-admin@controller-0.ctlplane \ - "sudo grep -A 10 '\[p11_crypto_plugin\]' \ - /var/lib/config-data/puppet-generated/barbican/etc/barbican/barbican.conf" ----- - -. Verify that the `customServiceConfig` section in your `OpenStackControlPlane` CR patch includes the `[p11_crypto_plugin]` configuration block with the correct values from your source environment. - -. Verify that `enabledSecretStores` includes `pkcs11` and that the `pkcs11` section references the correct Kubernetes secrets: -+ -[source,yaml] ----- -enabledSecretStores: ["simple_crypto", "pkcs11"] -pkcs11: - loginSecret: hsm-login - clientDataSecret: proteccio-data - clientDataPath: /etc/proteccio ----- - -. Re-apply the `OpenStackControlPlane` CR patch if you corrected any values. diff --git a/docs_user/modules/proc_resolving-hsm-certificate-mounting-issues.adoc b/docs_user/modules/proc_resolving-hsm-certificate-mounting-issues.adoc deleted file mode 100644 index b079237a0..000000000 --- a/docs_user/modules/proc_resolving-hsm-certificate-mounting-issues.adoc +++ /dev/null @@ -1,34 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="resolving-HSM-certificate-mounting-issues_{context}"] - -= Resolving HSM certificate mounting issues - -[role="_abstract"] -If Proteccio client certificates are not properly mounted in pods, check the secret creation and ensure that the {key_manager_first_ref} configuration includes the correct volume mounts. - -Example error: - ----- -$ oc exec -c barbican-api -- ls -la /etc/proteccio/ -ls: cannot access '/etc/proteccio/': No such file or directory ----- - -.Procedure - -. Verify that the `proteccio-data` secret was created correctly: -+ ----- -$ oc describe secret proteccio-data -n openstack ----- - -. Check that the secret contains the expected files: -+ ----- -$ oc get secret proteccio-data -n openstack -o yaml ----- - -. Verify that the {key_manager} configuration includes the correct volume mounts: -+ ----- -$ oc get barbican barbican -n openstack -o yaml | grep -A10 pkcs11 ----- diff --git a/docs_user/modules/proc_resolving-missing-HSM-file-prerequisites.adoc b/docs_user/modules/proc_resolving-missing-HSM-file-prerequisites.adoc deleted file mode 100644 index fa23ec05a..000000000 --- a/docs_user/modules/proc_resolving-missing-HSM-file-prerequisites.adoc +++ /dev/null @@ -1,59 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="resolving-missing-HSM-file-prerequisites_{context}"] - -= Resolving missing HSM file prerequisites - -[role="_abstract"] -If the adoption fails because hardware security module (HSM) certificates or client software cannot be found, verify that the files exist and are accessible, and then re-create the Kubernetes secrets with the correct file paths. - -Example error: - ----- -TASK [Validate Proteccio prerequisites exist] **** -fatal: [localhost]: FAILED! => { - "msg": "Proteccio client ISO not found: /opt/proteccio/Proteccio3.06.05.iso" -} ----- - -.Procedure - -. Verify that all required HSM files exist on the host where you are running the adoption commands: -+ -[source,bash] ----- -$ ls -la -$ ls -la -$ ls -la -$ ls -la ----- -+ -where: - -``:: -Specifies the path to the HSM client certificate file. -``:: -Specifies the path to the HSM client key file. -``:: -Specifies the path to the HSM server certificate file. -``:: -Specifies the path to the `proteccio.rc` configuration file. - -. If the files are in different locations than expected, delete and re-create the `proteccio-data` secret with the correct paths: -+ -[source,bash] ----- -$ oc delete secret proteccio-data -n openstack -$ oc create secret generic proteccio-data \ - --from-file=client.crt= \ - --from-file=client.key= \ - --from-file== \ - --from-file=proteccio.rc= \ - -n openstack ----- - -. Verify that the secret was created with the expected keys: -+ -[source,bash] ----- -$ oc get secret proteccio-data -n openstack -o jsonpath='{.data}' | python3 -c "import sys,json; print(list(json.load(sys.stdin).keys()))" ----- diff --git a/docs_user/modules/proc_resolving-performance-and-connectivity-issues.adoc b/docs_user/modules/proc_resolving-performance-and-connectivity-issues.adoc deleted file mode 100644 index eddaed97c..000000000 --- a/docs_user/modules/proc_resolving-performance-and-connectivity-issues.adoc +++ /dev/null @@ -1,32 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="resolving-performance-and-connectivity-issues_{context}"] - -= Resolving performance and connectivity issues - -[role="_abstract"] -If the hardware security module (HSM) operations are slow or fail intermittently, check the HSM connectivity and monitor the HSM server logs. - -.Procedure - -. Test HSM connectivity from {key_manager_first_ref} pods: -+ -[source,bash] ----- -$ oc exec barbican-api-xyz -- pkcs11-tool --module /usr/lib64/libnethsm.so --list-slots ----- - -. Check HSM server connectivity: -+ -[source,bash] ----- -$ oc exec barbican-api-xyz -- nc -zv ----- -+ -where: - -``:: -Specifies the IP address of the HSM server. -``:: -Specifies the port of your HSM server. - -. Monitor HSM server logs for authentication or capacity issues. diff --git a/docs_user/modules/proc_resolving-prerequisite-validation-failures.adoc b/docs_user/modules/proc_resolving-prerequisite-validation-failures.adoc deleted file mode 100644 index 73a46d1d3..000000000 --- a/docs_user/modules/proc_resolving-prerequisite-validation-failures.adoc +++ /dev/null @@ -1,38 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="resolving-prerequisite-validation-failures_{context}"] - -= Resolving prerequisite validation failures - -[role="_abstract"] -If the adoption script fails during the prerequisites check, verify that your configuration includes all the required Proteccio files and that the HSM Ansible role is available. - -Example error: - ----- -ERROR: Required file proteccio_files/YOUR_CERT_FILE not found -ERROR: Cannot connect to OpenShift cluster -ERROR: Proteccio HSM Ansible role not found ----- - -.Procedure - -. Verify that all required Proteccio files are present: -+ ----- -$ ls -la /path/to/your/proteccio_files/ ----- -+ -Ensure that your configured certificate files, private key, HSM certificate file, and configuration file exist as specified in your `proteccio_required_files` configuration. - -. Test OpenShift cluster connectivity: -+ ----- -$ oc cluster-info -$ oc get pods -n openstack ----- - -. Verify that the HSM Ansible role is available: -+ ----- -$ ls -la /path/to/your/roles/ansible-role-rhoso-proteccio-hsm/ ----- diff --git a/docs_user/modules/proc_resolving-service-startup-failures.adoc b/docs_user/modules/proc_resolving-service-startup-failures.adoc deleted file mode 100644 index c915be88c..000000000 --- a/docs_user/modules/proc_resolving-service-startup-failures.adoc +++ /dev/null @@ -1,38 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="resolving-service-startup-failures_{context}"] - -= Resolving service startup failures - -[role="_abstract"] -If the {key_manager_first_ref} services fail to start after the hardware security module (HSM) configuration is applied, check the configuration in the pod. - -Example error: - ----- -$ oc get pods -l service=barbican -NAME READY STATUS RESTARTS AGE -barbican-api-xyz 0/1 Error 0 2m ----- - -.Procedure - -. Check pod logs for HSM connectivity issues: -+ -[source,bash] ----- -$ oc logs barbican-api-xyz ----- - -. Verify HSM library is accessible: -+ -[source,bash] ----- -$ oc exec barbican-api-xyz -- ls -la /usr/lib64/libnethsm.so ----- - -. Check HSM configuration in the pod: -+ -[source,bash] ----- -$ oc exec barbican-api-xyz -- cat /etc/proteccio/proteccio.rc ----- diff --git a/docs_user/modules/proc_resolving-ssh-connection-failures.adoc b/docs_user/modules/proc_resolving-ssh-connection-failures.adoc deleted file mode 100644 index d90d8b9a1..000000000 --- a/docs_user/modules/proc_resolving-ssh-connection-failures.adoc +++ /dev/null @@ -1,31 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="resolving-SSH-connection-failures_{context}"] - -= Resolving SSH connection failures to the source environment - -[role="_abstract"] -If you cannot connect to the source {OpenStackPreviousInstaller} environment, verify your SSH key access and test the SSH commands that the adoption uses. - -Example error: - ----- -Warning: Permanently added 'YOUR_UNDERCLOUD_HOST' (ED25519) to the list of known hosts. -Permission denied (publickey). ----- - -.Procedure - -. Verify SSH key access to the undercloud: -+ ----- -$ ssh YOUR_UNDERCLOUD_HOST echo "Connection test" ----- - -. Test the specific SSH commands used by the adoption: -+ ----- -$ sudo ssh -t YOUR_UNDERCLOUD_HOST 'sudo -u stack bash -lc "echo test"' -$ sudo ssh -t YOUR_UNDERCLOUD_HOST 'sudo -u stack ssh -t tripleo-admin@YOUR_CONTROLLER_HOST.ctlplane "echo test"' ----- - -. If the connection fails, verify the SSH configuration and ensure that the undercloud hostname resolves correctly. diff --git a/docs_user/modules/proc_retrieving-network-information-from-your-existing-deployment.adoc b/docs_user/modules/proc_retrieving-network-information-from-your-existing-deployment.adoc deleted file mode 100644 index 2c10164d8..000000000 --- a/docs_user/modules/proc_retrieving-network-information-from-your-existing-deployment.adoc +++ /dev/null @@ -1,70 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="retrieving-the-network-configuration_{context}"] - -= Retrieving the network configuration from your existing deployment - -[role="_abstract"] -You must determine which isolated networks are defined in your existing -deployment. After you retrieve your network configuration, you have the following information: - -* A list of isolated networks that are used in the existing deployment. -* For each of the isolated networks, the VLAN tag and IP ranges used for - dynamic address allocation. -* A list of existing IP address allocations that are used in the environment. - When reusing the existing subnet ranges to host the new control plane - services, these addresses are excluded from the corresponding allocation - pools. - -ifeval::["{build_variant}" == "ospdo"] -For more information about director Operator network configurations, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html-single/deploying_an_overcloud_in_a_red_hat_openshift_container_platform_cluster_with_director_operator/index#assembly_creating-networks-with-director-operator[Creating networks with director Operator] in _Deploying an overcloud in a Red Hat OpenShift Container Platform cluster with director Operator_. -endif::[] - -.Procedure - -. Find the network configuration in the `network_data.yaml` file. For example: -+ ----- -- name: InternalApi - mtu: 1500 - vip: true - vlan: 20 - name_lower: internal_api - dns_domain: internal.mydomain.tld. - service_net_map_replace: internal - subnets: - internal_api_subnet: - ip_subnet: '172.17.0.0/24' - allocation_pools: [{'start': '172.17.0.4', 'end': '172.17.0.250'}] ----- - -. Retrieve the VLAN tag that is used in the `vlan` key and the IP range in the - `ip_subnet` key for each isolated network from the `network_data.yaml` file. - When reusing subnet ranges from the existing deployment for the new control - plane services, the ranges are split into separate pools for control - plane services and load-balancer IP addresses. - -. Use the `tripleo-ansible-inventory.yaml` file to determine the list of IP addresses that are already consumed in the adopted environment. For each listed host in the file, make a note of the IP and VIP addresses that are consumed by the node. For example: -+ ----- -Standalone: - hosts: - standalone: - ... - internal_api_ip: 172.17.0.100 - ... - ... -standalone: - children: - Standalone: {} - vars: - ... - internal_api_vip: 172.17.0.2 - ... ----- -+ -[NOTE] -In this example, the `172.17.0.2` and `172.17.0.100` values are -consumed and are not available for the new control plane services until the adoption is complete. - -. Repeat this procedure for each isolated network and each host in the -configuration. diff --git a/docs_user/modules/proc_retrieving-topology-specific-service-configuration.adoc b/docs_user/modules/proc_retrieving-topology-specific-service-configuration.adoc deleted file mode 100644 index 57e6bbdf1..000000000 --- a/docs_user/modules/proc_retrieving-topology-specific-service-configuration.adoc +++ /dev/null @@ -1,309 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="proc_retrieving-topology-specific-service-configuration_{context}"] - -= Retrieving topology-specific service configuration - -[role="_abstract"] -Before you migrate your databases to the {rhos_long} control plane, retrieve the topology-specific service configuration from your {rhos_prev_long} ({OpenStackShort}) environment. You need this configuration for the following reasons: - -* To check your current database for inaccuracies -* To ensure that you have the data you need before the migration -* To compare your {OpenStackShort} database with the adopted {rhos_acro} database - -.Prerequisites - -. Define the following shell variables. Replace the example values with values that are correct for your environment: -[NOTE] -If you use IPv6, define the `SOURCE_MARIADB_IP` value without brackets. For example, `SOURCE_MARIADB_IP=fd00:bbbb::2`. -+ ----- -$ PASSWORD_FILE="$HOME/overcloud-passwords.yaml" -ifeval::["{build}" != "downstream"] -$ MARIADB_IMAGE=quay.io/podified-antelope-centos9/openstack-mariadb:current-podified -endif::[] -ifeval::["{build}" == "downstream"] -$ MARIADB_IMAGE=registry.redhat.io/rhoso/openstack-mariadb-rhel9:18.0 -endif::[] -$ declare -A TRIPLEO_PASSWORDS -ifeval::["{build_variant}" != "ospdo"] -$ CELLS="default cell1 cell2" -endif::[] -ifeval::["{build_variant}" == "ospdo"] -$ CELLS="default" -endif::[] -$ for CELL in $(echo $CELLS); do -> TRIPLEO_PASSWORDS[$CELL]="$PASSWORD_FILE" -> done -ifeval::["{build_variant}" == "ospdo"] -$ oc get secret tripleo-passwords -o json | jq -r '.data["tripleo-overcloud-passwords.yaml"]' | base64 -d >"${TRIPLEO_PASSWORDS[$CELLS]}" -endif::[] -$ declare -A SOURCE_DB_ROOT_PASSWORD -$ for CELL in $(echo $CELLS); do -> SOURCE_DB_ROOT_PASSWORD[$CELL]=$(cat ${TRIPLEO_PASSWORDS[$CELL]} | grep ' MysqlRootPassword:' | awk -F ': ' '{ print $2; }') -> done ----- -+ -ifeval::["{build_variant}" == "ospdo"] -* You can only deploy a single {compute service} cell on the source cloud. - -. Get the name of the {OpenShiftShort} node where the {OpenStackShort} Controller virtual machine is running: -+ ----- -$ export CONTROLLER_NODE=$(oc get vmi -ojson | jq -r '.items[0].status.nodeName') -$ export SOURCE_OVN_OVSDB_IP=$(oc get cm tripleo-exports-default -o json | jq -r '.data["ctlplane-export.yaml"]' | awk '/ovn_controller_bootstrap_node_ip/ {print $2}') ----- - -. Find the mysql service IP in the `ctlplane-export.yaml` section of the `tripleo-exports-default` ConfigMap: -+ ----- -$ cpexport=$(oc get cm tripleo-exports-default -o json | jq -r '.data["ctlplane-export.yaml"]') -$ declare -A SOURCE_MARIADB_IP -$ for CELL in $(echo $CELLS); do -> SOURCE_MARIADB_IP[$CELL]=$(echo "$cpexport" | sed -e '0,/ MysqlInternal/d' | sed -n '0,/host_nobrackets/s/^.*host_nobrackets\:\s*\(.*\)$/\1/p') -> done -$ RUN_OVERRIDES='{ -> "apiVersion": "v1", -> "metadata": { -> "annotations": { -> "k8s.v1.cni.cncf.io/networks": "[{\"name\": \"internalapi-static\",\"namespace\": \"openstack\", \"ips\":[\"172.17.0.99/24\"]}]" -> } -> }, -> "spec": { -> "nodeName": "'"$CONTROLLER_NODE"'", -> "securityContext": { -> "allowPrivilegeEscalation": false, -> "capabilities": { -> "drop": ["ALL"] -> }, -> "runAsNonRoot": true, -> "seccompProfile": { -> "type": "RuntimeDefault" -> } -> } -> } -> }' ----- -+ -* The `mariadb-client` needs to run on the same {rhocp_long} node where the {OpenStackShort} Controller node is running. In addition, the `internalapi-static` network needs to be attached to the pod. -endif::[] - -. Define the following shell variables. Replace the example values with values that are correct for your environment: -+ ----- -ifeval::["{build_variant}" != "ospdo"] -$ MARIADB_CLIENT_ANNOTATIONS='--annotations=k8s.v1.cni.cncf.io/networks=internalapi' -$ MARIADB_RUN_OVERRIDES="$MARIADB_CLIENT_ANNOTATIONS" ----- -+ -[NOTE] -==== -For environments that are enabled with border gateway protocol (BGP), the network annotation must include a default route to enable proper routing. Use the following instead: - ----- -$ MARIADB_CLIENT_ANNOTATIONS='--annotations=k8s.v1.cni.cncf.io/networks=[{"name":"internalapi","namespace":"openstack","default-route":["<172.17.0.1>"]}]' -$ MARIADB_RUN_OVERRIDES="$MARIADB_CLIENT_ANNOTATIONS" ----- -where: - -<172.17.0.1>:: -Replace with the gateway IP address of your `internalapi` network. -==== -+ ----- - -ifeval::["{build}" != "downstream"] -$ CONTROLLER1_SSH="ssh -i ~/install_yamls/out/edpm/ansibleee-ssh-key-id_rsa root@192.168.122.100" -endif::[] -ifeval::["{build}" == "downstream"] -$ CONTROLLER1_SSH="ssh -i ** tripleo-admin@**" -endif::[] -endif::[] -ifeval::["{build_variant}" == "ospdo"] -$ MARIADB_RUN_OVERRIDES="--overrides='${RUN_OVERRIDES}' $MARIADB_CLIENT_ANNOTATIONS" - -$ CONTROLLER1_SSH="oc rsh -c openstackclient openstackclient ssh controller-0.ctlplane" -$ oc get secret tripleo-passwords -o json | jq -r '.data["tripleo-overcloud-passwords.yaml"]' | -base64 -d >"${PASSWORD_FILE}" -endif::[] - -$ declare -A SOURCE_MARIADB_IP -$ SOURCE_MARIADB_IP[default]=** -ifeval::["{build_variant}" != "ospdo"] -$ SOURCE_MARIADB_IP[cell1]=** -$ SOURCE_MARIADB_IP[cell2]=** -# ... -endif::[] ----- -+ -* Provide `CONTROLLER1_SSH` settings with SSH connection details for any non-cell Controller of the source {OpenStackPreviousInstaller} cloud. -* For each cell that is defined in `CELLS`, replace `SOURCE_MARIADB_IP[*]= ...`, with the records lists for the cell names and VIP addresses of MariaDB Galera clusters, including the cells, of the source {OpenStackPreviousInstaller} cloud. -* To get the values for `SOURCE_MARIADB_IP`, query the puppet-generated configurations in a Controller -ifeval::["{build_variant}" != "ospdo"] -and CellController -endif::[] -node: -+ ----- -$ sudo grep -rI 'listen mysql' -A10 /var/lib/config-data/puppet-generated/ | grep bind ----- -+ - -[NOTE] -The source cloud always uses the same password for cells databases. For that reason, the same passwords file is used for all cells stacks. However, split-stack topology allows using different passwords files for each stack. - -.Procedure - -. If your source {OpenStackShort} environment uses border gateway protocol (BGP) for Layer 3 networking, create a `BGPConfiguration` custom resource to enable BGP routing: -+ ----- -$ cat << EOF > bgp.yaml -apiVersion: network.openstack.org/v1beta1 -kind: BGPConfiguration -metadata: - name: bgpconfiguration - namespace: openstack -spec: {} -EOF - -$ oc apply -f bgp.yaml ----- -+ -The `BGPConfiguration` resource enables BGP route advertisement between the {rhocp_long} cluster and the source cloud, which is necessary for the `mariadb-client` pod to reach the source MariaDB cluster. - -. Create a persistent `mariadb-client` pod for database operations: -+ ----- -$ oc delete pod mariadb-client || true -$ oc run mariadb-client ${MARIADB_RUN_OVERRIDES} -q --image ${MARIADB_IMAGE} --restart=Never -- /usr/bin/sleep infinity ----- -+ -This creates a long-running pod that is used for all subsequent database operations, avoiding the need to create temporary pods for each command. - -. Wait for the `mariadb-client` pod to be able to reach the source MariaDB: -+ ----- -$ oc rsh mariadb-client mysql -rsh "${SOURCE_MARIADB_IP[default]}" -uroot -p"${SOURCE_DB_ROOT_PASSWORD[default]}" -e 'select 1;' ----- -+ -[NOTE] -==== -For BGP-enabled environments, this command might take a few moments to succeed while BGP routes are advertised and propagated through the network. The `mariadb-client` pod needs to receive the route to the source MariaDB IP address through BGP before it can establish a connection. If the command fails, wait a few seconds and retry. The connection should succeed once the BGP route advertisement is complete. - -For IPv6 environments, this command might take a few moments to succeed while the network IPv6 stack completes its setup. If the command fails, wait a few seconds and retry. - -For standard deployments, such as non-BGP deployments or IPv4 deployments, this command should succeed immediately. -==== - -. Export the shell variables for the following outputs and test the connection to the {OpenStackShort} database: -+ ----- -$ unset PULL_OPENSTACK_CONFIGURATION_DATABASES -$ declare -xA PULL_OPENSTACK_CONFIGURATION_DATABASES -$ for CELL in $(echo $CELLS); do -> PULL_OPENSTACK_CONFIGURATION_DATABASES[$CELL]=$(oc rsh mariadb-client \ -> mysql -rsh "${SOURCE_MARIADB_IP[$CELL]}" -uroot -p"${SOURCE_DB_ROOT_PASSWORD[$CELL]}" -e 'SHOW databases;') -> done ----- -+ -If the connection is successful, the expected output is nothing. -+ -[NOTE] -The `nova`, `nova_api`, and `nova_cell0` databases are included in the same database host for the main overcloud {orchestration_first_ref} stack. -ifeval::["{build_variant}" != "ospdo"] -Additional cells use the `nova` database of their local Galera clusters. -endif::[] - -. Run `mysqlcheck` on the {OpenStackShort} database to check for inaccuracies: -+ ----- -$ unset PULL_OPENSTACK_CONFIGURATION_MYSQLCHECK_NOK -$ declare -xA PULL_OPENSTACK_CONFIGURATION_MYSQLCHECK_NOK -$ run_mysqlcheck() { -> PULL_OPENSTACK_CONFIGURATION_MYSQLCHECK_NOK=$(oc rsh mariadb-client \ -> mysqlcheck --all-databases -h ${SOURCE_MARIADB_IP[$CELL]} -u root -p"${SOURCE_DB_ROOT_PASSWORD[$CELL]}" | grep -v OK) -> } -$ for CELL in $(echo $CELLS); do -> run_mysqlcheck $CELL -> done -$ if [ "$PULL_OPENSTACK_CONFIGURATION_MYSQLCHECK_NOK" != "" ]; then -> for CELL in $(echo $CELLS); do -> MYSQL_UPGRADE=$(oc rsh mariadb-client \ -> mysql_upgrade --skip-version-check -v -h ${SOURCE_MARIADB_IP[$CELL]} -u root -p"${SOURCE_DB_ROOT_PASSWORD[$CELL]}") -> # rerun mysqlcheck to check if problem is resolved -> run_mysqlcheck -> done -> fi ----- - -. Get the {compute_service_first_ref} cell mappings: -+ ----- -export PULL_OPENSTACK_CONFIGURATION_NOVADB_MAPPED_CELLS=$(oc rsh mariadb-client \ - mysql -rsh "${SOURCE_MARIADB_IP[default]}" -uroot -p"${SOURCE_DB_ROOT_PASSWORD[default]}" nova_api -e \ - 'select uuid,name,transport_url,database_connection,disabled from cell_mappings;') ----- - -. Get the hostnames of the registered Compute services: -+ ----- -$ unset PULL_OPENSTACK_CONFIGURATION_NOVA_COMPUTE_HOSTNAMES -$ declare -xA PULL_OPENSTACK_CONFIGURATION_NOVA_COMPUTE_HOSTNAMES -$ for CELL in $(echo $CELLS); do -> PULL_OPENSTACK_CONFIGURATION_NOVA_COMPUTE_HOSTNAMES[$CELL]=$(oc rsh mariadb-client \ -> mysql -rsh "${SOURCE_MARIADB_IP[$CELL]}" -uroot -p"${SOURCE_DB_ROOT_PASSWORD[$CELL]}" -e \ -> "select host from nova.services where services.binary='nova-compute' and deleted=0;") -> done ----- - -. Get the list of the mapped {compute_service} cells: -+ ----- -export PULL_OPENSTACK_CONFIGURATION_NOVAMANAGE_CELL_MAPPINGS=$($CONTROLLER1_SSH sudo podman exec -it nova_conductor nova-manage cell_v2 list_cells) ----- - -. Store the exported variables for future use: -+ ----- -$ unset SRIOV_AGENTS -$ declare -xA SRIOV_AGENTS -$ for CELL in $(echo $CELLS); do -> RCELL=$CELL -> [ "$CELL" = "$DEFAULT_CELL_NAME" ] && RCELL=default -> cat > ~/.source_cloud_exported_variables_$CELL << EOF -> unset PULL_OPENSTACK_CONFIGURATION_DATABASES -> unset PULL_OPENSTACK_CONFIGURATION_MYSQLCHECK_NOK -> unset PULL_OPENSTACK_CONFIGURATION_NOVA_COMPUTE_HOSTNAMES -> declare -xA PULL_OPENSTACK_CONFIGURATION_DATABASES -> declare -xA PULL_OPENSTACK_CONFIGURATION_MYSQLCHECK_NOK -> declare -xA PULL_OPENSTACK_CONFIGURATION_NOVA_COMPUTE_HOSTNAMES -> PULL_OPENSTACK_CONFIGURATION_DATABASES[$CELL]="$(oc rsh mariadb-client \ -> mysql -rsh ${SOURCE_MARIADB_IP[$RCELL]} -uroot -p${SOURCE_DB_ROOT_PASSWORD[$RCELL]} -e 'SHOW databases;')" -> PULL_OPENSTACK_CONFIGURATION_MYSQLCHECK_NOK[$CELL]="$(oc rsh mariadb-client \ -> mysqlcheck --all-databases -h ${SOURCE_MARIADB_IP[$RCELL]} -u root -p${SOURCE_DB_ROOT_PASSWORD[$RCELL]} | grep -v OK)" -> PULL_OPENSTACK_CONFIGURATION_NOVA_COMPUTE_HOSTNAMES[$CELL]="$(oc rsh mariadb-client \ -> mysql -rsh ${SOURCE_MARIADB_IP[$RCELL]} -uroot -p${SOURCE_DB_ROOT_PASSWORD[$RCELL]} -e \ -> "select host from nova.services where services.binary='nova-compute' and deleted=0;")" -> if [ "$RCELL" = "default" ]; then -> PULL_OPENSTACK_CONFIGURATION_NOVADB_MAPPED_CELLS="$(oc rsh mariadb-client \ -> mysql -rsh ${SOURCE_MARIADB_IP[$RCELL]} -uroot -p${SOURCE_DB_ROOT_PASSWORD[$RCELL]} nova_api -e \ -> 'select uuid,name,transport_url,database_connection,disabled from cell_mappings;')" -> PULL_OPENSTACK_CONFIGURATION_NOVAMANAGE_CELL_MAPPINGS="$($CONTROLLER1_SSH sudo podman exec -it nova_conductor nova-manage cell_v2 list_cells)" -> fi -> EOF -> done -$ chmod 0600 ~/.source_cloud_exported_variables* ----- -+ -* `declare -xA SRIOV_AGENTS` gets the `neutron-sriov-nic-agent` configuration to use for the data plane adoption if `neutron-sriov-nic-agent` agents are running in your {OpenStackShort} deployment. - -. Clean up the `mariadb-client` pod: -+ ----- -$ oc delete pod mariadb-client ----- -+ -The `mariadb-client` pod is no longer needed after all the data is exported and stored. - -.Next steps - -This configuration and the exported values are required later, during the data plane adoption post-checks. After the {OpenStackShort} control plane services are shut down, if any of the exported values are lost, re-running the `export` command fails because the control plane services are no longer running on the source cloud, and the data cannot be retrieved. To avoid data loss, preserve the exported values in an environment file before shutting down the control plane services. diff --git a/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc b/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc deleted file mode 100644 index f05803a41..000000000 --- a/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc +++ /dev/null @@ -1,24 +0,0 @@ -:_mod-docs-content-type: CONCEPT -[id="reusing-existing-subnet-ranges_{context}"] - -= Reusing existing subnet ranges - -[role="_abstract"] -Configure new control plane services to reuse the subnets from the {rhos_prev_long} ({OpenStackShort}) environment, and to exclude IP addresses that are already allocated to existing cluster nodes. This avoids additional link local route configuration between the existing and new subnets. - -ifeval::["{build_variant}" != "ospdo"] -If your existing subnets do not have enough IP addresses in the existing subnet ranges for the new control plane services, you must create new subnet ranges. -endif::[] - -No special routing configuration is required to reuse subnet ranges. However, you must ensure that the IP addresses that are consumed by {OpenStackShort} services do not overlap with the new allocation pools configured for {rhos_long_noacro} control plane services. - -If you are especially constrained by the size of the existing subnet, you may -have to apply elaborate exclusion rules when defining allocation pools for the -new control plane services. - -[role="_additional-resources"] -.Additional resources -ifeval::["{build_variant}" != "ospdo"] -* xref:using-new-subnet-ranges_{context}[Using new subnet ranges] -endif::[] -* xref:configuring-isolated-networks_configuring-network[Configuring isolated networks] diff --git a/docs_user/modules/proc_rolling-back-the-control-plane-adoption.adoc b/docs_user/modules/proc_rolling-back-the-control-plane-adoption.adoc deleted file mode 100644 index 5a2fb1691..000000000 --- a/docs_user/modules/proc_rolling-back-the-control-plane-adoption.adoc +++ /dev/null @@ -1,185 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="rolling-back-control-plane-adoption_{context}"] - -= Rolling back the control plane adoption - -[role="_abstract"] -If you encountered a problem and are unable to complete the adoption of the {rhos_prev_long} ({OpenStackShort}) control plane services, you can roll back the control plane adoption. - -[IMPORTANT] -Do not attempt the rollback if you altered the data plane nodes in any way. -You can only roll back the control plane adoption if you altered the control plane. - -During the control plane adoption, services on the {OpenStackShort} control plane are stopped but not removed. The databases on the {OpenStackShort} control plane are not edited during the adoption procedure. The {rhos_long} control plane receives a copy of the original control plane databases. The rollback procedure assumes that the data plane has not yet been modified by the adoption procedure, and it is still connected to the {OpenStackShort} control plane. - -The rollback procedure consists of the following steps: - -* Restoring the functionality of the {OpenStackShort} control plane. - -* Removing the partially or fully deployed {rhos_acro} control plane. - -.Procedure - -. To restore the source cloud to a working state, start the {OpenStackShort} -control plane services that you previously stopped during the adoption -procedure: -+ ----- -ServicesToStart=("tripleo_horizon.service" - "tripleo_keystone.service" - "tripleo_barbican_api.service" - "tripleo_barbican_worker.service" - "tripleo_barbican_keystone_listener.service" - "tripleo_cinder_api.service" - "tripleo_cinder_api_cron.service" - "tripleo_cinder_scheduler.service" - "tripleo_cinder_volume.service" - "tripleo_cinder_backup.service" - "tripleo_designate_api.service" - "tripleo_designate_backend_bind9.service" - "tripleo_designate_central.service" - "tripleo_designate_mdns.service" - "tripleo_designate_producer.service" - "tripleo_designate_worker.service" - "tripleo_glance_api.service" - "tripleo_manila_api.service" - "tripleo_manila_api_cron.service" - "tripleo_manila_scheduler.service" - "tripleo_neutron_api.service" - "tripleo_placement_api.service" - "tripleo_nova_api_cron.service" - "tripleo_nova_api.service" - "tripleo_nova_conductor.service" - "tripleo_nova_metadata.service" - "tripleo_nova_scheduler.service" - "tripleo_nova_vnc_proxy.service" - "tripleo_aodh_api.service" - "tripleo_aodh_api_cron.service" - "tripleo_aodh_evaluator.service" - "tripleo_aodh_listener.service" - "tripleo_aodh_notifier.service" - "tripleo_ceilometer_agent_central.service" - "tripleo_ceilometer_agent_compute.service" - "tripleo_ceilometer_agent_ipmi.service" - "tripleo_ceilometer_agent_notification.service" - "tripleo_ovn_cluster_north_db_server.service" - "tripleo_ovn_cluster_south_db_server.service" - "tripleo_ovn_cluster_northd.service" - "tripleo_octavia_api.service" - "tripleo_octavia_health_manager.service" - "tripleo_octavia_rsyslog.service" - "tripleo_octavia_driver_agent.service" - "tripleo_octavia_housekeeping.service" - "tripleo_octavia_worker.service" - "tripleo_unbound.service") - -PacemakerResourcesToStart=("galera-bundle" - "haproxy-bundle" - "rabbitmq-bundle" - "openstack-cinder-volume" - "openstack-cinder-backup" - "openstack-manila-share") - -echo "Starting systemd OpenStack services" -for service in ${ServicesToStart[*]}; do - for i in {1..3}; do - SSH_CMD=CONTROLLER${i}_SSH - if [ ! -z "${!SSH_CMD}" ]; then - if ${!SSH_CMD} sudo systemctl is-enabled $service &> /dev/null; then - echo "Starting the $service in controller $i" - ${!SSH_CMD} sudo systemctl start $service - fi - fi - done -done - -echo "Checking systemd OpenStack services" -for service in ${ServicesToStart[*]}; do - for i in {1..3}; do - SSH_CMD=CONTROLLER${i}_SSH - if [ ! -z "${!SSH_CMD}" ]; then - if ${!SSH_CMD} sudo systemctl is-enabled $service &> /dev/null; then - if ! ${!SSH_CMD} systemctl show $service | grep ActiveState=active >/dev/null; then - echo "ERROR: Service $service is not running on controller $i" - else - echo "OK: Service $service is running in controller $i" - fi - fi - fi - done -done - -echo "Starting pacemaker OpenStack services" -for i in {1..3}; do - SSH_CMD=CONTROLLER${i}_SSH - if [ ! -z "${!SSH_CMD}" ]; then - echo "Using controller $i to run pacemaker commands" - for resource in ${PacemakerResourcesToStart[*]}; do - if ${!SSH_CMD} sudo pcs resource config $resource &>/dev/null; then - echo "Starting $resource" - ${!SSH_CMD} sudo pcs resource enable $resource - else - echo "Service $resource not present" - fi - done - break - fi -done - -echo "Checking pacemaker OpenStack services" -for i in {1..3}; do - SSH_CMD=CONTROLLER${i}_SSH - if [ ! -z "${!SSH_CMD}" ]; then - echo "Using controller $i to run pacemaker commands" - for resource in ${PacemakerResourcesToStop[*]}; do - if ${!SSH_CMD} sudo pcs resource config $resource &>/dev/null; then - if ${!SSH_CMD} sudo pcs resource status $resource | grep Started >/dev/null; then - echo "OK: Service $resource is started" - else - echo "ERROR: Service $resource is stopped" - fi - fi - done - break - fi -done ----- - -. If the Ceph NFS service is running on the deployment as a {rhos_component_storage_file_first_ref} back end, you must restore the Pacemaker order and colocation constraints for the `openstack-manila-share` service: -+ ----- - -$ sudo pcs constraint order start ceph-nfs then openstack-manila-share kind=Optional id=order-ceph-nfs-openstack-manila-share-Optional -$ sudo pcs constraint colocation add openstack-manila-share with ceph-nfs score=INFINITY id=colocation-openstack-manila-share-ceph-nfs-INFINITY - ----- - -. Verify that the source cloud is operational again, for example, you -can run `openstack` CLI commands such as `openstack server list`, or check that you can access the {dashboard_first_ref}. - -. Remove the partially or fully deployed control plane so that you can attempt the adoption again later: -+ ----- -$ oc delete --ignore-not-found=true --wait=false openstackcontrolplane/openstack -$ oc patch openstackcontrolplane openstack --type=merge --patch ' -> metadata: -> finalizers: [] -> ' || true -> ->while oc get pod | grep rabbitmq-server-0; do -> sleep 2 ->done ->while oc get pod | grep openstack-galera-0; do -> sleep 2 ->done - -$ oc delete --ignore-not-found=true --wait=false pod mariadb-copy-data -$ oc delete --ignore-not-found=true --wait=false pvc mariadb-data -$ oc delete --ignore-not-found=true --wait=false pod ovn-copy-data -$ oc delete --ignore-not-found=true secret osp-secret ----- - -.Next steps - -After you restore the {OpenStackShort} control plane services, their internal -state might have changed. Before you retry the adoption procedure, verify that all the control plane resources are removed and that there are no leftovers which could affect the following adoption procedure attempt. You must not use previously created copies of the database contents in another adoption attempt. You must make a new copy of the latest state of the original source database contents. For more information about making new copies of the database, see xref:migrating-databases-to-the-control-plane_configuring-network[Migrating databases to the control plane]. diff --git a/docs_user/modules/proc_rolling-back-the-hsm-adoption.adoc b/docs_user/modules/proc_rolling-back-the-hsm-adoption.adoc deleted file mode 100644 index df6275fe6..000000000 --- a/docs_user/modules/proc_rolling-back-the-hsm-adoption.adoc +++ /dev/null @@ -1,40 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="rolling-back-the-HSM-adoption_{context}"] - -= Rolling back the HSM adoption - -[role="_abstract"] -If the hardware security module (HSM) adoption fails, you can restore your environment to its original state and attempt the adoption again. - -.Procedure - -. Restore the {rhos_long} 18.0 database backup: -+ ----- -$ oc exec -i openstack-galera-0 -n openstack -- mysql -u root -p barbican < /path/to/your/backups/rhoso18_barbican_backup.sql ----- -+ -where: - -:: -Specifies your database password. - -. Reset to standard images: -+ ----- -$ oc delete openstackversion openstack -n openstack ----- - -. Restore the base control plane configuration: -+ ----- -$ oc apply -f /path/to/your/base_controlplane.yaml ----- - -.Next steps - -To avoid additional issues when attempting your adoption again, consider the following suggestions: - -* Check the adoption logs that are stored in your configured working directory with timestamped summary reports. -* For HSM-specific issues, consult the Proteccio documentation and verify HSM connectivity from the target environment. -* Run the adoption in dry-run mode (`./run_proteccio_adoption.sh` option 3) to validate the environment before making changes. diff --git a/docs_user/modules/proc_stopping-infrastructure-management-and-compute-services.adoc b/docs_user/modules/proc_stopping-infrastructure-management-and-compute-services.adoc deleted file mode 100644 index 5d5656061..000000000 --- a/docs_user/modules/proc_stopping-infrastructure-management-and-compute-services.adoc +++ /dev/null @@ -1,67 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="stopping-infrastructure-management-and-compute-services_{context}"] - -= Stopping infrastructure management and Compute services - -[role="_abstract"] -You must stop cloud database nodes and messaging nodes on the {rhos_prev_long} {rhos_prev_ver} control plane. Do not stop nodes that are running the following roles: - -* Compute -* Storage -* Networker -* Controller if running `OVN Controller Gateway agent` network agent - -The following procedure applies to a standalone {OpenStackPreviousInstaller} deployment. You must stop the Pacemaker services on your host so that you can install libvirt packages when the Compute roles are adopted as data plane nodes. Modular libvirt daemons no longer run in podman containers on data plane nodes. - -.Prerequisites - -* Define the shell variables. Replace the following example values with values that apply to your environment: -+ -[subs=+quotes] ----- -ifeval::["{build}" != "downstream"] -CONTROLLER1_SSH="ssh -i ~/install_yamls/out/edpm/ansibleee-ssh-key-id_rsa tripleo-admin@" -# ... -endif::[] -ifeval::["{build}" == "downstream"] -CONTROLLER1_SSH="ssh -i tripleo-admin@" -# ... -endif::[] -# ... -ifeval::["{build}" != "downstream"] -EDPM_PRIVATEKEY_PATH="~/install_yamls/out/edpm/ansibleee-ssh-key-id_rsa" -endif::[] -ifeval::["{build}" == "downstream"] -EDPM_PRIVATEKEY_PATH="" -endif::[] ----- -+ -** `CONTROLLER_SSH` defines the SSH connection details for all Controller nodes, including cell Controller nodes, of the source {OpenStackPreviousInstaller} cloud. -ifeval::["{build}" == "downstream"] -** `` defines the path to your SSH key. -endif::[] - -.Procedure - -* Stop the Pacemaker services: -+ ----- -PacemakerResourcesToStop=( - "galera-bundle" - "haproxy-bundle" - "rabbitmq-bundle") - -echo "Stopping pacemaker services" -for i in {1..3}; do - SSH_CMD=CONTROLLER${i}_SSH - if [ ! -z "${!SSH_CMD}" ]; then - echo "Using controller $i to run pacemaker commands" - for resource in ${PacemakerResourcesToStop[*]}; do - if ${!SSH_CMD} sudo pcs resource config $resource; then - ${!SSH_CMD} sudo pcs resource disable $resource - fi - done - break - fi -done ----- diff --git a/docs_user/modules/proc_stopping-openstack-services.adoc b/docs_user/modules/proc_stopping-openstack-services.adoc deleted file mode 100644 index 1776cc6bf..000000000 --- a/docs_user/modules/proc_stopping-openstack-services.adoc +++ /dev/null @@ -1,388 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="stopping-openstack-services_{context}"] - -= Stopping {rhos_prev_long} services - -[role="_abstract"] -Before you start the {rhos_long} adoption, you must stop the {rhos_prev_long} ({OpenStackShort}) services to avoid inconsistencies in the data that you migrate for the data plane adoption. Inconsistencies are caused by resource changes after the database is copied to the new deployment. - -You should not stop the infrastructure management services yet, such as: - -* Database -* RabbitMQ -* HAProxy Load Balancer -* Ceph-nfs -* Compute service -* Containerized modular libvirt daemons -* {object_storage_first_ref} back-end services - -.Prerequisites - -* Ensure that there no long-running tasks that require the services that you plan to stop, such as instance live migrations, volume migrations, volume creation, backup and restore, attaching, detaching, and other similar operations: -+ ----- -$ openstack server list --all-projects -c ID -c Status |grep -E '\| .+ing \|' -$ openstack volume list --all-projects -c ID -c Status |grep -E '\| .+ing \|'| grep -vi error -$ openstack volume backup list --all-projects -c ID -c Status |grep -E '\| .+ing \|' | grep -vi error -$ openstack share list --all-projects -c ID -c Status |grep -E '\| .+ing \|'| grep -vi error -$ openstack image list -c ID -c Status |grep -E '\| .+ing \|' ----- -* Collect the services topology-specific configuration. For more information, see xref:proc_retrieving-topology-specific-service-configuration_migrating-databases[Retrieving topology-specific service configuration]. -* Define the following shell variables. The values are examples and refer to a single node standalone {OpenStackPreviousInstaller} deployment. Replace these example values with values that are correct for your environment: -+ -[subs=+quotes] ----- -ifeval::["{build}" != "downstream"] -CONTROLLER1_SSH="ssh -i ~/install_yamls/out/edpm/ansibleee-ssh-key-id_rsa root@192.168.122.100" -endif::[] -ifeval::["{build}" == "downstream"] -CONTROLLER1_SSH="ssh -i ** tripleo-admin@**" -CONTROLLER2_SSH="ssh -i ** tripleo-admin@**" -CONTROLLER3_SSH="ssh -i ** tripleo-admin@**" -endif::[] ----- -* Specify the IP addresses of all Controller nodes, for example: -+ -[subs=+quotes] ----- -ifeval::["{build}" != "downstream"] -CONTROLLER1_SSH="ssh -i ~/install_yamls/out/edpm/ansibleee-ssh-key-id_rsa root@192.168.122.103" -CONTROLLER2_SSH="ssh -i ~/install_yamls/out/edpm/ansibleee-ssh-key-id_rsa root@192.168.122.106" -CONTROLLER3_SSH="ssh -i ~/install_yamls/out/edpm/ansibleee-ssh-key-id_rsa root@192.168.122.109" -endif::[] -ifeval::["{build}" == "downstream"] -CONTROLLER1_SSH="ssh -i ** tripleo-admin@**" -CONTROLLER2_SSH="ssh -i ** tripleo-admin@**" -CONTROLLER3_SSH="ssh -i ** tripleo-admin@**" -# ... -endif::[] ----- -ifeval::["{build}" == "downstream"] -+ -** `` defines the path to your SSH key. -** ` IP>` defines the IP addresses of all Controller nodes. -endif::[] - -.Procedure - -. If your deployment enables CephFS through NFS as a back end for {rhos_component_storage_file_first_ref}, remove the following Pacemaker ordering and co-location constraints that govern the Virtual IP address of the `ceph-nfs` service and the `manila-share` service: -+ -[source,yaml] ----- -# check the co-location and ordering constraints concerning "manila-share" -sudo pcs constraint list --full - -# remove these constraints -sudo pcs constraint remove colocation-openstack-manila-share-ceph-nfs-INFINITY -sudo pcs constraint remove order-ceph-nfs-openstack-manila-share-Optional ----- - -. Disable {OpenStackShort} control plane services: -+ -[source,yaml] ----- -# Update the services list to be stopped -ServicesToStop=("tripleo_aodh_api.service" - "tripleo_aodh_api_cron.service" - "tripleo_aodh_evaluator.service" - "tripleo_aodh_listener.service" - "tripleo_aodh_notifier.service" - "tripleo_ceilometer_agent_central.service" - "tripleo_ceilometer_agent_notification.service" - "tripleo_designate_api.service" - "tripleo_designate_backend_bind9.service" - "tripleo_designate_central.service" - "tripleo_designate_mdns.service" - "tripleo_designate_producer.service" - "tripleo_designate_worker.service" - "tripleo_octavia_api.service" - "tripleo_octavia_health_manager.service" - "tripleo_octavia_rsyslog.service" - "tripleo_octavia_driver_agent.service" - "tripleo_octavia_housekeeping.service" - "tripleo_octavia_worker.service" - "tripleo_horizon.service" - "tripleo_keystone.service" - "tripleo_barbican_api.service" - "tripleo_barbican_worker.service" - "tripleo_barbican_keystone_listener.service" - "tripleo_cinder_api.service" - "tripleo_cinder_api_cron.service" - "tripleo_cinder_scheduler.service" - "tripleo_cinder_volume.service" - "tripleo_cinder_backup.service" - "tripleo_collectd.service" - "tripleo_glance_api.service" - "tripleo_gnocchi_api.service" - "tripleo_gnocchi_metricd.service" - "tripleo_gnocchi_statsd.service" - "tripleo_manila_api.service" - "tripleo_manila_api_cron.service" - "tripleo_manila_scheduler.service" - "tripleo_neutron_api.service" - "tripleo_placement_api.service" - "tripleo_nova_api_cron.service" - "tripleo_nova_api.service" - "tripleo_nova_conductor.service" - "tripleo_nova_metadata.service" - "tripleo_nova_scheduler.service" - "tripleo_nova_vnc_proxy.service" - "tripleo_aodh_api.service" - "tripleo_aodh_api_cron.service" - "tripleo_aodh_evaluator.service" - "tripleo_aodh_listener.service" - "tripleo_aodh_notifier.service" - "tripleo_ceilometer_agent_central.service" - "tripleo_ceilometer_agent_compute.service" - "tripleo_ceilometer_agent_ipmi.service" - "tripleo_ceilometer_agent_notification.service" - "tripleo_ovn_cluster_northd.service" - "tripleo_ironic_neutron_agent.service" - "tripleo_ironic_api.service" - "tripleo_ironic_inspector.service" - "tripleo_ironic_conductor.service" - "tripleo_ironic_inspector_dnsmasq.service" - "tripleo_ironic_pxe_http.service" - "tripleo_ironic_pxe_tftp.service" - "tripleo_unbound.service") - -PacemakerResourcesToStop=("openstack-cinder-volume" - "openstack-cinder-backup" - "openstack-manila-share") - -echo "Stopping systemd OpenStack services" -for service in ${ServicesToStop[*]}; do -ifeval::["{build_variant}" != "ospdo"] - for i in {1..3}; do - SSH_CMD=CONTROLLER${i}_SSH -endif::[] -ifeval::["{build_variant}" == "ospdo"] - SSH_CMD=CONTROLLER_SSH -endif::[] - if [ ! -z "${!SSH_CMD}" ]; then - echo "Stopping the $service in controller $i" - if ${!SSH_CMD} sudo systemctl is-active $service; then - ${!SSH_CMD} sudo systemctl stop $service - fi - fi -ifeval::["{build_variant}" != "ospdo"] - done -endif::[] -done - -echo "Checking systemd OpenStack services" -for service in ${ServicesToStop[*]}; do - for i in {1..3}; do - SSH_CMD=CONTROLLER${i}_SSH - if [ ! -z "${!SSH_CMD}" ]; then - if ! ${!SSH_CMD} systemctl show $service | grep ActiveState=inactive >/dev/null; then - echo "ERROR: Service $service still running on controller $i" - else - echo "OK: Service $service is not running on controller $i" - fi - fi - done -done - -echo "Stopping pacemaker OpenStack services" -ifeval::["{build_variant}" != "ospdo"] -for i in {1..3}; do - SSH_CMD=CONTROLLER${i}_SSH -endif::[] -ifeval::["{build_variant}" == "ospdo"] - SSH_CMD=CONTROLLER_SSH -endif::[] - if [ ! -z "${!SSH_CMD}" ]; then - echo "Using controller $i to run pacemaker commands" - for resource in ${PacemakerResourcesToStop[*]}; do - if ${!SSH_CMD} sudo pcs resource config $resource &>/dev/null; then - echo "Stopping $resource" - ${!SSH_CMD} sudo pcs resource disable $resource - else - echo "Service $resource not present" - fi -ifeval::["{build_variant}" != "ospdo"] - done -endif::[] - break - fi -done - -echo "Checking pacemaker OpenStack services" -ifeval::["{build_variant}" != "ospdo"] -for i in {1..3}; do - SSH_CMD=CONTROLLER${i}_SSH -endif::[] -ifeval::["{build_variant}" == "ospdo"] - SSH_CMD=CONTROLLER_SSH -endif::[] - if [ ! -z "${!SSH_CMD}" ]; then - echo "Using controller $i to run pacemaker commands" - for resource in ${PacemakerResourcesToStop[*]}; do - if ${!SSH_CMD} sudo pcs resource config $resource &>/dev/null; then - if ! ${!SSH_CMD} sudo pcs resource status $resource | grep Started; then - echo "OK: Service $resource is stopped" - else - echo "ERROR: Service $resource is started" - fi - fi - done - break - fi -ifeval::["{build_variant}" != "ospdo"] - done -endif::[] ----- -+ -If the status of each service is `OK`, then the services stopped successfully. - -. For Distributed Compute Node (DCN) deployments where {image_service}, {block_storage}, and {Ceph} services run on edge Compute nodes, stop the {image_service}, {block_storage}, and etcd services on all edge Compute nodes with the `DistributedComputeHCI` role: -+ -[NOTE] -==== -The `DistributedComputeHCI` role runs `GlanceApiEdge`, `CinderVolumeEdge`, and `Etcd` services. A minimum of three nodes per site use this role. Skip this step if your DCN deployment does not run these services on edge Compute nodes. The examples in this procedure use hyper-converged (HCI) roles. If your deployment does not use HCI, the same services apply to the `DistributedCompute` role, which runs the same `GlanceApiEdge`, `CinderVolumeEdge`, and `Etcd` services but without Ceph OSD, Ceph Monitor, or Ceph Manager. -==== -+ -.. Define shell variables for your `DistributedComputeHCI` edge Compute nodes: -+ -[subs=+quotes] ----- -# DCN1 edge site DistributedComputeHCI nodes -DCN1_HCI0_SSH="ssh -i ** tripleo-admin@**" -DCN1_HCI1_SSH="ssh -i ** tripleo-admin@**" -DCN1_HCI2_SSH="ssh -i ** tripleo-admin@**" - -# DCN2 edge site DistributedComputeHCI nodes -DCN2_HCI0_SSH="ssh -i ** tripleo-admin@**" -DCN2_HCI1_SSH="ssh -i ** tripleo-admin@**" -DCN2_HCI2_SSH="ssh -i ** tripleo-admin@**" ----- -+ -where: - -``:: -Specifies the path to your SSH key for each `DistributedComputeHCI` edge Compute node on each DCN edge site. - -``, ``, ``:: -Specifies the IP address for each `DistributedComputeHCI` edge Compute node within the DCN1 edge site. - -``, ``, ``:: -Specifies the IP address for each `DistributedComputeHCI` edge Compute node within the DCN2 edge site. -+ -.. Stop the storage services on all `DistributedComputeHCI` nodes: -+ ----- -# Services to stop on DistributedComputeHCI edge compute nodes -DCN_HCI_SERVICES=("tripleo_glance_api_internal.service" - "tripleo_cinder_volume.service" - "tripleo_etcd.service") - -# List of all DistributedComputeHCI node SSH commands -DCN_HCI_NODES=("$DCN1_HCI0_SSH" - "$DCN1_HCI1_SSH" - "$DCN1_HCI2_SSH" - "$DCN2_HCI0_SSH" - "$DCN2_HCI1_SSH" - "$DCN2_HCI2_SSH") - -echo "Stopping storage services on DistributedComputeHCI nodes" -for node_ssh in "${DCN_HCI_NODES[@]}"; do - [ -z "$node_ssh" ] && continue - echo "Processing node: $node_ssh" - for service in "${DCN_HCI_SERVICES[@]}"; do - if $node_ssh sudo systemctl is-active $service 2>/dev/null; then - echo "Stopping $service" - $node_ssh sudo systemctl stop $service - fi - done -done - -echo "Checking storage services on DistributedComputeHCI nodes" -for node_ssh in "${DCN_HCI_NODES[@]}"; do - [ -z "$node_ssh" ] && continue - for service in "${DCN_HCI_SERVICES[@]}"; do - if ! $node_ssh systemctl show $service 2>/dev/null | grep ActiveState=inactive >/dev/null; then - echo "ERROR: Service $service still running on $node_ssh" - else - echo "OK: Service $service is not running on $node_ssh" - fi - done -done ----- -+ -[NOTE] -==== -* On edge sites, the {image_service} runs with the service name `tripleo_glance_api_internal.service`, which is different from the `tripleo_glance_api.service` on the central controller. -* The {block_storage} volume service (`tripleo_cinder_volume.service`) uses the same service name on both edge sites and the central controller. -* The etcd service (`tripleo_etcd.service`) is used as a distributed lock manager (DLM) for the {block_storage} volume service running in active/active mode on edge sites. -==== - -. If your DCN deployment includes `DistributedComputeHCIScaleOut` nodes, stop the HAProxy service on those nodes: -+ -[NOTE] -==== -The `DistributedComputeHCIScaleOut` role is used to scale compute and storage capacity beyond the initial three `DistributedComputeHCI` nodes at each site. These nodes run `HAProxyEdge`, which proxies {image_service} requests to the `GlanceApiEdge` instances on `DistributedComputeHCI` nodes. Skip this step if your DCN deployment does not include `DistributedComputeHCIScaleOut` nodes. For non-HCI deployments, the equivalent role is `DistributedComputeScaleOut`, which runs the same `HAProxyEdge` service. -==== -+ -.. Define shell variables for your `DistributedComputeHCIScaleOut` edge Compute nodes: -+ -[subs=+quotes] ----- -# DCN1 edge site DistributedComputeHCIScaleOut nodes -DCN1_SCALEOUT0_SSH="ssh -i ** tripleo-admin@**" -DCN1_SCALEOUT1_SSH="ssh -i ** tripleo-admin@**" - -# DCN2 edge site DistributedComputeHCIScaleOut nodes -DCN2_SCALEOUT0_SSH="ssh -i ** tripleo-admin@**" -DCN2_SCALEOUT1_SSH="ssh -i ** tripleo-admin@**" ----- -+ -where: - -``, ``:: -Specifies the IP address for each `DistributedComputeHCIScaleOut` node within the DCN1 edge site. - -``, ``:: -Specifies the IP address for each `DistributedComputeHCIScaleOut` node within the DCN2 edge site. -+ -.. Stop the services on all `DistributedComputeHCIScaleOut` nodes: -+ ----- -# Services to stop on DistributedComputeHCIScaleOut edge compute nodes -DCN_SCALEOUT_SERVICES=("tripleo_haproxy_edge.service") - -# List of all DistributedComputeHCIScaleOut node SSH commands -DCN_SCALEOUT_NODES=("$DCN1_SCALEOUT0_SSH" - "$DCN1_SCALEOUT1_SSH" - "$DCN2_SCALEOUT0_SSH" - "$DCN2_SCALEOUT1_SSH") - -echo "Stopping services on DistributedComputeHCIScaleOut nodes" -for node_ssh in "${DCN_SCALEOUT_NODES[@]}"; do - [ -z "$node_ssh" ] && continue - echo "Processing node: $node_ssh" - for service in "${DCN_SCALEOUT_SERVICES[@]}"; do - if $node_ssh sudo systemctl is-active $service 2>/dev/null; then - echo "Stopping $service" - $node_ssh sudo systemctl stop $service - fi - done -done - -echo "Checking services on DistributedComputeHCIScaleOut nodes" -for node_ssh in "${DCN_SCALEOUT_NODES[@]}"; do - [ -z "$node_ssh" ] && continue - for service in "${DCN_SCALEOUT_SERVICES[@]}"; do - if ! $node_ssh systemctl show $service 2>/dev/null | grep ActiveState=inactive >/dev/null; then - echo "ERROR: Service $service still running on $node_ssh" - else - echo "OK: Service $service is not running on $node_ssh" - fi - done -done ----- -+ -[NOTE] -==== -* The HAProxy edge service (`tripleo_haproxy_edge.service`) provided a local {image_service} endpoint on `DistributedComputeHCIScaleOut` nodes, proxying requests to the `GlanceApiEdge` instances on `DistributedComputeHCI` nodes. During adoption, {rhocp_long} Kubernetes service endpoints backed by MetalLB replace HAProxy. -==== diff --git a/docs_user/modules/proc_updating-shiftstack-credentials.adoc b/docs_user/modules/proc_updating-shiftstack-credentials.adoc deleted file mode 100644 index a4591859e..000000000 --- a/docs_user/modules/proc_updating-shiftstack-credentials.adoc +++ /dev/null @@ -1,106 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="updating-shiftstack-credentials_{context}"] - -= Updating {OpenShiftShort} on {OpenStackShort} credentials and recovering the image-registry operator - -[role="_abstract"] -After adoption, update {rhocp_long} clusters with installer-provisioned infrastructure to reference the new keystone endpoint in the cloud credentials instead of the {OpenStackPreviousInstaller} endpoint. This facilitates authentication with keystone and avoids timeouts. - -[IMPORTANT] -Run all commands against the guest {OpenShiftShort} cluster that is running on {OpenStackShort} VMs, not the underlying {rhos_acro} host cluster. - -.Procedure - -. Verify the stale secret on the {OpenShiftShort} on {OpenStackShort} cluster: -+ ----- -$ oc get secret openstack-credentials -n kube-system \ - -o jsonpath='{.data.clouds\.yaml}' | base64 -d | grep auth_url ----- -+ -The output shows the {OpenStackPreviousInstaller} endpoint that can no longer be used after adoption. For example, https://overcloud.redhat.local:13000 or http://:5000. - -. Check if the new {rhos_acro} keystone is reachable from the {OpenShiftShort} on {OpenStackShort} cluster nodes: -+ ----- -$ RHOSO_AUTH_URL="http://keystone-public-openstack.apps." -$ oc debug node/$(oc get nodes -o jsonpath='{.items[0].metadata.name}') \ - -- chroot /host curl -sk -m 10 "${RHOSO_AUTH_URL}/v3/" ----- -+ -[IMPORTANT] -If the command returns a JSON response with keystone version information, proceed to step 3. If the command times out, the {rhos_acro} endpoint is not reachable from the {OpenShiftShort} on {OpenStackShort} cluster's network. You can still proceed with steps 3-5 because the credential update and image-registry fix will work regardless of {OpenStackShort} reachability. However, operators such as OCCM and CSI will continue logging timeout errors until the {rhos_acro} endpoint becomes reachable from the guest nodes. - -. Update the source secret with the {rhos_acro} endpoint: -+ -[NOTE] -The {OpenShiftShort} on {OpenStackShort} user, password, and project are preserved after adoption. Adoption uses the same keystone database as the one used in {rhos_prev_long} ({OpenStackShort}) 17.1. Only the `auth_url` needs to change. If {rhos_acro} uses HTTPS with a different certificate authority, update the `cacert` path too. -+ ----- -$ oc get secret openstack-credentials -n kube-system \ - -o jsonpath='{.data.clouds\.yaml}' | base64 -d > /tmp/clouds.yaml -# Edit /tmp/clouds.yaml: change auth_url to the RHOSO keystone endpoint -$ B64=$(base64 < /tmp/clouds.yaml | tr -d '\n') -$ oc patch secret openstack-credentials -n kube-system \ - -p "{\"data\":{\"clouds.yaml\":\"${B64}\"}}" ----- - -. Wait for Cloud Credential Operator (CCO) to propagate the source secret to all namespace-specific secrets, and then verify that the new {rhos_acro} endpoint is reachable: -+ ----- -$ oc get secret installer-cloud-credentials -n openshift-image-registry \ - -o jsonpath='{.data.clouds\.yaml}' | base64 -d | grep auth_url ----- -+ -[NOTE] -The output should show the new {rhos_acro} endpoint in the `auth_url` field. If the output still shows the previous endpoint after a few minutes, check that the CCO pod is running and that the CCO mode is Passthrough: -+ ----- -$ oc get pods -n openshift-cloud-credential-operator -$ oc get cloudcredential cluster -o jsonpath='{.spec.credentialsMode}' ----- -+ -If the CCO is healthy but not propagating, patch each namespace secret directly by using the following command: -+ ----- -$ oc patch secret openstack-credentials -n kube-system \ - -p "{\"data\":{\"clouds.yaml\":\"${B64}\"}}" ----- - -. Switch the image-registry storage from Swift to emptyDir: -+ ----- -$ oc patch configs.imageregistry.operator.openshift.io cluster \ - --type json -p '[{"op":"replace","path":"/spec/storage","value":{"emptyDir":{}}}]' ----- -+ -[WARNING] -emptyDir is non-persistent. Registry images are lost when the pod restarts. For production, configure PVC-backed storage instead. -+ -emptyDir does not require working {OpenStackShort} credentials. The image-registry operator only calls the {OpenStackShort} API when Swift is the configured back end. This step works regardless of whether the new {rhos_acro} keystone is reachable from the {OpenShiftShort} on {OpenStackShort} cluster node. - -.Verification - -* Verify that the credentials are pointing to the new {rhos_acro} endpoint: -+ ----- -$ oc get co image-registry cloud-controller-manager storage machine-api ----- -+ -Wait about 5 minutes. -+ -The following example shows the output if the new {rhos_acro} keystone was not reachable from the {OpenShiftShort} on {OpenStackShort} cluster nodes in step 2: -+ ----- -NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE -image-registry 4.22.0-rc.0 True False True 14m ImagePrunerDegraded: Job has reached the specified backoff limit -cloud-controller-manager 4.22.0-rc.0 True False False 3d10h -storage 4.22.0-rc.0 True False False 3d10h -machine-api 4.22.0-rc.0 True False False 3d9h ----- -+ -[NOTE] -==== -* If you completed steps 2-4 with a reachable {rhos_acro} endpoint, the timeout errors should be resolved. -* The output displays an environment that is running {rhocp_long} 4.22. If you are using an earlier version of {rhocp_long}, you might see different operator states. -==== diff --git a/docs_user/modules/proc_updating-the-object-storage-endpoints.adoc b/docs_user/modules/proc_updating-the-object-storage-endpoints.adoc deleted file mode 100644 index 8ccb95ce4..000000000 --- a/docs_user/modules/proc_updating-the-object-storage-endpoints.adoc +++ /dev/null @@ -1,111 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="updating-the-object-storage-endpoints_{context}"] - -= Create or update the {object_storage} endpoints - -[role="_abstract"] -You must create or update the {object_storage_first_ref} endpoints to configure the new virtual IP address (VIP) that you reserved on the same network that you used to deploy RGW ingress. - -.Procedure - -. List the current swift endpoints and service: -+ ----- -$ oc rsh openstackclient openstack endpoint list | grep "swift.*object" ----- -+ ----- -$ oc rsh openstackclient openstack service list | grep "swift.*object" ----- - -. If the service and endpoints do not exist, create the missing swift resources: -+ ----- -$ oc rsh openstackclient openstack service create --name swift --description 'OpenStack Object Storage' object-store -$ oc rsh openstackclient openstack role add --user swift --project service member -$ oc rsh openstackclient openstack role add --user swift --project service admin -> for i in public internal; do -> oc rsh openstackclient endpoint create --region regionOne object-store $i http://:8080/swift/v1/AUTH_%\(tenant_id\)s -> done -$ oc rsh openstackclient openstack role add --project admin --user admin swiftoperator ----- -+ -* Replace `` with the Ceph RGW ingress VIP. - -. If the endpoints exist, update the endpoints to point to the right RGW ingress VIP: -+ ----- -$ oc rsh openstackclient openstack endpoint set --url http://:8080/swift/v1/AUTH_%\(tenant_id\)s -$ oc rsh openstackclient openstack endpoint set --url http://:8080/swift/v1/AUTH_%\(tenant_id\)s -$ oc rsh openstackclient openstack endpoint list | grep object -| 0d682ad71b564cf386f974f90f80de0d | regionOne | swift | object-store | True | public | http://172.18.0.100:8080/swift/v1/AUTH_%(tenant_id)s | -| b311349c305346f39d005feefe464fb1 | regionOne | swift | object-store | True | internal | http://172.18.0.100:8080/swift/v1/AUTH_%(tenant_id)s | - ----- -+ -* Replace `` with the UUID of the swift public endpoint. -* Replace `` with the UUID of the swift internal endpoint. - -. Test the migrated service: -+ ----- - -$ oc rsh openstackclient openstack container list --debug - -... -... -... -REQ: curl -g -i -X GET http://keystone-public-openstack.apps.ocp.openstack.lab -H "Accept: application/json" -H "User-Agent: openstacksdk/1.0.2 keystoneauth1/5.1.3 python-requests/2.25.1 CPython/3.9.23" -Starting new HTTP connection (1): keystone-public-openstack.apps.ocp.openstack.lab:80 -http://keystone-public-openstack.apps.ocp.openstack.lab:80 "GET / HTTP/1.1" 300 298 -RESP: [300] content-length: 298 content-type: application/json date: Mon, 14 Jul 2025 17:41:29 GMT location: http://keystone-public-openstack.apps.ocp.openstack.lab/v3/ server: Apache set-cookie: b5697f82cf3c19ece8be533395142512=d5c6a9ee2 -267c4b63e9f656ad7565270; path=/; HttpOnly vary: X-Auth-Token x-openstack-request-id: req-452e42c5-e60f-440f-a6e8-fe1b9ea89055 -RESP BODY: {"versions": {"values": [{"id": "v3.14", "status": "stable", "updated": "2020-04-07T00:00:00Z", "links": [{"rel": "self", "href": "http://keystone-public-openstack.apps.ocp.openstack.lab/v3/"}], "media-types": [{"base": "applic -ation/json", "type": "application/vnd.openstack.identity-v3+json"}]}]}} -GET call to http://keystone-public-openstack.apps.ocp.openstack.lab/ used request id req-452e42c5-e60f-440f-a6e8-fe1b9ea89055 - -... - -REQ: curl -g -i -X GET "http://172.18.0.100:8080/swift/v1/AUTH_44477474b0dc4b5b8911ceec23a22246?format=json" -H "User-Agent: openstacksdk/1.0.2 keystoneauth1/5.1.3 python-requests/2.25.1 CPython/3.9.23" -H "X-Auth-Token: {SHA256}ec5deca0be37bd8bfe659f132b9cdf396b8f409db5dc16972d50cbf3f28474d4" -Starting new HTTP connection (1): 172.18.0.100:8080 -http://172.18.0.100:8080 "GET /swift/v1/AUTH_44477474b0dc4b5b8911ceec23a22246?format=json HTTP/1.1" 200 2 -RESP: [200] accept-ranges: bytes content-length: 2 content-type: application/json; charset=utf-8 date: Mon, 14 Jul 2025 17:41:31 GMT x-account-bytes-used: 0 x-account-bytes-used-actual: 0 x-account-container-count: 0 x-account-object-count: 0 x-account-storage-policy-default-placement-bytes-used: 0 x-account-storage-policy-default-placement-bytes-used-actual: 0 x-account-storage-policy-default-placement-container-count: 0 x-account-storage-policy-default-placement-object-count: 0 x-openstack-request-id: tx000001e95361131ccf694-006875414a-7753-default x-timestamp: 1752514891.25991 x-trans-id: tx000001e95361131ccf694-006875414a-7753-default -RESP BODY: [] -GET call to http://172.18.0.100:8080/swift/v1/AUTH_44477474b0dc4b5b8911ceec23a22246?format=json used request id tx000001e95361131ccf694-006875414a-7753-default - -clean_up ListContainer: -END return value: 0 - ----- -ifeval::["{build}" != "downstream"] -. Run tempest tests against {object_storage}: -+ ----- -$ tempest run --regex tempest.api.object_storage -... -... -... -====== -Totals -====== -Ran: 141 tests in 606.5579 sec. - - Passed: 128 - - Skipped: 13 - - Expected Fail: 0 - - Unexpected Success: 0 - - Failed: 0 -Sum of execute time for each test: 657.5183 sec. - -============== -Worker Balance -============== - - Worker 0 (1 tests) => 0:10:03.400561 - - Worker 1 (2 tests) => 0:00:24.531916 - - Worker 2 (4 tests) => 0:00:10.249889 - - Worker 3 (30 tests) => 0:00:32.730095 - - Worker 4 (51 tests) => 0:00:26.246044 - - Worker 5 (6 tests) => 0:00:20.114803 - - Worker 6 (20 tests) => 0:00:16.290323 - - Worker 7 (27 tests) => 0:00:17.103827 ----- -endif::[] diff --git a/docs_user/modules/proc_using-new-subnet-ranges.adoc b/docs_user/modules/proc_using-new-subnet-ranges.adoc deleted file mode 100644 index 914c584d5..000000000 --- a/docs_user/modules/proc_using-new-subnet-ranges.adoc +++ /dev/null @@ -1,146 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="using-new-subnet-ranges_{context}"] - -= Configuring new subnet ranges - -[role="_abstract"] -[NOTE] -If you are using IPv6, you can reuse existing subnet ranges in most cases. For more information about existing subnet ranges, see xref:reusing-existing-subnet-ranges_{context}[Reusing existing subnet ranges]. - -You can define new IP ranges for control plane services that belong to a different subnet that is not used in the existing cluster. Then you configure link local IP routing between the existing and new subnets to enable existing and new service deployments to communicate. This involves using the {OpenStackPreviousInstaller} mechanism on a pre-adopted cluster to configure additional link local routes. This enables the data plane deployment to reach out to {rhos_prev_long} ({OpenStackShort}) nodes by using the existing subnet addresses. You can use new subnet ranges with any existing subnet configuration, and when the existing cluster subnet ranges do not have enough free IP addresses for the new control plane services. - -You must size the new subnet appropriately to accommodate the new control -plane services. There are no specific requirements for the -existing deployment allocation pools that are already consumed by the {OpenStackShort} environment. - -[IMPORTANT] -Defining a new subnet for Storage and Storage management is not supported because {compute_service_first_ref} and {Ceph} do not allow modifying those networks during adoption. - -In the following procedure, you configure `NetworkAttachmentDefinition` custom resources (CRs) to use a different subnet from what is configured in the `network_config` section of the `OpenStackDataPlaneNodeSet` CR for the same networks. The new range in the `NetworkAttachmentDefinition` CR is used for control plane services, while the existing range in the `OpenStackDataPlaneNodeSet` CR is used to manage IP Address Management (IPAM) for data plane nodes. - -The values that are used in the following procedure are examples. Use values that are specific to your configuration. - -ifeval::["{build_variant}" == "ospdo"] -For more information about director Operator network configurations, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html-single/deploying_an_overcloud_in_a_red_hat_openshift_container_platform_cluster_with_director_operator/index#assembly_creating-networks-with-director-operator[Creating networks with director Operator] in _Deploying an overcloud in a Red Hat OpenShift Container Platform cluster with director Operator_. -endif::[] - -.Procedure - - -. Configure link local routes on the existing deployment nodes for the control plane subnets. This is done through {OpenStackPreviousInstaller} configuration: -+ -[subs=+quotes] ----- -network_config: - - type: ovs_bridge - name: br-ctlplane - routes: - - ip_netmask: 0.0.0.0/0 - next_hop: 192.168.1.1 - - *ip_netmask: 172.31.0.0/24* - *next_hop: 192.168.1.100* ----- -+ -* `ip_netmask` defines the new control plane subnet. -* `next_hop` defines the control plane IP address of the existing data plane node. -+ -Repeat this configuration for other networks that need to use different subnets for the new and existing parts of the deployment. - -. Apply the new configuration to every {OpenStackShort} node: -+ ----- -(undercloud)$ openstack overcloud network provision \ - --output \ -[--templates ]/home/stack/templates/ ----- -+ ----- -(undercloud)$ openstack overcloud node provision \ - --stack \ - --network-config \ - --output \ -[--templates ]/home/stack/templates/ ----- -+ -* Optional: Include the `--templates` option to use your own templates instead of the default templates located in `/usr/share/openstack-tripleo-heat-templates`. Replace `` with the path to the directory that contains your templates. -* Replace `` with the name of the stack for which the bare-metal nodes are provisioned. If not specified, the default is `overcloud`. -* Include the `--network-config` optional argument to provide the network definitions to the `cli-overcloud-node-network-config.yaml` Ansible playbook. The `cli-overcloud-node-network-config.yaml` playbook uses the `os-net-config` tool to apply the network configuration on the deployed nodes. If you do not use `--network-config` to provide the network definitions, then you must configure the `{{role.name}}NetworkConfigTemplate` parameters in your `network-environment.yaml` file, otherwise the default network definitions are used. -* Replace `` with the name of the heat environment file to generate for inclusion in the deployment command, for example `/home/stack/templates/overcloud-baremetal-deployed.yaml`. -* Replace `` with the name of your node definition file, for example, `overcloud-baremetal-deploy.yaml`. Ensure that the `network_config_update` variable is set to `true` in the node definition file. -+ -[NOTE] -Network configuration changes are not applied by default to avoid -the risk of network disruption. You must enforce the changes by setting the -`StandaloneNetworkConfigUpdate: true` in the {OpenStackPreviousInstaller} configuration files. - -. Confirm that there are new link local routes to the new subnet on each node. For example: -+ -[source,yaml] ----- -# ip route | grep 172 -172.31.0.0/24 via 192.168.122.100 dev br-ctlplane ----- - -. You also must configure link local routes to existing deployment on {rhos_long} worker nodes. This is achieved by adding `routes` entries to the `NodeNetworkConfigurationPolicy` CRs for each network. For example: -+ ----- - - destination: 192.168.122.0/24 - next-hop-interface: ospbr ----- -+ -* `destination` defines the original subnet of the isolated network on the data plane. -* `next-hop-interface` defines the {rhocp_long} worker network interface that corresponds to the isolated network on the data plane. -+ -As a result, the following route is added to your {OpenShiftShort} nodes: -+ -[source,yaml] ----- -# ip route | grep 192 -192.168.122.0/24 dev ospbr proto static scope link ----- -+ -. Later, during the data plane adoption, in the `network_config` section of the `OpenStackDataPlaneNodeSet` CR, add the same link local routes for the new control plane subnet ranges. For example: -+ ----- - nodeTemplate: - ansible: - ansibleUser: tripleo-admin - ansibleVars: - additional_ctlplane_host_routes: - - ip_netmask: 172.31.0.0/24 - next_hop: '{{ ctlplane_ip }}' - edpm_network_config_template: | - network_config: - - type: ovs_bridge - routes: {{ ctlplane_host_routes + additional_ctlplane_host_routes }} - ... ----- - -. List the IP addresses that are used for the data plane nodes in the existing deployment as `ansibleHost` and `fixedIP`. For example: -+ ----- - nodes: - standalone: - ansible: - ansibleHost: 192.168.122.100 - ansibleUser: "" - hostName: standalone - networks: - - defaultRoute: true - fixedIP: 192.168.122.100 - name: ctlplane - subnetName: subnet1 ----- -+ -[IMPORTANT] -Do not change {OpenStackShort} node IP addresses during the adoption process. List previously used IP addresses in the `fixedIP` fields for each node entry in the `nodes` section of the `OpenStackDataPlaneNodeSet` CR. - -. Expand the SSH range for the firewall configuration to include both subnets to allow SSH access to data plane nodes from both subnets: -+ ----- - edpm_sshd_allowed_ranges: - - 192.168.122.0/24 - - 172.31.0.0/24 ----- -+ -This provides SSH access from the new subnet to the {OpenStackShort} nodes as well as the {OpenStackShort} subnets. diff --git a/docs_user/modules/proc_verifying-the-image-service-adoption.adoc b/docs_user/modules/proc_verifying-the-image-service-adoption.adoc deleted file mode 100644 index 1e18b75d8..000000000 --- a/docs_user/modules/proc_verifying-the-image-service-adoption.adoc +++ /dev/null @@ -1,133 +0,0 @@ -:_mod-docs-content-type: PROCEDURE -[id="verifying-the-image-service-adoption_{context}"] - -= Verifying the {image_service} adoption - -[role="_abstract"] -Verify that you adopted the {image_service_first_ref} to the {rhos_long} {rhos_curr_ver} deployment. - -.Procedure - -. Test the {image_service} from the {rhos_prev_long} CLI. You can compare and ensure that the configuration is applied to the {image_service} pods: -+ ----- -$ os-diff diff /etc/glance/glance.conf.d/02-config.conf glance_patch.yaml --frompod -p glance-api ----- -+ -If no line appears, then the configuration is correct. - -. Inspect the resulting {image_service} pods: -+ ----- -GLANCE_POD=`oc get pod |grep glance-default | cut -f 1 -d' ' | head -n 1` -oc exec -t $GLANCE_POD -c glance-api -- cat /etc/glance/glance.conf.d/02-config.conf - -[DEFAULT] -enabled_backends=default_backend:rbd -[glance_store] -default_backend=default_backend -[default_backend] -rbd_store_ceph_conf=/etc/ceph/ceph.conf -rbd_store_user=openstack -rbd_store_pool=images -store_description=Ceph glance store backend. ----- - -. If you use a {Ceph} back end, ensure that the {Ceph} secrets are mounted: -+ ----- -$ oc exec -t $GLANCE_POD -c glance-api -- ls /etc/ceph -ceph.client.openstack.keyring -ceph.conf ----- - -. Check that the service is active, and that the endpoints are updated in the {OpenStackShort} CLI: -+ ----- -$ oc rsh openstackclient -$ openstack service list | grep image - -| fc52dbffef36434d906eeb99adfc6186 | glance | image | - -$ openstack endpoint list | grep image - -| 569ed81064f84d4a91e0d2d807e4c1f1 | regionOne | glance | image | True | internal | http://glance-internal-openstack.apps-crc.testing | -| 5843fae70cba4e73b29d4aff3e8b616c | regionOne | glance | image | True | public | http://glance-public-openstack.apps-crc.testing | ----- - -. Check that the images that you previously listed in the source cloud are available in the adopted service: -+ ----- -$ openstack image list -+--------------------------------------+--------+--------+ -| ID | Name | Status | -+--------------------------------------+--------+--------+ -| c3158cad-d50b-452f-bec1-f250562f5c1f | cirros | active | -+--------------------------------------+--------+--------+ ----- -ifeval::["{build}" != "downstream"] -. Test that you can create an image on the adopted service: -+ ----- -(openstack)$ alias openstack="oc exec -t openstackclient -- openstack" -(openstack)$ curl -L -o /tmp/cirros-0.6.3-x86_64-disk.img http://download.cirros-cloud.net/0.6.3/cirros-0.6.3-x86_64-disk.img - qemu-img convert -O raw /tmp/cirros-0.6.3-x86_64-disk.img /tmp/cirros-0.6.3-x86_64-disk.img.raw - openstack image create --container-format bare --disk-format raw --file /tmp/cirros-0.6.3-x86_64-disk.img.raw cirros2 - openstack image list - % Total % Received % Xferd Average Speed Time Time Time Current - Dload Upload Total Spent Left Speed -100 273 100 273 0 0 1525 0 --:--:-- --:--:-- --:--:-- 1533 - 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 -100 15.5M 100 15.5M 0 0 17.4M 0 --:--:-- --:--:-- --:--:-- 17.4M - -+------------------+--------------------------------------------------------------------------------------------------------------------------------------------+ -| Field | Value | -+------------------+--------------------------------------------------------------------------------------------------------------------------------------------+ -| container_format | bare | -| created_at | 2023-01-31T21:12:56Z | -| disk_format | raw | -| file | /v2/images/46a3eac1-7224-40bc-9083-f2f0cd122ba4/file | -| id | 46a3eac1-7224-40bc-9083-f2f0cd122ba4 | -| min_disk | 0 | -| min_ram | 0 | -| name | cirros | -| owner | 9f7e8fdc50f34b658cfaee9c48e5e12d | -| properties | os_hidden='False', owner_specified.openstack.md5='', owner_specified.openstack.object='images/cirros', owner_specified.openstack.sha256='' | -| protected | False | -| schema | /v2/schemas/image | -| status | queued | -| tags | | -| updated_at | 2023-01-31T21:12:56Z | -| visibility | shared | -+------------------+--------------------------------------------------------------------------------------------------------------------------------------------+ - -+--------------------------------------+--------+--------+ -| ID | Name | Status | -+--------------------------------------+--------+--------+ -| 46a3eac1-7224-40bc-9083-f2f0cd122ba4 | cirros2| active | -| c3158cad-d50b-452f-bec1-f250562f5c1f | cirros | active | -+--------------------------------------+--------+--------+ - - -(openstack)$ oc rsh ceph -sh-4.4$ ceph -s -r cluster: - id: 432d9a34-9cee-4109-b705-0c59e8973983 - health: HEALTH_OK - - services: - mon: 1 daemons, quorum a (age 4h) - mgr: a(active, since 4h) - osd: 1 osds: 1 up (since 4h), 1 in (since 4h) - - data: - pools: 5 pools, 160 pgs - objects: 46 objects, 224 MiB - usage: 247 MiB used, 6.8 GiB / 7.0 GiB avail - pgs: 160 active+clean - -sh-4.4$ rbd -p images ls -46a3eac1-7224-40bc-9083-f2f0cd122ba4 -c3158cad-d50b-452f-bec1-f250562f5c1f ----- -endif::[] diff --git a/docs_user/modules/ref_adoption-duration-and-impact.adoc b/docs_user/modules/ref_adoption-duration-and-impact.adoc deleted file mode 100644 index 25b2ea330..000000000 --- a/docs_user/modules/ref_adoption-duration-and-impact.adoc +++ /dev/null @@ -1,44 +0,0 @@ -:_mod-docs-content-type: REFERENCE -[id="adoption-duration-and-impact_{context}"] - -= Adoption duration and impact - -[role="_abstract"] -The durations in the following table were recorded in a test environment that consisted of 228 Compute nodes and 3 Networker nodes. To accurately estimate the duration for each task, perform these procedures in a test environment with similar hardware to your production environment. - -Set up the {rhocp_long} environment and install the Operators before testing. - -[IMPORTANT] -Durations can vary significantly based on the content of your environment, for example, the size of your service databases or the number of services. The durations represent raw execution time. They do not include human operator activity. - -.Duration and impact of adoption stages -[options="header",cols="h,a,a"] -|=== -| Adoption stage | Duration | Notes - -| xref:migrating-tls-everywhere_configuring-network[TLS-e migration] | * 3 seconds | * No impact on running workloads. -| xref:migrating-databases-to-the-control-plane_configuring-network[Database migration and back-end services deployment] | * 12 minutes -| * No data loss or workload disruption. -* APIs are offline. -| xref:adopting-openstack-control-plane-services_configuring-network[Control plane adoption] | * 21 minutes | * No data loss or workload disruption. -* APIs are being started. -* No Compute hosts are available to schedule workloads until the data plane adoption stage. -* No network changes should be done until the data plane adoption is complete. -| xref:adopting-data-plane_hsm-integration[Data plane adoption] | * 60 minutes | * APIs are online. -* As Compute hosts are adopted, they become available for workload scheduling. -* No data loss or workload disruption. -| xref:performing-a-fast-forward-upgrade-on-compute-services_data-plane[Fast-forward upgrade of Compute services] | * 8 minutes | * No data loss or workload disruption. -| xref:adopting-networker-services-to-the-data-plane_data-plane[Networker node adoption] | * 9 minutes | * See the following "Data plane connectivity impact" table for more details about Networker scenarios. -|=== - - -.Data plane connectivity impact -[options="header",cols="h,a"] -|=== -| Scenario | Notes - -| Migrate a 17.1 OVN gateway on the control plane to a {OpenShiftShort}-hosted OVN gateway | Possible L3 downtime due to the migration of the traffic path to new hosts -| Migrate a 17.1 OVN gateway on the control plane to an 18.0 data plane Networker node | No L2/L3 data plane connectivity loss because the traffic path remains unchanged -| Migrate a 17.1 OVN gateway on a Networker node to a 18.0 data plane Networker node | No L2/L3 data plane connectivity loss because the traffic path remains unchanged -| L3 handled through provider networks | No L2/L3 data plane connectivity loss because the traffic path remains unchanged -|=== diff --git a/docs_user/modules/ref_adoption-prerequisites.adoc b/docs_user/modules/ref_adoption-prerequisites.adoc deleted file mode 100644 index eb852bcbb..000000000 --- a/docs_user/modules/ref_adoption-prerequisites.adoc +++ /dev/null @@ -1,66 +0,0 @@ -:_mod-docs-content-type: REFERENCE -[id="adoption-prerequisites_{context}"] - -= Adoption prerequisites - -[role="_abstract"] -Before you begin the adoption procedure, complete the following prerequisites: - -Planning information:: -+ -* Review the xref:adoption-limitations_{context}[Adoption limitations]. -* Review the {rhocp_long} requirements, data plane node requirements, Compute node requirements, and so on. For more information, see link:{planning}/index[{planning-t}]. -* Review the adoption-specific networking requirements. For more information, see xref:configuring-network-for-RHOSO-deployment_planning[Configuring the network for the RHOSO deployment]. -* Review the adoption-specific storage requirements. For more information, see xref:storage-requirements_configuring-network[Storage requirements]. -* Review how to customize your deployed control plane with the services that are required for your environment. For more information, see link:{customizing-rhoso}/index[{customizing-rhoso-t}]. -ifeval::["{build_variant}" == "ospdo"] -* Familiarize yourself with a disconnected environment deployment. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html-single/deploying_an_overcloud_in_a_red_hat_openshift_container_platform_cluster_with_director_operator/index#proc_configuring-an-airgapped-environment_air-gapped-environment[Configuring an airgapped environment] in _Deploying an overcloud in a Red Hat OpenShift Container Platform cluster with director Operator_. -endif::[] -* Familiarize yourself with the following {OpenShiftShort} concepts that are used during adoption: -** link:{defaultOCPURL}/nodes/overview-of-nodes[Overview of nodes] -** link:{defaultOCPURL}/nodes/index#nodes-scheduler-node-selectors-about_nodes-scheduler-node-selectors[About node selectors] -** link:{defaultOCPURL}/machine_configuration/index[Machine configuration overview] -* Familiarize yourself with mapping RHOSO versions to OpenStack Operators and OpenStackVersion custom resources (CRs). For more information, see the Red Hat Knowledgebase article link:https://access.redhat.com/articles/7125383[How RHOSO versions map to OpenStack Operators and OpenStackVersion CRs]. - -Back-up information:: -+ -* Back up your {rhos_prev_long} ({OpenStackShort}) {rhos_prev_ver} environment by using one of the following options: -** The Relax-and-Recover tool. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html/backing_up_and_restoring_the_undercloud_and_control_plane_nodes/assembly_backing-up-the-undercloud-and-the-control-plane-nodes-using-the-relax-and-recover-tool_br-undercloud-ctlplane[Backing up the undercloud and the control plane nodes by using the Relax-and-Recover tool] in _Backing up and restoring the undercloud and control plane nodes_. -** The Snapshot and Revert tool. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html/backing_up_and_restoring_the_undercloud_and_control_plane_nodes/assembly_snapshot-and-revert-appendix_snapshot-and-revert-appendix[Backing up your Red Hat OpenStack Platform cluster by using the Snapshot and Revert tool] in _Backing up and restoring the undercloud and control plane nodes_. -** A third-party backup and recovery tool. For more information about certified backup and recovery tools, see the link:https://catalog.redhat.com/[Red Hat Ecosystem Catalog]. -* Back up the configuration files from the {OpenStackShort} services and {OpenStackPreviousInstaller} on your file system. For more information, see xref:pulling-configuration-from-tripleo-deployment_adopt-control-plane[Pulling the configuration from a {OpenStackPreviousInstaller} deployment]. - -Compute:: -+ -* Upgrade your Compute nodes to Red Hat Enterprise Linux {rhel_prev_ver}. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html-single/framework_for_upgrades_16.2_to_17.1/index#upgrading-compute-nodes_upgrading-the-compute-node-operating-system[Upgrading all Compute nodes to RHEL 9.2] in _Framework for upgrades (16.2 to 17.1)_. -* On your Compute hosts, the `systemd-container` package must be installed and the `systemd-machined` service must be running. For more information about how to verify that the package is installed and that the service is running, see xref:installing-the-systemd-container-package-on-compute-hosts_{context}[Installing the `systemd-container` package on Compute hosts]. - -ML2/OVS:: -+ -* If you use the Modular Layer 2 plug-in with Open vSwitch mechanism driver (ML2/OVS), migrate it to the Modular Layer 2 plug-in with Open Virtual Networking (ML2/OVN) mechanism driver. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html/migrating_to_the_ovn_mechanism_driver/index[Migrating to the OVN mechanism driver]. - -Tools:: -+ -* The oc and podman command line tools are installed on your workstation. -* Make sure to set the correct {rhos_acro} project namespace in which to run commands. -ifeval::["{build_variant}" == "ospdo"] -* In director Operator adoption, the source {rhos_prev_long} {rhos_prev_ver} namespace is `openstack`. In order to successfully adopt the {OpenStackShort} {rhos_prev_ver} environment, the destination {rhos_acro} {rhos_curr_ver} namespace must be different, for example, `rhoso`. -endif::[] -+ -[source, shell] ----- -ifeval::["{build_variant}" == "ospdo"] -$ oc project rhoso -endif::[] -ifeval::["{build_variant}" != "ospdo"] -$ oc project openstack -endif::[] ----- - -{OpenStackShort} {rhos_prev_ver} release:: -+ -* The {OpenStackShort} {rhos_prev_ver} cloud is updated to the 17.1.4 release or later. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html/performing_a_minor_update_of_red_hat_openstack_platform/index[Performing a minor update of Red Hat OpenStack Platform]. - -{OpenStackShort} {rhos_prev_ver} hosts:: -+ -* All control plane and data plane hosts of the {OpenStackShort} {rhos_prev_ver} cloud are up and running, and continue to run throughout the adoption procedure. diff --git a/docs_user/modules/ref_adoption-process-overview.adoc b/docs_user/modules/ref_adoption-process-overview.adoc deleted file mode 100644 index b7f5b6572..000000000 --- a/docs_user/modules/ref_adoption-process-overview.adoc +++ /dev/null @@ -1,41 +0,0 @@ -:_mod-docs-content-type: REFERENCE -[id="adoption-process-overview_{context}"] - -= Adoption process overview - -[role="_abstract"] -Familiarize yourself with the steps of the adoption process. - -Main adoption process:: -+ -. xref:migrating-tls-everywhere_configuring-network[Migrate TLS everywhere (TLS-e) to the Red Hat OpenStack Services on OpenShift (RHOSO) deployment]. -. xref:migrating-databases-to-the-control-plane_configuring-network[Migrate your existing databases to the new control plane]. -. xref:adopting-openstack-control-plane-services_configuring-network[Adopt your Red Hat OpenStack Platform 17.1 control plane services to the new RHOSO 18.0 deployment]. -ifeval::["{build_variant}" == "ospdo"] -. xref:ospdo-scale-down-pre-database-adoption_configuring-network[Scaling down director Operator resources]. -endif::[] -. xref:adopting-data-plane_adopt-control-plane[Adopt the RHOSO 18.0 data plane]. -. xref:migrating-the-object-storage-service_adopt-control-plane[Migrate the Object Storage service (swift) to the RHOSO nodes]. -. xref:ceph-migration_adopt-control-plane[Migrate the {Ceph} cluster]. -.. xref:migrating-ceph-monitoring_migrating-ceph[Migrate the monitoring stack component to new nodes within an existing {Ceph} cluster]. -.. xref:migrating-ceph-mds_migrating-ceph-monitoring[Migrate {Ceph} MDS to new nodes within the existing cluster]. -.. xref:migrating-ceph-rgw_migrating-ceph-monitoring[Migrate {Ceph} RGW to external RHEL nodes]. -.. xref:migrating-ceph-rbd_migrating-ceph-monitoring[Migrate {Ceph} RBD to external RHEL nodes]. - -Distributed Compute Node (DCN) architecture process:: -+ -. xref:dcn-adoption-overview_planning[Overview of Distributed Compute Node adoption] -. xref:adopting-spine-leaf-networks_configuring-network[Configuring spine-leaf networks for the {rhos_long_noacro} deployment] -. xref:configuring-control-plane-networking-for-spine-leaf_hsm-integration[Configuring control plane networking for spine-leaf topologies] -. xref:configuring-dcn-data-plane-nodesets_data-plane[Configuring data plane node sets for DCN sites] -+ -If you use a DCN architecture with storage, the following additional steps apply, depending on the services that are included in your deployment: -+ -.. xref:adopting-image-service-with-dcn-backend_image-service[Adopting the {image_service} with multiple {Ceph} back ends (DCN)] -.. xref:adopting-block-storage-service-with-dcn-backend_hsm-integration[Adopt the {block_storage} service with multiple {Ceph} back ends (DCN)] -.. xref:adopting-compute-services-with-dcn-backend_data-plane[Adopting Compute services with multiple Red Hat Ceph Storage back ends (DCN)] -.. xref:ceph-migration-dcn_migrating-ceph[{Ceph} migration for Distributed Compute Node deployments] - -Post-adoption tasks:: -+ -* For more details on the tasks you must perform after completing the adoption, see xref:post-adoption-tasks_migrating-ceph-rbd[Post-adoption tasks]. diff --git a/docs_user/modules/ref_block-storage-service-requirements.adoc b/docs_user/modules/ref_block-storage-service-requirements.adoc deleted file mode 100644 index 8d82a42c0..000000000 --- a/docs_user/modules/ref_block-storage-service-requirements.adoc +++ /dev/null @@ -1,53 +0,0 @@ -:_mod-docs-content-type: REFERENCE -[id="block-storage-requirements_{context}"] - -= {block_storage} guidelines - -[role="_abstract"] -Prepare to adopt your {block_storage_first_ref}: - -* Take note of the {block_storage} back ends that you use. -* Determine all the transport protocols that the {block_storage} back ends use, such as -RBD, iSCSI, FC, NFS, NVMe-TCP, and so on. You must consider them when you place the Block Storage services and when the right storage transport-related binaries are running on the {rhocp_long} nodes. For more information about each storage transport protocol, see xref:openshift-preparation-for-block-storage-adoption_storage-requirements[{OpenShiftShort} preparation for {block_storage} adoption]. -* Use a {block_storage} volume service to deploy each {block_storage} volume back end. -+ -For example, you have an LVM back end, a Ceph back end, and two entries in `cinderVolumes`, and you cannot set global defaults for all volume services. You must define a service for each of them: -+ -[source,yaml] ----- -apiVersion: core.openstack.org/v1beta1 -kind: OpenStackControlPlane -metadata: - name: openstack -spec: - cinder: - enabled: true - template: - cinderVolumes: - lvm: - customServiceConfig: | - [DEFAULT] - debug = True - [lvm] -< . . . > - ceph: - customServiceConfig: | - [DEFAULT] - debug = True - [ceph] -< . . . > ----- -+ -[WARNING] -Check that all configuration options are still valid for {rhos_acro} {rhos_curr_ver} version. Configuration options might be deprecated, removed, or added. This applies to both back-end driver-specific configuration options and other generic options. - -ifeval::["{build}" != "downstream"] -There are two ways to prepare a {block_storage} configuration for adoption. You can customize the configuration or prepare a quick configuration. There is no difference in how {block_storage} operates with both methods, but you should customize the configuration whenever possible. -endif::[] - - -ifeval::["{build}" != "downstream"] -include::../modules/proc_preparing-block-storage-service-by-using-agnostic-config-file.adoc[leveloffset=+1] - -include::../modules/con_block-storage-service-config-generation-helper-tool.adoc[leveloffset=+1] -endif::[] diff --git a/docs_user/modules/ref_ceph-daemon-cardinality.adoc b/docs_user/modules/ref_ceph-daemon-cardinality.adoc deleted file mode 100644 index 0a9aae3b6..000000000 --- a/docs_user/modules/ref_ceph-daemon-cardinality.adoc +++ /dev/null @@ -1,48 +0,0 @@ -:_mod-docs-content-type: REFERENCE -[id="ceph-daemon-cardinality_{context}"] - -= {Ceph} daemon cardinality - -[role="_abstract"] -{Ceph} {CephVernum} and later applies strict constraints in the way daemons can be colocated within the same node. Your topology depends on the available hardware and the amount of Red Hat Ceph Storage services in the Controller nodes that you retire. - -The amount of services that you can migrate depends on the amount of available nodes in the cluster. - -The following diagrams show the distribution of Red Hat Ceph Storage daemons on Red Hat Ceph Storage nodes where at least 3 nodes are required. - -ifeval::["{build}" != "upstream"] -For more information, see the Red Hat Knowledgebase article link:https://access.redhat.com/articles/1548993[Red Hat Ceph Storage: Supported configurations]. -endif::[] - -* The following scenario includes only RGW and RBD, without the {Ceph} dashboard: -+ ----- -| | | | -|----|---------------------|-------------| -| osd | mon/mgr/crash | rgw/ingress | -| osd | mon/mgr/crash | rgw/ingress | -| osd | mon/mgr/crash | rgw/ingress | ----- - -* With the {Ceph} dashboard, but without {rhos_component_storage_file_first_ref}, at least 4 nodes are required. The {Ceph} dashboard has no failover: -+ ----- -| | | | -|-----|---------------------|-------------| -| osd | mon/mgr/crash | rgw/ingress | -| osd | mon/mgr/crash | rgw/ingress | -| osd | mon/mgr/crash | dashboard/grafana | -| osd | rgw/ingress | (free) | ----- - -* With the {Ceph} dashboard and the {rhos_component_storage_file}, a minimum of 5 nodes are required, and the {Ceph} dashboard has no failover: -+ ----- -| | | | -|-----|---------------------|-------------------------| -| osd | mon/mgr/crash | rgw/ingress | -| osd | mon/mgr/crash | rgw/ingress | -| osd | mon/mgr/crash | mds/ganesha/ingress | -| osd | rgw/ingress | mds/ganesha/ingress | -| osd | mds/ganesha/ingress | dashboard/grafana | ----- diff --git a/docs_user/modules/ref_ceph-migration-dcn.adoc b/docs_user/modules/ref_ceph-migration-dcn.adoc deleted file mode 100644 index 2681e3cda..000000000 --- a/docs_user/modules/ref_ceph-migration-dcn.adoc +++ /dev/null @@ -1,44 +0,0 @@ -:_mod-docs-content-type: REFERENCE -[id="ceph-migration-dcn_{context}"] - -= {Ceph} migration for Distributed Compute Node deployments - -[role="_abstract"] -Before you adopt your Distributed Compute Node (DCN) deployments that host {CephCluster} clusters on Compute nodes at edge sites so that your architecture runs on {rhos_long} (RHOSO), be aware of important considerations. - -Supported edge storage topologies:: DCN deployments support the following storage topologies at edge sites: -+ -* Hyperconverged Infrastructure (HCI): {Ceph} daemons run on Compute nodes at each edge site. -* {OpenStackPreviousInstaller}-deployed dedicated storage: {Ceph} runs on separate storage nodes deployed by {OpenStackPreviousInstaller}. -* External {Ceph} cluster: Edge sites connect to pre-existing {CephCluster} clusters not managed by {OpenStackPreviousInstaller}. - -Central site {Ceph} migration:: For the central site, migrate {Ceph} daemons from the {OpenStackShort} Controller nodes by using the same process as a non-DCN deployment. For more information, see xref:ceph-daemon-cardinality_migrating-ceph[{Ceph} daemon cardinality]. - -Edge site {Ceph} migration:: For edge sites that use HCI or {OpenStackPreviousInstaller}-deployed dedicated storage, the {Ceph} daemons can continue to run on their current nodes without migration. The Compute nodes or dedicated storage nodes at edge sites are not decommissioned during adoption, so the {Ceph} daemons remain operational. -+ -For edge sites that use external {Ceph} clusters, no migration is required because the {CephCluster} cluster is not managed by {OpenStackPreviousInstaller}. - -{Ceph} back-end configuration and key distribution:: In a DCN deployment, each site has its own {CephCluster} cluster with its own configuration file and {Ceph} keyring. These must be stored in Kubernetes secrets and mounted into the appropriate {rhos_long} service pods. -+ -Rather than storing all {Ceph} keys in a single secret accessible to every pod, the recommended approach is to create one secret per site containing only the keys that site actually needs. This limits the security impact if a site is compromised: a pod at an edge site can authenticate only to its local {CephCluster} cluster and the central cluster, not to the {Ceph} keyrings of other edge sites. -+ -The key distribution rule for N sites is: -+ -* The central site (site 0) receives the {Ceph} keys and configuration for all clusters, because central services such as {image_service} use the `split` back end and must be able to copy images to and from any site. -* Each edge site (site 1 through N) receives only the keys for the central cluster and its own local cluster. -+ -For example, in a three-site deployment with a central site and two edge sites: -+ ----- -ceph-conf-central -> central.conf + central.keyring - dcn1.conf + dcn1.keyring - dcn2.conf + dcn2.keyring - -ceph-conf-dcn1 -> central.conf + central.keyring - dcn1.conf + dcn1.keyring - -ceph-conf-dcn2 -> central.conf + central.keyring - dcn2.conf + dcn2.keyring ----- -+ -The per-site secrets are created and then mounted into the appropriate pods using `extraMounts` propagation labels. The procedure in xref:configuring-a-ceph-backend_migrating-databases[Configuring a {Ceph} back end] covers both creating the secrets and applying the propagation labels so that each pod receives only its site-specific keys. diff --git a/docs_user/modules/ref_openshift-preparation-for-block-storage-adoption.adoc b/docs_user/modules/ref_openshift-preparation-for-block-storage-adoption.adoc deleted file mode 100644 index 42a5391f3..000000000 --- a/docs_user/modules/ref_openshift-preparation-for-block-storage-adoption.adoc +++ /dev/null @@ -1,187 +0,0 @@ -:_mod-docs-content-type: REFERENCE -[id="openshift-preparation-for-block-storage-adoption_{context}"] - -= {OpenShiftShort} preparation for {block_storage} adoption - -[role="_abstract"] -Before you deploy {rhos_prev_long} ({OpenStackShort}) in {rhocp_long} nodes, ensure that the networks are ready, that you decide which {OpenShiftShort} nodes to restrict, and that you make any necessary changes to the {OpenShiftShort} nodes. - -Node selection:: -You might need to restrict the {OpenShiftShort} nodes where the {block_storage} volume and backup services run. -+ -An example of when you need to restrict nodes for a specific {block_storage} is when you deploy the {block_storage} with the LVM driver. In that scenario, the LVM data where the volumes are stored only exists in a specific host, so you need to pin the Block Storage-volume service to that specific {OpenShiftShort} node. Running the service on any other {OpenShiftShort} node does not work. You cannot use the {OpenShiftShort} host node name to restrict the LVM back end. You need to identify the LVM back end by using a unique label, an existing label, or a new label: -+ ----- -$ oc label nodes worker0 lvm=cinder-volumes ----- -+ -[source,yaml] ----- -apiVersion: core.openstack.org/v1beta1 -kind: OpenStackControlPlane -metadata: - name: openstack -spec: - secret: osp-secret - storageClass: local-storage - cinder: - enabled: true - template: - cinderVolumes: - lvm-iscsi: - nodeSelector: - lvm: cinder-volumes -< . . . > ----- -+ -For more information about node selection, see link:{defaultOCPURL}/nodes/index#nodes-scheduler-node-selectors-about_nodes-scheduler-node-selectors[About node selectors]. -+ -[NOTE] -==== -If your nodes do not have enough local disk space for temporary images, you can use a remote NFS location by setting the extra volumes feature, `extraMounts`. -==== -Transport protocols:: -Some changes to the storage transport protocols might be required for {OpenShiftShort}: -+ -* If you use a `MachineConfig` to make changes to {OpenShiftShort} nodes, the nodes reboot. -* Check the back-end sections that are listed in the `enabled_backends` configuration option in your `cinder.conf` file to determine the enabled storage back-end sections. -* Depending on the back end, you can find the transport protocol by viewing the `volume_driver` or `target_protocol` configuration options. -* The `iscsid` service, `multipathd` service, and `NVMe-TCP` kernel modules start automatically on data plane nodes. - -NFS::: -** {OpenShiftShort} connects to NFS back ends without additional changes. - -Rados Block Device and {Ceph}::: -** {OpenShiftShort} connects to {Ceph} back ends without additional changes. You must provide credentials and configuration files to the services. - -iSCSI::: -** To connect to iSCSI volumes, the iSCSI initiator must run on the -{OpenShiftShort} hosts where the volume and backup services run. The Linux Open iSCSI initiator does not support network namespaces, so you must only run one instance of the service for the normal {OpenShiftShort} usage, as well as -the {OpenShiftShort} CSI plugins and the {OpenStackShort} services. -** If you are not already running `iscsid` on the {OpenShiftShort} nodes, then you must apply a `MachineConfig`. For example: -+ -[source,yaml] ----- -apiVersion: machineconfiguration.openshift.io/v1 -kind: MachineConfig -metadata: - labels: - machineconfiguration.openshift.io/role: worker - service: cinder - name: 99-master-cinder-enable-iscsid -spec: - config: - ignition: - version: 3.2.0 - systemd: - units: - - enabled: true - name: iscsid.service ----- -** If you use labels to restrict the nodes where the Block Storage services run, you must use a `MachineConfigPool` to limit the effects of the -`MachineConfig` to the nodes where your services might run. For more information, see link:{defaultOCPURL}/nodes/index#nodes-scheduler-node-selectors-about_nodes-scheduler-node-selectors[About node selectors]. -** If you are using a single node deployment to test the process, replace `worker` with `master` in the `MachineConfig`. -** For production deployments that use iSCSI volumes, configure multipathing for better I/O. - -FC::: -** The {block_storage} volume and {block_storage} backup services must run in an {OpenShiftShort} host that has host bus adapters (HBAs). If some nodes do not have HBAs, then use labels to restrict where these services run. For more information, see link:{defaultOCPURL}/nodes/index#nodes-scheduler-node-selectors-about_nodes-scheduler-node-selectors[About node selectors]. -** If the {image_service} is configured to use {block_storage} as a back end with FC, the {image_service} must also run on an {OpenShiftShort} host that has HBAs and follow the same node selection requirements as the {block_storage}. -** If you have virtualized {OpenShiftShort} clusters that use FC you need to expose the host HBAs inside the virtual machine. -** For production deployments that use FC volumes, configure multipathing for better I/O. - -NVMe-TCP::: -** To connect to NVMe-TCP volumes, load NVMe-TCP kernel modules on the {OpenShiftShort} hosts. -** If you do not already load the `nvme-fabrics` module on the {OpenShiftShort} nodes where the volume and backup services are going to run, then you must apply a `MachineConfig`. For example: -+ ----- -apiVersion: machineconfiguration.openshift.io/v1 -kind: MachineConfig -metadata: - labels: - machineconfiguration.openshift.io/role: worker - service: cinder - name: 99-master-cinder-load-nvme-fabrics -spec: - config: - ignition: - version: 3.2.0 - storage: - files: - - path: /etc/modules-load.d/nvme_fabrics.conf - overwrite: false - # Mode must be decimal, this is 0644 - mode: 420 - user: - name: root - group: - name: root - contents: - # Source can be a http, https, tftp, s3, gs, or data as defined in rfc2397. - # This is the rfc2397 text/plain string format - source: data:,nvme-fabrics ----- -** If you use labels to restrict the nodes where Block Storage -services run, use a `MachineConfigPool` to limit the effects of the `MachineConfig` to the nodes where your services run. For more information, see link:{defaultOCPURL}/nodes/index#nodes-scheduler-node-selectors-about_nodes-scheduler-node-selectors[About node selectors]. -** If you use a single node deployment to test the process, replace `worker` with `master` in the `MachineConfig`. -** Only load the `nvme-fabrics` module because it loads the transport-specific modules, such as TCP, RDMA, or FC, as needed. -+ -ifeval::["{build}" != "downstream"] -For production deployments that use NVMe-TCP volumes, use multipathing. For NVMe-TCP volumes {OpenShiftShort} uses native multipathing, called -https://nvmexpress.org/faq-items/what-is-ana-nvme-multipathing/[ANA]. -endif::[] -ifeval::["{build}" != "upstream"] -** For production deployments that use NVMe-TCP volumes, use multipathing for better I/O. For NVMe-TCP volumes, {OpenShiftShort} uses native multipathing, called ANA. -endif::[] -** After the {OpenShiftShort} nodes reboot and load the `nvme-fabrics` module, you can confirm that the operating system is configured and that it supports ANA by checking the host: -+ ----- -$ cat /sys/module/nvme_core/parameters/multipath ----- -+ -[IMPORTANT] -ANA does not use the Linux Multipathing Device Mapper, but {OpenShiftShort} requires `multipathd` to run on Compute nodes for the {compute_service_first_ref} to be able to use multipathing. Multipathing is automatically configured on data plane nodes when they are provisioned. - -Multipathing::: -** Use multipathing for iSCSI and FC protocols. To configure multipathing on these protocols, you perform the following tasks: -*** Prepare the {OpenShiftShort} hosts -*** Configure the Block Storage services -*** Prepare the {compute_service} nodes -*** Configure the {compute_service} -** To prepare the {OpenShiftShort} hosts, ensure that the Linux Multipath Device Mapper is configured and running on the {OpenShiftShort} hosts by using `MachineConfig`. For example: -+ -[source,yaml] ----- -# Includes the /etc/multipathd.conf contents and the systemd unit changes -apiVersion: machineconfiguration.openshift.io/v1 -kind: MachineConfig -metadata: - labels: - machineconfiguration.openshift.io/role: worker - service: cinder - name: 99-master-cinder-enable-multipathd -spec: - config: - ignition: - version: 3.2.0 - storage: - files: - - path: /etc/multipath.conf - overwrite: false - # Mode must be decimal, this is 0600 - mode: 384 - user: - name: root - group: - name: root - contents: - # Source can be a http, https, tftp, s3, gs, or data as defined in rfc2397. - # This is the rfc2397 text/plain string format - source: data:,defaults%20%7B%0A%20%20user_friendly_names%20no%0A%20%20recheck_wwid%20yes%0A%20%20skip_kpartx%20yes%0A%20%20find_multipaths%20yes%0A%7D%0A%0Ablacklist%20%7B%0A%7D - systemd: - units: - - enabled: true - name: multipathd.service ----- -** If you use labels to restrict the nodes where Block Storage services run, you need to use a `MachineConfigPool` to limit the effects of the `MachineConfig` to only the nodes where your services run. For more information, see link:{defaultOCPURL}/nodes/index#nodes-scheduler-node-selectors-about_nodes-scheduler-node-selectors[About node selectors]. -** If you are using a single node deployment to test the process, replace `worker` with `master` in the `MachineConfig`. -** Cinder volume and backup are configured by default to use multipathing. diff --git a/docs_user/modules/ref_preparing-block-storage-service-by-customizing-configuration.adoc b/docs_user/modules/ref_preparing-block-storage-service-by-customizing-configuration.adoc deleted file mode 100644 index 20edb9e68..000000000 --- a/docs_user/modules/ref_preparing-block-storage-service-by-customizing-configuration.adoc +++ /dev/null @@ -1,114 +0,0 @@ -:_mod-docs-content-type: REFERENCE -[id="preparing-block-storage-by-customizing-configuration_{context}"] - -ifeval::["{build}" == "downstream"] -= Converting the {block_storage} configuration - -[role="_abstract"] -In your previous deployment, you use the same `cinder.conf` file for all the services. To prepare your {block_storage_first_ref} configuration for adoption, split this single-file configuration into individual configurations for each {block_storage} service. Review the following information to guide you in coverting your previous configuration: -endif::[] - -ifeval::["{build}" != "downstream"] -= Preparing the {block_storage} by customizing the configuration - -The high level explanation of the tailor-made approach is: -endif::[] - -* Determine what part of the configuration is generic for all the Block Storage services and remove anything that would change when deployed in {rhocp_long}, such as the `connection` in the `[database]` section, the `transport_url` and `log_dir` in the `[DEFAULT]` sections, the whole `[coordination]` and `[barbican]` sections. The remaining generic configuration goes into the `customServiceConfig` option, or a `Secret` custom resource (CR) and is then used in the `customServiceConfigSecrets` section, at the `cinder: template:` level. -* Determine if there is a scheduler-specific configuration and add it to the `customServiceConfig` option in `cinder: template: cinderScheduler`. -* Determine if there is an API-specific configuration and add it to the `customServiceConfig` option in `cinder: template: cinderAPI`. -* If the {block_storage} backup is deployed, add the {block_storage} backup configuration options to `customServiceConfig` option, or to a `Secret` CR that you can add to `customServiceConfigSecrets` section at the `cinder: template: -cinderBackup:` level. Remove the `host` configuration in the `[DEFAULT]` section to support multiple replicas later. -* Determine the individual volume back-end configuration for each of the drivers. The configuration is in the specific driver section, and it includes the `[backend_defaults]` section and FC zoning sections if you use them. The {block_storage} operator does not support a global `customServiceConfig` option for all volume services. Each back end has its own section under `cinder: template: cinderVolumes`, and the configuration goes in the `customServiceConfig` option or in a `Secret` CR and is then used in the `customServiceConfigSecrets` section. -* If any of the {block_storage} volume drivers require a custom vendor image, find the location of the image in the link:https://catalog.redhat.com/search?searchType=software[Red Hat Ecosystem Catalog], and create or modify an `OpenStackVersion` CR to specify the custom image by using the key from the `cinderVolumes` section. -+ -For example, if you have the following configuration: -+ -[source,yaml] ----- -spec: - cinder: - enabled: true - template: - cinderVolume: - pure: - customServiceConfigSecrets: - - openstack-cinder-pure-cfg -< . . . > ----- -+ -Then the `OpenStackVersion` CR that describes the container image for that back end looks like the following example: -+ -[source,yaml] ----- -apiVersion: core.openstack.org/v1beta1 -kind: OpenStackVersion -metadata: - name: openstack -spec: - customContainerImages: - cinderVolumeImages: - pure: registry.connect.redhat.com/purestorage/openstack-cinder-volume-pure-rhosp-18-0' ----- -+ -[NOTE] -The name of the `OpenStackVersion` must match the name of your `OpenStackControlPlane` CR. - -* If your Block Storage services use external files, for example, for a custom policy, or to store credentials or SSL certificate authority bundles to connect to a storage array, make those files available to the right containers. Use `Secrets` or `ConfigMap` to store the information in {OpenShiftShort} and then in the `extraMounts` key. For example, for {Ceph} credentials that are stored in a `Secret` called `ceph-conf-files`, you patch the top-level `extraMounts` key in the `OpenstackControlPlane` CR: -+ -[source,yaml] ----- -spec: - extraMounts: - - extraVol: - - extraVolType: Ceph - mounts: - - mountPath: /etc/ceph - name: ceph - readOnly: true - propagation: - - CinderVolume - - CinderBackup - - Glance - volumes: - - name: ceph - projected: - sources: - - secret: - name: ceph-conf-files ----- - -* For a service-specific file, such as the API policy, you add the configuration -on the service itself. In the following example, you include the `CinderAPI` -configuration that references the policy you are adding from a `ConfigMap` -called `my-cinder-conf` that has a `policy` key with the contents of the policy: -+ -[source,yaml] ----- -spec: - cinder: - enabled: true - template: - cinderAPI: - customServiceConfig: | - [oslo_policy] - policy_file=/etc/cinder/api/policy.yaml - extraMounts: - - extraVol: - - extraVolType: Ceph - mounts: - - mountPath: /etc/cinder/api - name: policy - readOnly: true - propagation: - - CinderAPI - volumes: - - name: policy - projected: - sources: - - configMap: - name: my-cinder-conf - items: - - key: policy - path: policy.yaml ----- diff --git a/docs_user/rhoso_attributes.adoc b/docs_user/rhoso_attributes.adoc deleted file mode 100644 index 563e5d4b5..000000000 --- a/docs_user/rhoso_attributes.adoc +++ /dev/null @@ -1,107 +0,0 @@ -// rhosp_attributes.adoc -// Add this include statement in your master.adoc file: include::common/global/rhosp_attributes.adoc[] -// Run this command to create a sym link in your doc folder: $ ln -s ../common -// Enclose the attribute in {} brackets in your modules. -// Example: Use {osp_long} to display "OpenStack Platform". - -// RHEL version attributes -:rhel_prev_ver: 9.2 -:rhel_curr_ver: 9.4 - -// The {rhelvernum} attribute is currently in use in several deployment docs -:rhelvernum: 9.4 - -// RHOSO version attributes - -:rhos_long: Red{nbsp}Hat OpenStack Services on OpenShift (RHOSO) -:rhos_prev_long: Red{nbsp}Hat OpenStack Platform -:rhos_long_noacro: Red{nbsp}Hat OpenStack Services on OpenShift -:rhos_acro: RHOSO -:rhos_curr_ver: 18.0 -:rhos_curr_ver_no_beta: 18.0 -:rhos_prev_ver: 17.1 -:rhos_z_stream: 0 - - -// RHOCP version attributes - -:ocp_curr_ver: 4.16 -:rhocp_long: Red{nbsp}Hat OpenShift Container Platform (RHOCP) - -// Ceph version attributes - -:CephVernum: 7 - -// Common URLs. Do not override. Do not delete. -:base_url: https://access.redhat.com/documentation -:defaultURL: https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/{rhos_curr_ver}/html -:defaultOCPURL: https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp_curr_ver}/html -:defaultCephURL: https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/{CephVernum}/html - -// books - URLs and titles -:adopting-data-plane: {defaultURL}/adopting_the_red_hat_openstack_platform_data_plane -:auto-scaling: {defaultURL}/auto-scaling_for_instances -:backing-up-volumes: {defaultURL}/backing_up_block_storage_volumes -:backing-up: {defaultURL}/backing_up_and_restoring_the_undercloud_and_control_plane_nodes -:barbican: {defaultURL}/managing_secrets_with_the_key_manager_service -:bare-metal: {defaultURL}/configuring_the_bare_metal_provisioning_service -:bgp: {defaultURL}/configuring_dynamic_routing -:bgp-t: Configuring dynamic routing -:commandline-ref: {defaultURL}/command_line_interface_reference -:commandline-ref-t: Command line interface reference -:configuration-ref: {defaultURL}/configuration_reference -:configure-compute: {defaultURL}/configuring_the_compute_service_for_instance_creation -:configure-compute-t: Configuring the Compute service for instance creation -:configuring-storage: {defaultURL}/configuring_persistent_storage -:configuring-storage-t: Configuring persistent storage -:creating-images: {defaultURL}/creating_and_managing_images -:creating-instances: {defaultURL}/creating_and_managing_instances -:creating-instances-t: Creating and managing instances -:customizing-rhoso: {defaultURL}/customizing_the_red_hat_openstack_services_on_openshift_deployment -:customizing-rhoso-t: Customizing the Red Hat OpenStack Services on OpenShift deployment -:dashboard: {defaultURL}/managing_cloud_resources_with_the_openstack_dashboard -:dcn: {defaultURL}/deploying_a_distributed_compute_node_dcn_architecture -:deploy-at-scale: {defaultURL}/deploying_red_hat_openstack_platform_at_scale -:deploy-in-rhocp: {defaultURL}/deploying_an_overcloud_in_a_red_hat_openshift_container_platform_cluster_with_director_operator -:deploying-rhoso: {defaultURL}/deploying_red_hat_openstack_services_on_openshift -:deploying-rhoso-t: Deploying Red Hat OpenStack Services on OpenShift -:designate: {defaultURL}/configuring_dns_as_a_service -:designate-t: Configuring DNS as a service -:existing-ceph: {defaultURL}/integrating_an_overcloud_with_an_existing_red_hat_ceph_storage_cluster -:external-identity: {defaultURL}/integrating_openstack_identity_with_external_user_management_services -:ffu: {defaultURL}/framework_for_upgrades_16.2_to_17.1 -:firewall-rules: {defaultURL}/firewall_rules_for_red_hat_openstack_platform -:ha-for-instances: {defaultURL}/configuring_high_availability_for_instances -:hci: {defaultURL}/deploying_a_hyperconverged_infrastructure_environment -:hci-t: Deploying a hyperconverged infrastructure environment -:identity: {defaultURL}/managing_openstack_identity_resources -:installing-director: {defaultURL}/installing_and_managing_red_hat_openstack_platform_with_director -:intro-to-containers: {defaultURL}/introduction_to_containerized_services_in_red_hat_openstack_platform -:intro-to-rhosp: {defaultURL}/introduction_to_red_hat_openstack_platform -:ipv6: {defaultURL}/configuring_ipv6_networking_for_the_overcloud -:managing-ha: {defaultURL}/managing_high_availability_services -:migrating-to-ovn: {defaultURL}/migrating_to_the_ovn_mechanism_driver -:minor-update: {defaultURL}/performing_a_minor_update_of_red_hat_openstack_platform -:network-config: {defaultURL}/configuring_networking_services -:network-config-t: Configuring networking services -:network-manage: {defaultURL}/managing_networking_resources -:network-manage-t: Managing networking resources -:nfv: {defaultURL}/deploying_a_network_functions_virtualization_environment -:nfv-t: Deploying a Network Functions Virtualization environment -:observability: {defaultURL}/managing_overcloud_observability -:oc-params: {defaultURL}/overcloud_parameters -:octavia: {defaultURL}/configuring_load_balancing_as_a_service -:octavia-t: Configuring load balancing as a service -:planning: {defaultURL}/planning_your_deployment -:planning-t: Planning your deployment -:release-notes: {defaultURL}/release_notes -:rhos-deployed-ceph: {defaultURL}/deploying_red_hat_ceph_storage_and_red_hat_openstack_platform_together_with_director -:security-guide: {defaultURL}/hardening_red_hat_openstack_platform -:spine-leaf: {defaultURL}/configuring_spine-leaf_networking -:spine-leaf-t: Configuring spine-leaf networking -:stf-release-notes: {defaultURL}/service_telemetry_framework_release_notes_1.5 -:stf: {defaultURL}/service_telemetry_framework_1.5 -:test-suite: {defaultURL}/validating_your_cloud_with_the_red_hat_openstack_platform_integration_test_suite - -// Specific links -:setup-tlse: {defaultURL}/hardening_red_hat_openstack_platform/assembly_securing-rhos-with-tls-and-pki_security_and_hardening#proc_implementing-tls-e-with-ansible_encryption-and-key-management[Implementing TLS-e with Ansible]