On Jul 10, 2014, at 9:21 AM, Zane Bitter <zbit...@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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
