Open Stack

On Mon, Mar 3, 2014 at 10:13 AM, 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 have access to 2 public clouds that both would be very embarrassed
if they ran out of capacity, so they make sure that doesn't happen.

>
> 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)

I don't follow, how does climate make these guarantees?

>
>
>>
>>
>> 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)

Why can't I just run 'nova boot' when I want the lease to start.

>
>>
>>
>> > - 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 ?


Not really, the amazon model, where a reservation is long term makes
sense, but I don't see how short term reservations would help cloud
operators.

>
>
>
>>
>>
>> "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.

I like this idea, but something should be in Nova. Not sure how this
concept of spot instances works for other resource such as object or
volume storage.

>
> -Sylvain
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>