Implement a workload autoscaling solution in OpenStack Operator-driven deployments using components available to the next generation OpenStack solution.

Feature is not intended to be backported.

Goals

In RHOSP 17.1 and earlier the workload autoscaling solution was implemented using the following services:

• Gnocchi
• Ceilometer
• Heat
• Aodh

In the modernized OpenStack deployment framework not all of these supporting services are expected to be available, and thus a new solution needs to be created in a way that aligns to the workflows and deployment methods used in the modernized solution.

OpenStack administrators who previously made use of the horizontal virtualized workload (instance) scale up and scale down solution may expect for this feature to be available in an on-premise cloud solution.

Currently telemetry is collected (Ceilometer) and written to a time-series data store (Gnocchi). Thresholds are defined using THT and loaded into Aodh as an alarming service to trigger Heat to perform the actual scale up and scale down solution.

More information is available at https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/17.1-beta/html/auto-scaling_for_instances

It is expected that in RHOSP 18 and later that the Gnocchi time-series database will not be available, and thus a new time-series database implementation will be required for storage of telemetry data, and integrated using other appropriate services within the RHOSP 18 environment.

Requirements

A list of specific needs 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.

(Optional) Use Cases

< How will the user interact with this feature? >

< Which users will use this and when will they use it? >

< Is this feature used as part of current user interface? >

Out of Scope

Background, and strategic fit

< What does the person writing code, testing, documenting need to know? >

Assumptions

< Are there assumptions being made regarding prerequisites and dependencies?>

< Are there assumptions about hardware, software or people resources?>

Customer Considerations

< Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

< Are there upgrade considerations that customers need to account for or that the feature should address on behalf of the customer?>

Documentation Considerations

< What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >

< What does success look like?>

< Does this feature have doc impact?  Possible values are: New Content, Updates to existing content,  Release Note, or No Doc Impact>

< If unsure and no Technical Writer is available, please contact Content Strategy. If yes, complete the following.>

• <What concepts do customers need to understand to be successful in [action]?>

• <How do we expect customers will use the feature? For what purpose(s)?>

• <What reference material might a customer want/need to complete [action]?>

• <Is there source material that can be used as reference for the Technical Writer in writing the content? If yes, please link if available. >

• <What is the doc impact (New Content, Updates to existing content, or Release Note)?>

Interoperability Considerations

< Which other products and versions in our portfolio does this feature impact?>

< What interoperability test scenarios should be factored by the layered product(s)?>