Open Stack

On Jul 10, 2014, at 9:21 AM, Zane Bitter <zbitter at redhat.com>
 wrote:

> On 10/07/14 05:34, Steven Hardy wrote:
>>>> > >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.
>>> >
>>> >While I agree that these examples are totally silly, I'm just trying to illustrate that we shouldn't deny an operator an option so long as its understood what that option entails from a technical/usage perspective.
>> I don't really get why this question is totally silly - I made a genuine
>> request for education based on near-zero knowledge of public cloud provider
>> pricing models.
> 
> The way I read it Randall was not saying that the question was silly, he was acknowledging that his own examples (like charging per-resource) were contrived (to the point of absurdity) to illustrate his argument.

Yes. I didn't mean to imply the questions or any of the responses were silly, only my contrived examples.