On 04/01/2017 08:32 PM, Joe Topjian wrote:
On Sat, Apr 1, 2017 at 5:21 PM, Matt Riedemann <mriede...@gmail.com
<mailto:mriede...@gmail.com>> wrote:
On 4/1/2017 8:36 AM, Blair Bethwaite wrote:
Hi all,
The below was suggested for a Forum session but we don't yet have a
submission or name to chair/moderate. I, for one, would certainly be
interested in providing input. Do we have any owners out there?
Resource reservation requirements:
==
The Blazar project [https://wiki.openstack.org/wiki/Blazar
<https://wiki.openstack.org/wiki/Blazar>] has been
revived following Barcelona and will soon release a new version. Now
is a good time to get involved and share requirements with the
community. Our development priorities are described through
Blueprints
on Launchpad: https://blueprints.launchpad.net/blazar
<https://blueprints.launchpad.net/blazar>
In particular, support for pre-emptible instances could be combined
with resource reservation to maximize utilization on unreserved
resources.+1
Regarding resource reservation, please see this older Nova spec
which is related:
https://review.openstack.org/#/c/389216/
<https://review.openstack.org/#/c/389216/>
And see the points that Jay Pipes makes in that review. Before
spending a lot of time reviving the project, I'd encourage people to
read and digest the points made in that review and if there
responses or other use cases then let's discuss them *before*
bringing a service back from the dead and assume it will be
integrated into the other projects.
This is appreciated. I'll describe the way I've seen Blazar used and I
believe it's quite different than the above slot reservation as well as
spot instance support, but please let me know if I am incorrect or if
there have been other discussions about this use-case elsewhere:
A research group has a finite amount of specialized hardware and there
are more people wanting to use this hardware than what's currently
available. Let's use high performance GPUs as an example. The group is
OK with publishing the amount of hardware they have available (normally
this is hidden as best as possible). By doing this, a researcher can use
Blazar as sort of a community calendar, see that there are 3 GPU nodes
available for the week of April 3, and reserve them for that time period.
Yeah, I totally understand this use case.
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.
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.
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.
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.
Does that make sense?
Best,
-jay
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
