Open Stack

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.

- ZB