On Mon, Apr 3, 2017 at 8:20 AM, Jay Pipes <[email protected]> wrote:
> On 04/01/2017 08:32 PM, Joe Topjian wrote: > >> On Sat, Apr 1, 2017 at 5:21 PM, Matt Riedemann <[email protected] >> <mailto:[email protected]>> 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? > Ah, yes, indeed it does. Thanks, Jay.
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
