>> 1. VM Counters that specify the monitored aspects of the VMs (some >> of these counters are monitored through SNMP agents running inside the > >VM- hence they are of the SNMP type)
>This is specific to the implementation. There are several ways to monitor >performance. SNMP is just one. Hence it should not be part of the API. It can >be a generic key-value pair (for an >example, look at the >createLbStickinessPolicy >http://download.cloud.com/releases/3.0.0/api_3.0.0/user/createLBStickinessPolicy.html) Counters can be of any type. One of the types supported is SNMP. If the user has got an SNMP agent inside his VM that is monitoring some aspect of that VM, he needs to be able to configure it as a counter that can be used in the autoscale policies. If the contention is not to surface the "type" of a counter, we can hide it inside a "param" argument, which can contain "type" as one of the keys in a key/value list. In any case, the implementer must understand how to instantiate counters. >>3. VM Profile that contains the details needed to auto-instantiates >>VMs and captures anything VM-specific (template, service offering, >>network, VM's SNMP agent port and community, etc.) > > Template, service offering and network are generic, SNMP is not. Same here, the VM's SNMP port and community string are specific to the VM and can be configured as a generic key/value list. >>The implementation relies on the LoadBalancer Resource being able to >>support this new config item in an LB Rule. Any LB offering in >>CloudStack can support this new additional config and is free in the >>way it implements it. CloudStack will only allow configuring this >>feature on an LB Rule when the network LB offering supports it. The >>NetScaler offering will support this new feature, and we are extending >>the existing NetScaler Resource layer to implement it. >> > >It is not necessary for an LB to implement the auto scaling. Any other >component can do the same. For example, a component can monitor via hypervisor >stats, or volume IO stats. So in >this sense it is not generic. It is not necessary for an LB to implement the auto scaling but NetScaler LB provides one and we want to allow CS admins who are using NetScaler to be able to take advantage of it. There is nothing here that prevents other components to take advantage of Counters, AutoScale policies, etc. if they wish to. Youcef
