Open Stack

Oh, Sylvain, you were first :)

I have just small things to add here: Joe, resource usage planning is great
feature, that, I believe, is not supported in OS services now. Resource
planning will allow cloud providers to react on future picks of loads,
because they *will know* about that. As Zane said, otherwise you need to
spend much money keeping much extra capacity in common pool, or have real
risks to run out of resources.

Everything else was described by Sylvain, I guess :)

-- Dina


On Mon, Mar 3, 2014 at 10:13 PM, Sylvain Bauza <sylvain.bauza at gmail.com>wrote:

> Hi Joe,
>
>
> 2014-03-03 18:32 GMT+01:00 Joe Gordon <joe.gordon0 at gmail.com>:
>
>
>>
>> This sounds like something that belongs in nova, Phil Day has an
>> elegant solution for this:
>> https://blueprints.launchpad.net/nova/+spec/whole-host-allocation
>>
>>
> This blueprint has already been addressed by Climate team, and we
> discussed about this with Phil directly.
> This blueprint has been recently abandoned by its author and Phil is
> trying to focus on dedicated instances instead.
>
> As we identified this blueprint as non-supported yet, we implemented its
> logic directly within Climate. That said, don't confuse 2 different things
> :
>  - the locking process for isolating one compute node to a single tenant :
> that should be done in Nova
>  - the timetable for scheduling hosts and electing which ones are
> appropriate : that must be done in Climate (and in the future, should use
> Gantt as external scheduler for electing from a pool of available hosts on
> that timeframe)
>
> Don't let me say that the resource isolation must be done within Climate :
> I'm definitely conviced that this logic should be done on the resource
> project level (Nova, Cinder, Neutron) and Climate should use their
> respective CLI for asking isolation.
> The overall layer for defining what will available when, and what are the
> dependencies in between projects, still relies on a shared service, which
> is Climate.
>
>
>>
>> Heat?
>>
>> I spin up dev instances all the time and have never had this problem
>> in part because if I forget my quota will remind me.
>>
>>
> How do you ensure that you won't run out of resources when firing up an
> instance in 3 days ? How can you guaranttee that in the next couple of
> days, you would be able to create a volume with 50GB of space ?
>
> I'm not saying that the current Climate implementation does all the work.
> I'm just saying it's duty of Climate to look at Quality of Service aspects
> for resource allocation (or say SLA if you prefer)
>
>
>>
>> Why does he need to reserve them in the future? When he wants an
>> instance can't he just get one? As Sean said, what happens if someone
>> has no free quota when the reservation kicks in?
>>
>>
> That's the role of the resource plugin to manage capacity and ensure
> everything can be charged correctly.
> Regarding the virtual instances plugin logic, that's something that can be
> improved, but consider the thing that the instance is already created but
> not spawned when the lease is created, so that the quota is decreased from
> one.
>
> With the compute hosts plugin, we manage availability thanks to a resource
> planner, based on a fixed set of resources (enrolled compute hosts within
> Climate), so we can almost guaranttee this (minus the hosts outages we
> could get, of course)
>
>
>
>>
>> How is this different from 'nova boot?' When nova boot finishes the VM
>> is completely ready to be used
>>
>>
>
> Nova boot directly creates the VM when the command is issued, while the
> proposal here is to defer the booting itself only at the lease start (which
> can happen far later than when the lease is created)
>
>
>>
>> > - if you're reserving resources far before you'll need them, it'll be
>> > cheaper
>>
>> Why? How does this save a provider money?
>>
>>
> From a cloud operator point of view, don't you think it's way preferrable
> to get feedback for future capacity needs ?
> Don't you feel it would be interesting for him to propose a business model
> like this ?
>
>
>
>
>>
>> "Reserved Instances provide a capacity reservation so that you can
>> have confidence in your ability to launch the number of instances you
>> have reserved when you need them."
>> https://aws.amazon.com/ec2/purchasing-options/reserved-instances/
>>
>> Amazon does guarantee the resource will be available.  Amazon can
>> guarantee the resource because they can terminate spot instances at
>> will, but OpenStack doesn't have this concept today.
>>
>>
> That's why we think there is a need for guarantteing resource allocation
> within Openstack.
> Spot instances can be envisaged thanks to Climate as a formal contract for
> reserving resources that can be freed if needed.
>
> -Sylvain
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Best regards,

Dina Belova

Software Engineer

Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140303/247657a6/attachment.html>