Re: [openstack-dev] [ceilometer] time based auto scaling

2015-05-03 Thread Ildikó Váncsa
Hi,

I like the base idea to trigger scaling based on other information than what we 
have from the current Ceilometer alarms.

Although I think this functionality should live somewhere else than under the 
responsibility of Ceilometer. This type of scaling is usually based on trend 
analysis and other application specific data, which is out of the scope for 
Ceilometer, even if it has the capability of triggering Heat.

Best Regards,
Ildiko

Feladó: Julien Danjou [jul...@danjou.info]
Küldve: 2015. április 29. 9:29
Címzett: ZhiQiang Fan
Másolatot kap: OpenStack Development Mailing List
Tárgy: Re: [openstack-dev] [ceilometer] time based auto scaling

On Wed, Apr 29 2015, ZhiQiang Fan wrote:

 However, current ceilometer only provide time constraint alarm, which will
 only evaluate but not guarantee it will be triggered. And heat cannot
 provide something like timer, but just can wait for the signal.

 So I propose to add a new type of alarm, which will definitely send a
 signal to action when it is evaluated (with or without repeat, it will work
 well with time constraint)

 Any suggestion?

I've proposed exactly that around 18-24 years go I think during a
summit, and nobody was really interested back then and was worried to
have yet another cron system – though OpenStack didn't have one.

I still think it's a good idea and it will be a nice addition to the
alarming system, so if you want to write a spec for that I'll be all
yours. :)

--
Julien Danjou
# Free Software hacker
# http://julien.danjou.info

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ceilometer] time based auto scaling

2015-04-29 Thread Julien Danjou
On Wed, Apr 29 2015, ZhiQiang Fan wrote:

 However, current ceilometer only provide time constraint alarm, which will
 only evaluate but not guarantee it will be triggered. And heat cannot
 provide something like timer, but just can wait for the signal.

 So I propose to add a new type of alarm, which will definitely send a
 signal to action when it is evaluated (with or without repeat, it will work
 well with time constraint)

 Any suggestion?

I've proposed exactly that around 18-24 years go I think during a
summit, and nobody was really interested back then and was worried to
have yet another cron system – though OpenStack didn't have one.

I still think it's a good idea and it will be a nice addition to the
alarming system, so if you want to write a spec for that I'll be all
yours. :)

-- 
Julien Danjou
# Free Software hacker
# http://julien.danjou.info


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ceilometer] time based auto scaling

2015-04-28 Thread Fei Long Wang
+1, if you really care about time range, Mistral can meet your requirements.

Besides, maybe not directly related, as for autoscaling, I always
believe there should be a message queue service(like Zaqar) between the
(web) application and the worker, a task request will be posted to the
queue as a message, worker will pick the message from the queue to
handle. And then we can trigger the autoscaling based on the workload of
queue instead of the hardware usage. Just drop my 2 cents.

On 29/04/15 16:39, Fox, Kevin M wrote:
 what about Mistral?

 https://wiki.openstack.org/wiki/Mistral

 Thanks,
 Kevin *
  
 *
 
 *From:* ZhiQiang Fan
 *Sent:* Tuesday, April 28, 2015 9:23:20 PM
 *To:* OpenStack Development Mailing List
 *Subject:* [openstack-dev] [ceilometer] time based auto scaling

 Hi devs,

 I'm thinking to add new type of alarm for time based auto scaling, but
 not sure if there is a better way to achieve it outside ceilometer scope

 Currently we can auto scaling based on vm load, but it will take
 several minutes to do it. For the worst case, when the vm load is
 heavy, ceilometer needs 10 minutes (by default) to collect the
 performance data, and alarm need 1 minutes to evaluate it, maybe there
 is evaluation_periods which set to higher that 1 to avoid performance
 peak. 

 So even though we can collect data by 1 minutes, but evaluation
 periods may be set to 3, so the worst case is after vm load perfomance
 in high level for 4 minutes, then the alarm is triggered, then heat
 will expand vm count, nova will take dozens seconds or more to create,
 finally the service on the in the heat server group will performance
 bad or unavailable for several minutes, which is not acceptable for
 some critical applications.

 But if we can know some high load which related with time, for
 example, 08:00am will be a peak, and after 22:00pm will definitely
 drop to idel level, then heat can increase some vms at 07:30am, then
 decrease some vms at 22:00 (or decrease by load as normal routine)

 However, current ceilometer only provide time constraint alarm, which
 will only evaluate but not guarantee it will be triggered. And heat
 cannot provide something like timer, but just can wait for the signal.

 So I propose to add a new type of alarm, which will definitely send a
 signal to action when it is evaluated (with or without repeat, it will
 work well with time constraint)

 Any suggestion?


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Cheers  Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ceilometer] time based auto scaling

2015-04-28 Thread Fox, Kevin M
what about Mistral?

https://wiki.openstack.org/wiki/Mistral

Thanks,
Kevin


From: ZhiQiang Fan
Sent: Tuesday, April 28, 2015 9:23:20 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [ceilometer] time based auto scaling

Hi devs,

I'm thinking to add new type of alarm for time based auto scaling, but not sure 
if there is a better way to achieve it outside ceilometer scope

Currently we can auto scaling based on vm load, but it will take several 
minutes to do it. For the worst case, when the vm load is heavy, ceilometer 
needs 10 minutes (by default) to collect the performance data, and alarm need 1 
minutes to evaluate it, maybe there is evaluation_periods which set to higher 
that 1 to avoid performance peak.

So even though we can collect data by 1 minutes, but evaluation periods may be 
set to 3, so the worst case is after vm load perfomance in high level for 4 
minutes, then the alarm is triggered, then heat will expand vm count, nova will 
take dozens seconds or more to create, finally the service on the in the heat 
server group will performance bad or unavailable for several minutes, which is 
not acceptable for some critical applications.

But if we can know some high load which related with time, for example, 08:00am 
will be a peak, and after 22:00pm will definitely drop to idel level, then heat 
can increase some vms at 07:30am, then decrease some vms at 22:00 (or decrease 
by load as normal routine)

However, current ceilometer only provide time constraint alarm, which will only 
evaluate but not guarantee it will be triggered. And heat cannot provide 
something like timer, but just can wait for the signal.

So I propose to add a new type of alarm, which will definitely send a signal to 
action when it is evaluated (with or without repeat, it will work well with 
time constraint)

Any suggestion?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [ceilometer] time based auto scaling

2015-04-28 Thread ZhiQiang Fan
Hi devs,

I'm thinking to add new type of alarm for time based auto scaling, but not
sure if there is a better way to achieve it outside ceilometer scope

Currently we can auto scaling based on vm load, but it will take several
minutes to do it. For the worst case, when the vm load is heavy, ceilometer
needs 10 minutes (by default) to collect the performance data, and alarm
need 1 minutes to evaluate it, maybe there is evaluation_periods which set
to higher that 1 to avoid performance peak.

So even though we can collect data by 1 minutes, but evaluation periods may
be set to 3, so the worst case is after vm load perfomance in high level
for 4 minutes, then the alarm is triggered, then heat will expand vm count,
nova will take dozens seconds or more to create, finally the service on the
in the heat server group will performance bad or unavailable for several
minutes, which is not acceptable for some critical applications.

But if we can know some high load which related with time, for example,
08:00am will be a peak, and after 22:00pm will definitely drop to idel
level, then heat can increase some vms at 07:30am, then decrease some vms
at 22:00 (or decrease by load as normal routine)

However, current ceilometer only provide time constraint alarm, which will
only evaluate but not guarantee it will be triggered. And heat cannot
provide something like timer, but just can wait for the signal.

So I propose to add a new type of alarm, which will definitely send a
signal to action when it is evaluated (with or without repeat, it will work
well with time constraint)

Any suggestion?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] ?????? [ceilometer] time based auto scaling

2015-04-28 Thread Luo Gangyi
Agree with ZhiQiang. 


Maybe we could achieve this by heat itself or other project like Mistral, 
but it seems more natural to achieve this through ceilometer alarm system.


--
Luo gangyiluogan...@chinamobile.com



 




--  --
??: ZhiQiang Fan;aji.zq...@gmail.com;
: 2015??4??29??(??) 12:23
??: OpenStack Development Mailing 
Listopenstack-dev@lists.openstack.org; 

: [openstack-dev] [ceilometer] time based auto scaling



Hi devs,

I'm thinking to add new type of alarm for time based auto scaling, but not sure 
if there is a better way to achieve it outside ceilometer scope


Currently we can auto scaling based on vm load, but it will take several 
minutes to do it. For the worst case, when the vm load is heavy, ceilometer 
needs 10 minutes (by default) to collect the performance data, and alarm need 1 
minutes to evaluate it, maybe there is evaluation_periods which set to higher 
that 1 to avoid performance peak. 


So even though we can collect data by 1 minutes, but evaluation periods may be 
set to 3, so the worst case is after vm load perfomance in high level for 4 
minutes, then the alarm is triggered, then heat will expand vm count, nova will 
take dozens seconds or more to create, finally the service on the in the heat 
server group will performance bad or unavailable for several minutes, which is 
not acceptable for some critical applications.


But if we can know some high load which related with time, for example, 08:00am 
will be a peak, and after 22:00pm will definitely drop to idel level, then heat 
can increase some vms at 07:30am, then decrease some vms at 22:00 (or decrease 
by load as normal routine)


However, current ceilometer only provide time constraint alarm, which will only 
evaluate but not guarantee it will be triggered. And heat cannot provide 
something like timer, but just can wait for the signal.



So I propose to add a new type of alarm, which will definitely send a signal to 
action when it is evaluated (with or without repeat, it will work well with 
time constraint)


Any suggestion?__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev