As an OpenStack Administrator using OpenStack Operator-driven deployment I want a virtual machine workload autoscaling solution.

Why it Matters

In RHOSP 17.1 and 16.2 systems, OpenStack administrators had the ability to implement virtual machine workload autoscaling using a combination of Heat, Gnocchi, Aodh, and Ceilometer.

In RHOSP 18 some of the components originally used as part of an autoscaling solution are either changing or being removed, so a new solution needs to be identified if there are customer needs for this solution.

TODO: evaluate the market to determine that a new solution should be implemented to maintain a workload autoscaling solution within RHOSP 18 and later.

Illustrative User Stories

As a <USER>, I want <EASE OF ACQUISITION AND DEPLOYMENT> because <TIME TO DEPLOYMENT MATTERS TO ME>.

Expected Outcomes

<Not metrics (those are in features), but should inspire metrics>

Articulates and defines the value proposition from a user's point of view, frames what is needed to fulfill the goal and outcome of this Outcome, and provides a level of detail, some framing of scope, and the expected outcomes

Effect 

Effect is the expected outcome within the market.  There are two outcomes: growth or retention. This represents part of the “why” statement for a feature.

Growth is the acquisition of net new usage of the platform.  This can be new workloads not previously able to be supported, new markets not previously considered, or new end users not previously served.

Retention is maintaining and expanding existing use of the platform.  This can be more effective use of tools, competitive pressures,  and ease of use improvements.

Partner

Partner is any specific delivery vehicle requirements.  These are feature components that MUST be delivered in concert with or through a particular BU external product.  This represents part of the “how” statement for a feature. This would be the optional only category.

Layered product is when a Red Hat product has functional requirements.