Cafe

Cafe

Current Team
The project is led by the Cyber Security Lab in the University of Waikato, New Zealand. We welcome interested, like-minded volunteer software developers to embark on this journey to make OpenStack resources manageable from a time-based and user-centric perspective.

Members from the Cyber Security Lab, University of Waikato, New Zealand (https://crow.org.nz):

Ryan Ko, Alan Tan, Grace Ng, Brad Cowie

Contacts: Alan Tan (yst1@waikato.ac.nz), Ryan Ko (ryan@waikato.ac.nz)

GitHub link: https://github.com/CROWLaboratory/OpenstackCafe

Summary
Café is a time-based resource booking system for OpenStack clouds. As it is time-based, booked resources can be relinquished back to the cloud resource pool after the booked time is up. Café is designed for cloud environments such as clouds for educational purposes, research clouds available for lease, and private clouds with a large number of users. Some of the features of Café include:


 * Simplified graphical interface for monitoring usage of cloud resources for a large group of users through a timetable-like view of resource bookings and allocations for a specific time/date.
 * Ability to allow administrators to plan and understand the current utility of hardware and identify the need for future expansions.
 * Time-slot based cloud resource management. Allow users (e.g. students) to plan when they want to use the resources. This also helps to avoid the problem of block bookings and hence increase utility of hardware resources.
 * Warning alerts for users when the booked session is about to end.
 * Enables administrators to optimise up/down time of resources in order to achieve energy optimisation with respect to performance of vms and customer requests.

Rationale
The rationale behind project Café, is to complement OpenStack from the aspect of user-centric resource management. As a cloud resource management software, OpenStack is expected to cater to a large amount of users, while maintaining elastic and reliable access to the resources managed by OpenStack. Hence, we intend Café to fill in the following roles in the OpenStack ecosystem:
 * Automatic control of the resources each user has access to (both from the time and resource amount perspective).
 * Automated resource management (enable/relinquish user’s access to resources based on contextually identified needs).
 * A time-based resource management scheme to prevent resource hogging by users and to facilitate the planning of resource utilisation by the administrators.

How Café Works

 * 1) User signs up for a new account through the dashboard (Horizon).
 * 2) Administrator approves the new account and undertakes the following for each user (through the Café interface – Waiter).

a. Assigns the user to a new or existing project as appropriate which creates an OpenStack account for the user. b. Allocates a resource quota to the user which will form the resource amount for each of the user’s bookings – the resource quota is able to be selected by the user in the “create account” form from a list of administrator-created quota templates. c. Automatic user account creation through Waiter. d. Email notification sent to user.
 * 1) Users access Café’s interface (Waiter) and books the desired timeslots for access to resources by submitting a request and providing the following details:

a. Start time. b. End time. c. Whether the booking needs to occur regularly i.e. at the same time every week or every month.
 * 1) Administrator receives request on Waiter and approves/rejects request through Barista.

a. Allow comments from administrators on why request was rejected. b. Email notification of decision sent.
 * 1) At the start of the session, the booking manager service (Manager) will enable user access to virtual resources.
 * 2) Towards the end of the session, the system will prompt users on their VMs that their session is about to end soon. This prompt will occur either on the web interface or the VMs or both.
 * 3) At end of the session the Manager will remove/disable the user’s rights to access virtual resources.
 * 4) Manager will automatically suspend all user resources currently being used in order to free up the resources.

Design
Overall view of how Café interacts with an existing OpenStack setup:

Interaction for user account creation:

Interaction for resource management (ranges from user request to automatic resource booking enforcement):



Complementary notes:


 * Café’s interface (Waiter) will use Openstack API to communicate with:
 * Keystone:
 * Mass-create approved new user accounts.
 * Nova
 * Manage quota templates for each user. (Create and assign) [per-user quota feature is enabled in the Havana release]
 * Resource booking page
 * Tied to project tab so project and user details are automatically filled in for the booking.
 * User account creation requests
 * Controls in place such as requiring a unique organisation email domain name to prevent malicious mass-creation of user accounts
 * Administrative interface
 * Allow for mass approval of booking requests based on various filters (e.g. all requests with the project prefix “abc” at 1pm on the 27th January)
 * Booking manager service (Manager)
 * Utilise existing Nova API for enabling and relinquishing resource control to/from users when session starts and ends.

To-Do List
The following are the planned list of components, component names and features for Café: Most of Waiter’s functionality should utilise either the existing OpenStack APIs or Café’s resource API (Barista). As such, most of the implementation for Waiter focuses on the front end. Another possibility will be to integrate the interfaces into Horizon.
 * Booking manager service (Manager)
 * Add/remove user access to virtual resources at start and end of approved sessions.
 * Periodic checking of the booking database for session management.
 * Prompt users that their session is ending either via web or VM interfaces.
 * Relinquish resources from users at end of session. (Possibly through Nova’s API).
 * Café Resource API (Barista) (to separate out service functions into an API)
 * Update and retrieve user bookings from booking databases.
 * User resource request approval and rejection.
 * Calculate projected resource usage (see potential features for discussion).
 * Interface with existing components of Horizon to prevent unauthorised access to virtual resources by users, outside of their approved session times.
 * Café Interface (Waiter)
 * [Admin panel] Quota template creation page so that administrators can create new quota templates.
 * [Admin panel] View/Edit existing Quota templates.
 * [Admin panel] User account approval / rejection interface.
 * [Admin panel] User resource request approval / rejection interface.
 * [Admin panel] Retrieve booking overviews for specified dates and time.
 * [User panel] Resource booking page. Displays a timetable-like interface where users can view available timeslots for particular dates and select their bookings through an interactive booking interface.
 * [User panel] View own bookings.
 * [User panel] Modify existing bookings.

Current Prototype Implementation
A prototype has been implemented as a proof of concept as of 15th Oct 2013.

The current prototype utilises existing features and functionalities found in the Grizzly release. Below are some of the key differences with the plan laid down in this blueprint documentation so far.


 * Parts of the Café interface are designed as tabs in Horizon (user resource bookings, user modification of bookings, user viewing of own bookings, resource request approval for administrators), while other parts (user account creation, retrieval of bookings) are implemented as separate interfaces. While this works, our intent is to provide a unified user experience, hence the intent is to explore possibilities in having tighter integration with existing Openstack projects such as Horizon.
 * Current prototype lacks the feature to email users informing them of the decision made by the administrators regarding their requests.
 * Current way of informing users that their session is approaching the end is through the use of the “wall” command in Linux OS environment. While this works, it severely limits the guest OS that can be used on virtual machines. It might also pose potential security issues due to the way the commands are being issued.
 * In the prototype, user’s access to virtual resources at start / end of session are granted/removed via the use of roles and user access-list maintained by nova. This brings about the disadvantage of users having to logout and log back into their dashboards as they are unable to continue with their current Horizon session after roles have been added or removed. The use of roles to control user access to resources also brings about certain loop holes in enforcing a user’s access to virtual resources, especially when session is about to end.
 * User account creation is broken up into multiple stages and requires manual intervention.
 * Security features are not considered yet in the prototype.
 * Current prototype only implements the control of resources for VMs. That is to say, control of other resources such as storage are not being implemented in the prototype. The idea is that the full fledged Café implementation should cover those virtual resources too.

Potential Features for Discussion
There are various avenues for future work stemming from this testbed.
 * Extending Café to include the implementation of automated resource planning and scheduling for the testbed. This would allow for the automatic approval of user access requests and improve the efficiency with which testbed resources are being used particularly where a weighting system is used for the priority level of a user access request. Such a system would have to handle the delicate balance between approving high-priority and low-priority requests so that the testbed is still usable by the user group as a whole.
 * Integrate administrative view of percentage of resources that have already been “allocated” for a certain period of time. This will give administrators a better view of the utilisation rate of resources, with respect to the requested time slot. Barista can also be extended to include the projected resource allocation for the relevant time periods if the selected user requests are approved. This will give the administrator a better idea of what the end result of their approval decision is.
 * Another avenue for future work on the testbed includes the implementation of a credits system where users have a set amount of credits and must spend them accordingly in order to secure access to testbed resources for a certain period of time. Different times of the day may be assigned different purchase prices. This may be particularly helpful for the most popular testbed booking times so that users must sacrifice a higher proportion of their booking power in order to book during peak times. Assigning a link between the purchase price and the number of resources requested may also increase the efficiency with which testbed resources are used as users would then be encouraged to only book the amount of resources they need. Such a system would require substantial thought into design considerations including the associated market-like implications that such a system would create. For example, would all users be given the same number of credits for every semester? How would the total amount of credits allocated to the user group be controlled accordingly? Would users be able to earn credits? How would this affect the purchasing power within the user group and would it create an unfair purchasing power imbalance within the user group? These questions and more would have to be considered when designing a credits-based resource access system for the testbed.
 * A fourth avenue would be investigating how suspension of instances at the end of each booked session affects users who are running a process at the time of instance suspension. This is particularly important for users who are using the testbed to conduct research experiments. A brief investigation was conducted using a python script that prints out the time every second. The suspension and resuming of the instance on which the script was running shows that the time is no longer accurate after the resuming of the instance as the time suspended is not taken into account. This issue is one of many that can be investigated and accounted for in future work on the testbed.