<div dir="ltr">Oh, Sylvain, you were first :)<div><br></div><div>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.</div>
<div><br></div><div>Everything else was described by Sylvain, I guess :)</div><div><br></div><div>-- Dina</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 3, 2014 at 10:13 PM, Sylvain Bauza <span dir="ltr"><<a href="mailto:sylvain.bauza@gmail.com" target="_blank">sylvain.bauza@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Joe,<div class="gmail_extra"><br><br><div class="gmail_quote">2014-03-03 18:32 GMT+01:00 Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></span>:<div class="">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br>
<br>
</div></div>This sounds like something that belongs in nova, Phil Day has an<br>
elegant solution for this:<br>
<a href="https://blueprints.launchpad.net/nova/+spec/whole-host-allocation" target="_blank">https://blueprints.launchpad.net/nova/+spec/whole-host-allocation</a><br>
<div><br></div></blockquote><div><br></div></div><div>This blueprint has already been addressed by Climate team, and we discussed about this with Phil directly.</div><div>This blueprint has been recently abandoned by its author and Phil is trying to focus on dedicated instances instead.</div>
<div><br></div><div>As we identified this blueprint as non-supported yet, we implemented its logic directly within Climate. That said, don't confuse 2 different things : </div><div> - the locking process for isolating one compute node to a single tenant : that should be done in Nova</div>
<div> - 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)</div>
<div><br></div><div>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.</div>
<div>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.</div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
</div>Heat?<br>
<br>
I spin up dev instances all the time and have never had this problem<br>
in part because if I forget my quota will remind me.<br>
<div><br></div></blockquote><div><br></div></div><div>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 ?</div>
<div><br></div><div>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)</div>
<div class="">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
</div>Why does he need to reserve them in the future? When he wants an<br>
instance can't he just get one? As Sean said, what happens if someone<br>
has no free quota when the reservation kicks in?<br>
<div><br></div></blockquote><div><br></div></div><div>That's the role of the resource plugin to manage capacity and ensure everything can be charged correctly.</div><div>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.</div>
<div><br></div><div>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)</div>
<div class="">
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
</div>How is this different from 'nova boot?' When nova boot finishes the VM<br>
<div>is completely ready to be used<br>
<br></div></blockquote><div><br></div><div><br></div></div><div>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)</div>
<div class="">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
> - if you're reserving resources far before you'll need them, it'll be<br>
> cheaper<br>
<br>
</div>Why? How does this save a provider money?<br>
<div><br></div></blockquote><div><br></div></div><div>From a cloud operator point of view, don't you think it's way preferrable to get feedback for future capacity needs ?</div><div>Don't you feel it would be interesting for him to propose a business model like this ?</div>
<div class="">
<div> </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
</div>"Reserved Instances provide a capacity reservation so that you can<br>
have confidence in your ability to launch the number of instances you<br>
have reserved when you need them."<br>
<a href="https://aws.amazon.com/ec2/purchasing-options/reserved-instances/" target="_blank">https://aws.amazon.com/ec2/purchasing-options/reserved-instances/</a><br>
<br>
Amazon does guarantee the resource will be available. Amazon can<br>
guarantee the resource because they can terminate spot instances at<br>
will, but OpenStack doesn't have this concept today.<br>
<div><div><br></div></div></blockquote><div><br></div></div><div>That's why we think there is a need for guarantteing resource allocation within Openstack.</div><div>Spot instances can be envisaged thanks to Climate as a formal contract for reserving resources that can be freed if needed.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>-Sylvain</div></font></span></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><p style="font-size:small;margin:0px;font-family:Helvetica">
Best regards,</p><p style="font-size:small;margin:0px;font-family:Helvetica">Dina Belova</p><p style="font-size:small;margin:0px;font-family:Helvetica">Software Engineer</p><p style="font-size:small;margin:0px;font-family:Helvetica">
Mirantis Inc.</p></div></div>
</div>