Chapter 2. Migrating autoscaling from earlier RHOSP deployments There are important differences between the autoscaling heat templates on Red Hat OpenStack Services on OpenShift (RHOSO) and versions of Red Hat OpenStack Platform (RHOSP): Updated alarm types and parameters. Groups of instances. Alarm queries. 2.1. Updating alarm types and obsolete parameters versions of Red Hat OpenStack Platform (RHOSP) used Gnocchi for metric storage. Because Red Hat OpenStack Services on OpenShift (RHOSO) uses Prometheus for metric storage instead, you need to edit the alarm types in your existing template files. Procedure Update the value of the resources.cpu_alarm_high.type parameter from OS::Aodh::GnocchiAggregationByResourcesAlarm to OS::Aodh::PrometheusAlarm . Update the value of the resources.cpu_alarm_low.type parameter from OS::Aodh::GnocchiAggregationByResourcesAlarm to OS::Aodh::PrometheusAlarm . Delete the following parameters from the alarm definitions section of the template: metric aggregation_method granularity evaluation_periods resource_type 2.2. Querying the alarms In Red Hat OpenStack Services on OpenShift (RHOSO), ensure that the queries in the alarm definitions are compatible with PromQL. Procedure Include server_group=<stack_id> in the queries to select only the instances in the stack. The ceilometer_cpu metric is stored as an accumulated value recording the CPU time total since the instance was created. You can use the PromQL rate() function to query only for a specified CPU time or a percentage value of CPU time for a certain duration. In Red Hat OpenStack Platform (RHOSP) versions, this was not automatic, but now you can automatically compute the percentage as part of the query. You can use the PromQL rate() function like this: rate(ceilometer_cpu{server_group=<stack_id>}[<duration>]) . To avoid unstable query results, calculate the <duration> by adding <ceilometer polling interval> to <prometheus scrape interval>. Optional: You can use the USD openstack metric query command to check what the new queries return. Ensure that you test your queries. You can check that only instances from the relevant stack are queried, take note of the metric values returned by the queries, and ensure that you set the thresholds in the alarm definitions accordingly. autoscaling.yaml 47,49c50,53 < list_join: < - '' < - - {'=': {server_group: {get_param: "OS::stack_id"}}} --- > str_replace: > template: "(rate(ceilometer_cpu{server_group='stack_id'}[150s]))/10000000" > params: > stack_id: {get_param: OS::stack_id} 68,70c67,70 < list_join: < - '' < - - {'=': {server_group: {get_param: "OS::stack_id"}}} --- > str_replace: > template: "(rate(ceilometer_cpu{server_group='stack_id'}[150s]))/10000000" > params: > stack_id: {get_param: OS::stack_id}

Commands:
47,49c50,53 < list_join: < - '' < - - {'=': {server_group: {get_param: "OS::stack_id"}}} --- > str_replace: > template: "(rate(ceilometer_cpu{server_group='stack_id'}[150s]))/10000000" > params: > stack_id: {get_param: OS::stack_id} 68,70c67,70 < list_join: < - '' < - - {'=': {server_group: {get_param: "OS::stack_id"}}} --- > str_replace: > template: "(rate(ceilometer_cpu{server_group='stack_id'}[150s]))/10000000" > params: > stack_id: {get_param: OS::stack_id}