<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 3, 2017 at 8:20 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 04/01/2017 08:32 PM, Joe Topjian wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Sat, Apr 1, 2017 at 5:21 PM, Matt Riedemann <<a href="mailto:mriedemos@gmail.com" target="_blank">mriedemos@gmail.com</a><br></span><div><div class="h5">
<mailto:<a href="mailto:mriedemos@gmail.com" target="_blank">mriedemos@gmail.com</a>>> wrote:<br>
<br>
On 4/1/2017 8:36 AM, Blair Bethwaite wrote:<br>
<br>
Hi all,<br>
<br>
The below was suggested for a Forum session but we don't yet have a<br>
submission or name to chair/moderate. I, for one, would certainly be<br>
interested in providing input. Do we have any owners out there?<br>
<br>
Resource reservation requirements:<br>
==<br>
The Blazar project [<a href="https://wiki.openstack.org/wiki/Blazar" rel="noreferrer" target="_blank">https://wiki.openstack.org/wi<wbr>ki/Blazar</a><br>
<<a href="https://wiki.openstack.org/wiki/Blazar" rel="noreferrer" target="_blank">https://wiki.openstack.org/wi<wbr>ki/Blazar</a>>] has been<br>
revived following Barcelona and will soon release a new version. Now<br>
is a good time to get involved and share requirements with the<br>
community. Our development priorities are described through<br>
Blueprints<br>
on Launchpad: <a href="https://blueprints.launchpad.net/blazar" rel="noreferrer" target="_blank">https://blueprints.launchpad.n<wbr>et/blazar</a><br>
<<a href="https://blueprints.launchpad.net/blazar" rel="noreferrer" target="_blank">https://blueprints.launchpad.<wbr>net/blazar</a>><br>
<br>
In particular, support for pre-emptible instances could be combined<br>
with resource reservation to maximize utilization on unreserved<br>
resources.+1<br>
<br>
<br>
Regarding resource reservation, please see this older Nova spec<br>
which is related:<br>
<br>
<a href="https://review.openstack.org/#/c/389216/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/389216/</a><br>
<<a href="https://review.openstack.org/#/c/389216/" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>#/c/389216/</a>><br>
<br>
And see the points that Jay Pipes makes in that review. Before<br>
spending a lot of time reviving the project, I'd encourage people to<br>
read and digest the points made in that review and if there<br>
responses or other use cases then let's discuss them *before*<br>
bringing a service back from the dead and assume it will be<br>
integrated into the other projects.<br>
<br>
This is appreciated. I'll describe the way I've seen Blazar used and I<br>
believe it's quite different than the above slot reservation as well as<br>
spot instance support, but please let me know if I am incorrect or if<br>
there have been other discussions about this use-case elsewhere:<br>
<br>
A research group has a finite amount of specialized hardware and there<br>
are more people wanting to use this hardware than what's currently<br>
available. Let's use high performance GPUs as an example. The group is<br>
OK with publishing the amount of hardware they have available (normally<br>
this is hidden as best as possible). By doing this, a researcher can use<br>
Blazar as sort of a community calendar, see that there are 3 GPU nodes<br>
available for the week of April 3, and reserve them for that time period.<br>
</div></div></blockquote>
<br>
Yeah, I totally understand this use case.<br>
<br>
However, implementing the above in any useful fashion requires that Blazar be placed *above* Nova and essentially that the cloud operator turns off access to Nova's POST /servers API call for regular users. Because if not, the information that Blazar acts upon can be simply circumvented by any user at any time.<br>
<br>
In other words, your "3 GPU nodes available for the week of April 3" can change at any time by a user that goes and launches instances that consumes those 3 GPU nodes.<br>
<br>
If you have a certain type of OpenStack deployment that isn't multi-user and where the only thing that launches instances is an automation/orchestration tool (in other words, an NFV MANO system), the reservation concepts works great -- because you don't have pesky users that can sidestep the system and actually launch instances that would impact reserved consumables.<br>
<br>
However, if you *do* have normal users of your cloud -- as most scientific deployments must have -- then I'm afraid the only way to make this work is to have users *only* use the Blazar API to reserve instances and essentially shut off the normal Nova POST /servers API.<br>
<br>
Does that make sense?<br></blockquote><div><br></div><div>Ah, yes, indeed it does. Thanks, Jay.</div></div></div></div>