Excerpts from Randall Burt's message of 2014-07-09 15:33:26 -0700: > On Jul 9, 2014, at 4:38 PM, Zane Bitter <zbit...@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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev