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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
