Open Stack

On 04/01/2017 08:32 PM, Joe Topjian wrote:
> On Sat, Apr 1, 2017 at 5:21 PM, Matt Riedemann <mriedemos at gmail.com
> <mailto:mriedemos at 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