Open Stack

Ceilometer mixes notifications and pollsters, so instance sample cannot
represents how many instances (sample-list nor statistics),
when we specify a time range in API query, the count of samples is not
precise to real situation, it is ether less (due to potential lag when time
range is precise) or more (due to redundant when time range has been
extended a bit to avoid lag)

IMHO, count of resource should be queried from specific service's API

On Tue, Oct 28, 2014 at 12:00 AM, Clint Byrum <clint at fewbar.com> wrote:

> Excerpts from Daniel Comnea's message of 2014-10-27 04:16:32 -0700:
> > Yes i did but if you look at this example
> >
> >
> https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml
> >
> >
> > the flow is simple:
> >
> > CPU alarm in Ceilometer triggers the "type: OS::Heat::ScalingPolicy"
> which
> > then triggers the "type: OS::Heat::AutoScalingGroup"
> >
> >
> >
> > Now what i want is to be able to always maintain a min number of
> instances
> > in my Group, if is min_size been reached than trigger HEAT to spun a new
> > one to be min_size + n
> >
>
> Sounds like you're expecting Heat to respond to the stop/delete of one
> of the instances in the group.
>
> It doesn't do that.. yet. There's a very large scale effort under way
> called 'convergence' that will add such a capability to Heat (by having
> Heat try to assert that reality should match intention). Until then it
> doesn't support this use case very well.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
blog: zqfan.github.com
git: github.com/zqfan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141028/f395b209/attachment.html>