Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nova multi-cell adoption requires different renaming technics for cells databases during importing it #184

Open
bogdando opened this issue Oct 18, 2023 · 0 comments · May be fixed by #746 or openstack-k8s-operators/ci-framework#2601

Comments

@bogdando
Copy link
Contributor

  • Document deployment of dev setup for adoption of a multi-stack topology for Nova cells v2.
    • Gotchas: connecting an extra standalone compute host to the central standalone host is problematic as it doesn't fit the supported multi-cell v2 topologies in OSP. No dev envs shortcuts possible? If that would become supported at least for dev envs, the approximate scenario might look like:

      • Create the edpm-compute-1 and edpm-compute-2 virtual machinee for Nova compute cells.
      make edpm_compute EDPM_COMPUTE_SUFFIX=1
      make edpm_compute_repos EDPM_COMPUTE_SUFFIX=1
      
      • Omit the edpm_deploy make target to not making it managed from the control
        plane running on OCP. Instead, deploy it as a 2nd TripleO standalone Heat stack,
        with an extra OSP compute:
      make standalone EDPM_COMPUTE_SUFFIX=1 EDPM_COMPUTE_CEPH_ENABLED=false
      (requires intall_yaml to support exporting stack data to use it with consequent stacks additions 
      https://github.com/openstack-k8s-operators/install_yamls/pull/568)
      
      • Ssh into deployed standalone host:
      ssh -i ~/install_yamls/out/edpm/ansibleee-ssh-key-id_rsa [email protected]
      
      • Discover the deployed compute host keys (a passwordless access is required by
        the Nova Live-migration feature):
      ssh-copy-id -i ~/.ssh/id_rsa [email protected]
      
      • Discover the remote compute node from the central controller node ...
  • Adjust the databases importing/renaming script for real multi-stack cases:
    • nova_cell1-> nova_cell2, ..., nova_cellN -> nova_cellN+1, nova-> nova_cell1.
    • if there were computes in the 'default' (int terms of tripleo) cell, then it needs to be imported and adopted like a normal cell,
      and renamed like 'default' -> cell<latest+1>. For a single stack scenario, that is cell1. And the command that renames the default cell name should become update nova_api.cell_mappings set name="cell<latest+1>" where name="default";'
    • For that, add a second map in the DB importing script, and loop cell_name_map["default"] = "nova_cell$x".
@bogdando bogdando changed the title Nova multi-cell adoption requires different renaming technics for cells database during importing it Nova multi-cell adoption requires different renaming technics for cells databases during importing it Oct 18, 2023
@github-actions github-actions bot added the Stale label Nov 17, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 24, 2024
@bogdando bogdando reopened this Nov 25, 2024
@bogdando bogdando linked a pull request Nov 25, 2024 that will close this issue
@github-actions github-actions bot removed the Stale label Nov 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant