RFE: Support for OS::Heat::AutoScalingGroup

[alonsocamaro]

To describe this RFE first I’m going to describe how LBaaS adapts the pool members whenever scaling in or scaling out happens by means of using OS::Heat::AutoScalingGroup

We will use two templates for this: master.yaml which describes the whole deployment making use of a server.yaml resource type

• master.yaml uses OS::Heat::AutoScalingGroup and increases or descreases the number of instances of server.yaml. This template also has the resources OS::Neutron::LBaaS::LoadBalancer, OS::Neutron::LBaaS::Listener, OS::Neutron::LBaaS::Pool and OS::Neutron::LBaaS::HealthMonitor but NOT OS::Neutron::LBaaS::PoolMember. The OS::Neutron::LBaaS::Pool is passed as a parameter to server.yaml.

• server.yaml will create the VM instance of the server and will auto-add itself to the pool. More precisely by receiving the The OS::Neutron::LBaaS::Pool parameter the server.yaml can add itself to the pool by instantiating a OS::Neutron::LBaaS::PoolMember resource.

This RFE is to allow this auto-scaling model in Apps just described which is very intuitive, self-contained and is also used by LBaaS.

For implementing this we would need two new resource types:

• one resource type to retrieve the reference to the pool from the iApp (i.e.: F5::Sys::iAppPool) and would have the following properties:

  type: F5::Sys::iAppPool
   properties:
     service: F5::Sys::iAppService
     pool_name: String

• the second resource type would allow server.yaml (using the example below) to auto-scale itself and could be called F5::Sys::iAppPoolMember (following the LBaaS naming). This would have the following properties:

    type: F5::Sys::iAppPoolMember
    properties:
       pool: F5::Sys::iAppPool
       address: String
       protocol_port: Integer

as a minimum but all the properties of a pool member should be added, these are:

root@(bigip2)(cfg-sync Changes Pending)(Active)(/Common)(tmos)# list ltm pool test members { 1.1.1.1:0 } 
ltm pool test {
    members {
        1.1.1.1:any {
            address 1.1.1.1
            app-service none
            connection-limit 0
            description none
            dynamic-ratio 1
            ephemeral false
            inherit-profile enabled
            logging disabled
            monitor default
            priority-group 0
            rate-limit disabled
            ratio 1
            session user-enabled
            state unchecked
            fqdn {
                autopopulate disabled
                name none
            }
            metadata none
            profiles none
        }
    }
}

Some comments:

This model supports iApps that have several pools.

It should be taken into account that the iApp might have strict-updates enabled. I believe that these could be disabled temporarily: if an iApp service has strict-updates enabled a transaction would be created to disable strict-updates, change the members in the pool and finally re-enable strict-updates.

Worth to note is that an additional plus of following the same auto-scaling model as LBaaS is that LBaaS applications could migrated to iApps easily to allow richer functionalities.

[alonsocamaro]

When I initially created this RFE I initially only mentioned support for iApps because that is what I always use -- I was thinking selfish :-D

The AutoScalingGroup feature should be also supported for regular pools.

We would only need a new F5::LTM::PoolMember resource type which would be analogous to OS::Neutron::LBaaS::PoolMember in the example above. We would not need another resource type -- assuming that we can use F5::LTM::Pool as property of this new resource type.

[tkam8]

+1, would also like to see this RFE for LTM autoscale