Open Stack

Hi!
Comments inline.

On 20/05/14 21:58, "Zane Bitter" <zbitter at redhat.com> wrote:

>On 20/05/14 12:17, Jay Pipes wrote:
>> Hi Zane, sorry for the delayed response. Comments inline.
>>
>> You are assuming a public cloud provider use case above. As much as I
>> tend to focus on the utility cloud model, where the incentives are
>> around maximizing the usage of physical hardware by packing in as many
>> paying tenants into a fixed resource, this is only one domain for
>> OpenStack.
>
>I was assuming the use case advanced in this thread, which sounded like
>a semi-public cloud model.
>
>However, I'm actually trying to argue from a higher level of abstraction
>here. In any situation where there are limited resources, optimal
>allocation of those resources will occur when the incentives of the
>suppliers and consumers of said resources are aligned, independently of
>whose definition of "optimal" you use. This applies equally to public
>clouds, private clouds, lemonade stands, and the proverbial two guys
>stranded on a desert island. In other words, it's an immutable property
>of economies, not anything specific to one use case.

This makes perfect sense. I¹d add one tiny bit though. ³Šoptimal of those
resource will *eventually* occurŠ².
For clouds, by rounding up to the nearest flavour you actually leave no
space for optimisation. Even for the lemonade stands you¹d first observe
what people prefer most before deciding on optimal allocation of water or
soda bottles :)

>
>> There are, for good or bad, IT shops and telcos that frankly are willing
>> to dump money into an inordinate amount of hardware -- and see that
>> hardware be inefficiently used -- in order to appease the demands of
>> their application customer tenants. The impulse of onboarding teams for
>> these private cloud systems is to "just say yes", with utter disregard
>> to the overall cost efficiency of the proposed customer use cases.

+1. I¹d also add to add support of legacy applications as another reason
for the "utter disregard²

>
>Fine, but what I'm saying is that you can just give the customer _more_
>than they really wanted (i.e. round up to the nearest flavour). You can
>charge them the same if you want - you can even decouple pricing from
>the flavour altogether if you want. But what you can't do is assume
>that, just because you gave the customer exactly what they needed and
>not one kilobyte more, you still get to use/sell the excess capacity you
>didn't allocate to them. Because you may not.

Like I said above, if you round up you most definitely don¹t get to use
the excess capacity.
Also, where exactly would you place this rounding up functionality? Heat?
Nova? A custom script that runs before deployment? Assume the tenant
doesn¹t know what flavours are available, because template creation is
done automatically outside of the cloud environment.

>
>> If there was a simple switching mechanism that allowed a deployer to
>> turn on or off this ability to allow tenants to construct specialized
>> instance type configurations, then who really loses here? Public or
>> utility cloud providers would simply leave the switch to its default of
>> "off" and folks who wanted to provide this functionality to their users
>> could provide it. Of course, there are clear caveats around lack of
>> portability to other clouds -- but let's face it, cross-cloud
>> portability has other challenges beyond this particular point ;)
>>
>>> The insight of flavours, which is fundamental to the whole concept of
>>> IaaS, is that users must pay the *opportunity cost* of their resource
>>> usage. If you allow users to opt, at their own convenience, to pay only
>>> the actual cost of the resources they use regardless of the opportunity
>>> cost to you, then your incentives are no longer aligned with your
>>> customers.
>>
>> Again, the above assumes a utility cloud model. Sadly, that isn't the
>> only cloud model.
>
>______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-
Dimitri