• False
    • Hide

      None

      Show
      None
    • False
    • ?
    • Targeted
    • OSP-14492 - Enable agnostic new device hardware with multi-vendor migration capabilities
    • ?
    • ?

      Why is this Epic required for deployment and adoption support for the 17.1 OSP feature set, except for 17.1 functionality that has been intentionally re-prioritized to 18-Feature Release-1 or later, and in-place update to post-18.0.0 releases.

      This is tracking the tooling to migrate VMs from the deprecated (in 17.1) `pc` machine type to the supported `q35` machine type. `pc` is not supported in 18. Migrating all VMs is a soft-requirement in 17.1 before the adoption to 18, but nothing actually enforces that, so we're bound to get customers who adopt and land themselves in an unsupported state. We need to support the migration tooling in 18 GA.

      *Do you have capacity to complete the work, testing and documentation required for
      this Epic and is all the remaining work captured in Jira stories?*

      This is a question for Docs/QE, as the only remaining work is to update the existing procedure to work in a podified world, and test the new procedure.

      What is the probability and severity of the issue? I.e. the overall risk

      NA, no issue here.

      Does this affect specific configurations, hardware, environmental factors, etc.?

      Our default machine type was `q35` in 17.1, but `pc` in 16.x, so we're bound to have some customer with old deployments that still have VMs with the `pc` machine type, but the exact % is unknown.

      Are any partners relying on this functionality in order to ship an ecosystem product?

      Probably not.

      What proportion of our customers could hit this issue?

      See two points above, unknown.

      Does this happen for only a specific use case?

      See three points above.

      What proportion of our CI infrastructure, automation, and test cases does this issue impact?

      To my knowledge we have no CI for this, it's manual procedure verification at this point.

      Is this a regression in supported functionality from a previous release?

      Yes, this was supported in 17.1.

      Is there a clear workaround?

      No.

      Is there potential doc impact?

      Yes.

      If this is a UI issue

      NA

      Overall context and effort – is the overall impact bigger/worse than the bug in isolation?

      There's no bug here, so it's a matter of deciding whether the QE/docs effort is worse than not having a way out for the customers that land themselves in the situation described in point 1.

              Unassigned Unassigned
              jjoyce@redhat.com Jason Joyce
              rhos-dfg-compute
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: