On 07/03/2014 10:13 PM, Mike Spreitzer wrote:
I do think the issue these address --- the need to get application logic
involved in, e.g., shutdown --- is most of what an application needs;
involvement in selection of which member(s) to delete is much less
important (provided that clean shutdown
Steven Hardy wrote on 07/02/2014 06:16:21 AM:
> On Wed, Jul 02, 2014 at 02:41:19AM +, Adrian Otto wrote:
> >Zane,
> >If you happen to have a link to this blueprint, could you replywith
it? ...
>
> I believe Zane was referring to:
>
> https://blueprints.launchpad.net/heat/+spec/updat
On 01/07/14 21:09, Mike Spreitzer wrote:
Zane Bitter wrote on 07/01/2014 07:05:15 PM:
> On 01/07/14 16:30, Mike Spreitzer wrote:
> > Thinking about my favorite use case for lifecycle plug points for cloud
> > providers (i.e., giving something a chance to make a holistic placement
> > decisi
On Wed, Jul 02, 2014 at 02:41:19AM +, Adrian Otto wrote:
>Zane,
>If you happen to have a link to this blueprint, could you reply with it? I
>took a look, but did not find it.
>I'd like to suggest that the implementation allow apps to call
>unauthenticated (signed) webhook UR
Zane,
If you happen to have a link to this blueprint, could you reply with it? I took
a look, but did not find it.
I’d like to suggest that the implementation allow apps to call unauthenticated
(signed) webhook URLs in order to trigger a scale up/down event within a
scaling group. This is abou
Zane Bitter wrote on 07/01/2014 07:05:15 PM:
> On 01/07/14 16:30, Mike Spreitzer wrote:
> > Thinking about my favorite use case for lifecycle plug points for
cloud
> > providers (i.e., giving something a chance to make a holistic
placement
> > decision), it occurs to me that one more is needed:
On 01/07/14 16:30, Mike Spreitzer wrote:
Thinking about my favorite use case for lifecycle plug points for cloud
providers (i.e., giving something a chance to make a holistic placement
decision), it occurs to me that one more is needed: a scale-down plug
point. A plugin for this point has a dist
