Uploaded image for project: 'OpenStack Strategy'
  1. OpenStack Strategy
  2. RHOSSTRAT-1076

Add Heat Orchestration Template (HOT) support to the Red Hat OpenStack VMware Migration Toolkit

XMLWordPrintable

    • Icon: Feature Feature
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None
    • Migrations
    • None
    • Not Selected
    • False
    • False
    • Hide

      None

      Show
      None
    • 0
    • 0
    • 100% To Do, 0% In Progress, 0% Done
    • rhos-ops-day1day2-migrations

      Feature Request Overview

      Currently, the VMware Migration Kit creates OpenStack resources (instances, volumes, network ports, flavors) individually during the migration process. When migrating multiple VMs or when migration fails, there is no unified way to manage, track, or clean up all related resources as a single unit. Users need a way to:

      1. Group all migration-related OpenStack resources under a single Heat stack for better resource management
      2. Have a single point of reference for all resources created during a migration batch
      3. Simplify cleanup operations by deleting the entire stack instead of individual resources
      4. Enable better cost tracking and resource governance through Heat stack tagging

      Business justification

      • Improved Resource Management: Heat stacks provide a unified view of all resources created during migration, making it easier to track and manage complex multi-VM migrations
      • Enhanced Reliability: Heat's built-in rollback capabilities ensure that failed migrations can be cleanly reverted, preventing orphaned resources
      • Simplified Operations: Operators can manage entire migration batches through a single Heat stack instead of tracking individual resources
      • Better Cost Control: Heat stack tagging enables better cost allocation and tracking for migration projects
      • Compliance & Governance: Organizations can apply consistent policies and tags across all migration resources through Heat templates
      • Reduced Manual Effort: Eliminates the need for manual cleanup of individual resources when migrations fail or need to be rolled back

      Functional Requirements

      1. Heat Stack Creation: The migration kit should create a Heat stack for each migration batch, with the stack name derived from a configurable pattern (e.g., vmware-migration-{batch-id} or vmware-migration-{timestamp})

      2. Resource Grouping: All OpenStack resources created during migration should be managed within the Heat stack:

      • Nova instances (servers)
      • Cinder volumes (boot and data volumes)
      • Neutron ports
      • Nova flavors (when created dynamically)
      • Security groups (if created)

      3. Heat Template Generation:
      Automatically generate Heat templates that include:

      • All VM instances with their configurations
      • Associated volumes with proper dependencies
      • Network ports with security group assignments
      • Flavor definitions (when dynamically created)
      • Proper resource dependencies and relationships

      (Optional) Point of contact Provide any additional points of contact for this feature request, such as an account executive, SA, or TAM:

      Greg Procunier
       
      (Optional) Additional links Click More > Link to add any links to issues, such as an outcome, that are related to this feature request.

      Feature Overview (mandatory - Complete while in New status)
      An elevator pitch (value statement) that describes the Feature in a clear, concise way. ie: Executive Summary of the user goal or problem that is being solved, why does this matter to the user? The “What & Why”... 
      <your text here>

      Goals (mandatory - Complete while in New status)
      Provide high-level goal statement, providing user context and expected user outcome(s) for this Feature

      • Who benefits from this Feature, and how? 
      • What is the difference between today’s current state and a world with this Feature?
        <your text here>

      Requirements (mandatory -_ Complete while in Refinement status):
      A list of specific needs, capabilities, or objectives that a Feature must deliver to satisfy the Feature. Some requirements will be flagged as MVP. If an MVP gets shifted, the Feature shifts. If a non MVP requirement slips, it does not shift the feature.

      Requirement Notes isMVP?
           
           

       
      Done - Acceptance Criteria (mandatory - Complete while in Refinement status):
      Acceptance Criteria articulates and defines the value proposition - what is required to meet the goal and intent of this Feature. The Acceptance Criteria provides a detailed definition of scope and the expected outcomes - from a users point of view

      <your text here>
      Use Cases - i.e. User Experience & Workflow: (Initial completion while in Refinement status):
      Include use case diagrams, main success scenarios, alternative flow scenarios.
      <your text here>
      Out of Scope _ _(Initial completion while in Refinement status):
      High-level list of items or persona’s that are out of scope.
      <your text here>
      Documentation Considerations _ _(Initial completion while in Refinement status):
      Provide information that needs to be considered and planned so that documentation will meet customer needs. If the feature extends existing functionality, provide a link to its current documentation..
      <your text here>
       
      Questions to Answer _ _(Initial completion while in Refinement status):
      Include a list of refinement / architectural questions that may need to be answered before coding can begin.
      <your text here>
      Background and Strategic Fit (Initial completion while in Refinement status):
      Provide any additional context is needed to frame the feature.
      <your text here>
      Customer Considerations _ _(Initial completion while in Refinement status):
      Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.
      <your text here>
      Team Sign Off (Completion while in Planning status)

      • All required Epics (known at the time) are linked to the this Feature
      • All required Stories, Tasks (known at the time) for the most immediate Epics have been created and estimated
      • Add - Reviewers name, Team Name
      • Acceptance == Feature as “Ready” - well understood and scope is clear - Acceptance Criteria (scope) is elaborated, well defined, and understood
      • Note: Only set FixVersion/s: on a Feature if the delivery team agrees they have the capacity and have committed that capability for that milestone
        Reviewed By Team Name Accepted Notes
               
               
               
               

              rhn-engineering-apevec Alan Pevec
              gprocuni@redhat.com Greg Procunier
              rhos-dfg-migrations
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated: