MEA scaling¶

TOSCA schema for scaling policy¶

Apmec defines TOSCA schema for the scaling policy as given below:

tosca.policies.apmec.Scaling:
  derived_from: tosca.policies.Scaling
  description: Defines policy for scaling the given targets.
  properties:
    increment:
      type: integer
      required: true
      description: Number of nodes to add or remove during the scale out/in.
    targets:
      type: list
      entry_schema:
        type: string
      required: true
      description: List of Scaling nodes.
    min_instances:
      type: integer
      required: true
      description: Minimum number of instances to scale in.
    max_instances:
      type: integer
      required: true
      description: Maximum number of instances to scale out.
    default_instances:
      type: integer
      required: true
      description: Initial number of instances.
    cooldown:
      type: integer
      required: false
      default: 120
      description: Wait time (in seconds) between consecutive scaling
      operations. During the cooldown period, scaling action will be ignored

Sample TOSCA with scaling policy¶

Following TOSCA snippet shows the scaling policy used in MEAD, in which vdu1 and vdu2 are already defined VDUs.

policies:

   sp1:

     type: tosca.policies.apmec.Scaling

     description: Simple VDU scaling

     properties:
        min_instances: 1

        max_instances: 3

        default_instances: 2

        increment: 1

        targets: [vdu1, vdu2]

Deploying scaling TOSCA template using Apmec¶

Once OpenStack/Devstack along with Apmec has been successfully installed, deploy a sample scaling template from location given below: https://github.com/openstack/apmec/tree/master/samples/tosca-templates/mead

Refer the ‘Getting Started’ link below on how to create a MEAD and deploy a MEA: https://docs.openstack.org/apmec/latest/install/getting_started.html

How to scale MEA using CLI¶

Apmec provides following CLI for scaling.

apmec mea-scale –mea-id <mea-id>

–mea-name <mea name> –scaling-policy-name <policy name> –scaling-type <type>

Here,

• scaling-policy-name - Policy name defined in scaling MEAD
• scaling-type - in or out
• mea-id - scaling MEA id
• mea-name - scaling MEA name

For example, to scale-out policy ‘sp1’ defined above, this cli could be used as below:

apmec mea-scale –mea-name sample-mea

–scaling-policy-name sp1 –scaling-type out

How to scale MEA using REST API¶

Apmec provides following REST API for scaling.

POST on v1.0/meas/<mea-id>/actions

with body

{“scale”: { “type”: “<type>”, “policy” : “<scaling-policy-name>”}}

Here,

• scaling-policy-name - Policy name defined in scaling MEAD
• scaling-type - in or out
• mea-id - scaling MEA id

Response http status codes:

• 202 - Accepted the request for doing the scaling operation
• 404 - Bad request, if given scaling-policy-name and type are invalid
• 500 - Internal server error, on scaling operation failed due to an error
• 401 - Unauthorized

MEA state transitions during scaling operation¶

During the scaling operation, the MEA will be moving in below state transformations:

• ACTIVE -> PENDING_SCALE_IN -> ACTIVE
• ACTIVE -> PENDING_SCALE_IN -> ERROR
• ACTIVE -> PENDING_SCALE_OUT -> ACTIVE
• ACTIVE -> PENDING_SCALE_OUT -> ERROR

Limitations¶

Following features are not supported with scaling:

• Auto-scaling feature is supported only with alarm monitors and it does not work with other monitors such as ping, http_ping.
• When MEA is modelled with scaling requirement in MEAD, any config management requirement in MEAD is not supported.
• Scaling feature does not support to selectively choose the VDU as part of scaling.