Resource reservation is one of the key requirements OPNFV is driving for Telco NFV usecases. Today it is staged within "Promise" project as a shim layer, but the intention is to get a native support through OpenStack core services like nova, neutron, cinder. Here are some urls where the requirements are captured very well: Requirement document: http://artifacts.opnfv.org/promise/docs/requirements/requirements.pdf Website: https://github.com/opnfv/promise
There are some traction in the community in this area, specifically reignite blazar and/or drive low-level requirements at individual service level. Regards~Hrushi -----Original Message----- From: Jonathan D. Proulx [mailto:j...@csail.mit.edu] Sent: Wednesday, August 03, 2016 12:22 PM To: Tim Bell <tim.b...@cern.ch> Cc: openstack-operators@lists.openstack.org Subject: Re: [Openstack-operators] Blazar? (Reservations and/or scheduled termination) On Wed, Aug 03, 2016 at 05:23:23PM +0000, Tim Bell wrote: : :When I last looked, Blazar allows you to reserve instances for a given time. An example would be : :- We are organizing a user training session for 100 physicists from Monday to Friday :- We need that each user is able to create 2 VMs within a single shared project (as the images etc. are set up before) :- OpenStack should ensure that these resources would be available (or reject the request) and schedule other Blazar requests around it : :This does need other functionality though which is currently not there : :- Spot instances, i.e. give me the resources if they are available but kill when you have a reservation. Alvaro is proposing a talk for some work done in Indigo Datacloud project for this at the summit (votes welcome). :- Impending shutdown notification .. save what you want quickly because you’re going to be deleted I hadn't looked in ages (untill today) and that does seem to be both what I remember and what seems to be current best I can tell (still hoping someone will correct me and tell me I'm just looking in the worng place, but...) :We have a use case where we offer each user a quota of 2 VMs for ‘Personal’ use. This gives a good onboarding experience but the problem is that our users forget they asked for resources. Something where we can define a default lifetime for a VM (ideally, a project) and users need to positively confirm they want to extend the lifetime would help identify these forgotten VMs. We have similar onboarding user sandboxes, it would be nice to auto limit lives there. My current pain seems to come from peopel who've setup virtual clusters and then not taken them down. Not sure it they've forgotten or if they're squatting to ensure they have resources later. :I think a good first step would be : :- An agreed metadata structure for a VM with an expiry date :- An agreed project metadata giving the default length of the VM :- An OSops script which finds those VMs exceeding the agreed period and goes through a ‘suspend’ for N days followed by a delete M days afterwards (to catch the accidents) :I think this can be done in Nova as is if this is not felt to be a ‘standard’ function but we should agree on the names/concepts. Kris (above) seems to have rigged up a similar system using Jenkins. I'd prefer not to drag in yet another thing since I'm not running Jenkins (yet?), but conceptually the metadata path seems resonable to me. :Some of the needs are covered in https://openstack-in-production.blogspot.fr/2016/04/resource-management-at-cern.html Ah yes, I was at the Summit session you reference there. Reminds me I do need to get mroe involved with Scientific Working Group (at least enough to follow the ongoing discussions) Thanks, -Jon : :Tim : : :On 03/08/16 18:47, "Jonathan D. Proulx" <j...@csail.mit.edu> wrote: : : Hi All, : : As a private cloud operatior who doesn't charge internal users, I'd : really like a way to force users to set an exiration time on their : instances so if they forget about them they go away. : : I'd though Blazar was the thing to look at and Chameleoncloud.org : seems to be using it (any of you around here?) but it also doesn't : look like it's seen substantive work in a long time. : : Anyone have operational exprience with blazar to share or other : solutions? : : -Jon : : _______________________________________________ : OpenStack-operators mailing list : OpenStack-operators@lists.openstack.org : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators : : _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
