Open Stack

Excerpts from Randall Burt's message of 2014-07-09 15:33:26 -0700:
> On Jul 9, 2014, at 4:38 PM, Zane Bitter <zbitter at redhat.com>
>  wrote:
> > On 08/07/14 17:17, Steven Hardy wrote:
> > 
> >> Regarding forcing deployers to make a one-time decision, I have a question
> >> re cost (money and performance) of the Swift approach vs just hitting the
> >> Heat API
> >> 
> >> - If folks use the Swift resource and it stores data associated with the
> >>   signal in Swift, does that incurr cost to the user in a public cloud
> >>   scenario?
> > 
> > Good question. I believe the way WaitConditions work in AWS is that it sets up a pre-signed URL in a bucket owned by CloudFormation. If we went with that approach we would probably want some sort of quota, I imagine.
> 
> Just to clarify, you suggest that the swift-based signal mechanism use containers that Heat owns rather than ones owned by the user?
> 

+1, don't hide it.

> > The other approach is to set up a new container, owned by the user, every time. In that case, a provider selecting this implementation would need to make it clear to customers if they would be billed for a WaitCondition resource. I'd prefer to avoid this scenario though (regardless of the plug-point).
> 
> Why? If we won't let the user choose, then why wouldn't we let the provider make this choice? I don't think its wise of us to make decisions based on what a theoretical operator may theoretically do. If the same theoretical provider were to also charge users to create a trust, would we then be concerned about that implementation as well? What if said provider decides charges the user per resource in a stack regardless of what they are? Having Heat own the container(s) as suggested above doesn't preclude that operator from charging the stack owner for those either.
>

This is a nice use case for preview. A user should be able to preview a
stack and know what will be consumed. Wait conditions will show a swift
container if preview is worth anything.