Welcome to Pebbles’s documentation!¶
Pebbles is a tool developed at CSC for simple provisioning of resources. Pebbles is the name of the open source project and the installations should individual names. The name of the installation at CSC for example will be called CSC Notebooks.
Pebbles overview¶
Pebbles is about provisioning cloud resources with a simple end-user experience. Currently supported provisioning back-end is OpenStack. It’s possible to provision either full Virtual Machines or merely Docker containers from a pool of hosts that Pebbles maintains.
Virtual machines can and typically do have their own IP address and for containers a port can be forwarded for communication with software running on the container. Jupyter Notebooks or RStudio Server are good candidates for inside a container.
Note
Currently no authentication is done when accessing a container via a forwarded URL. Anyone who knows the URL for a notebook can access it, the connection is not authenticated. This is something to keep in mind as it has security implications. Scanning for all possible URLs may be difficult but in the current implementation confidentiality of data in notebooks is not guaranteed. The upside is that many parties can access the same container if the URL is shared.
- The resources are abstracted on two levels as Bluperint Templates and Blueprints:
- Blueprint templates are created by system administrators who maintain the system.
- Blueprints can be created based on an existing Blueprint templates by users with elevated but non-administrator rights. Regular users can then provision and access resources based on these blueprints.
The purpose of this divide is to let system administrators create types of resource packages with limited freedom to modify the parameters delegated to lower level elevated priviledge users.
Note
All disk storage in Pebbles is more or less ephemeral. You are responsible for your data persistence!
User Types in Pebbles¶
There are broadly four roles in a Pebbles instance:
- Admin - Which is supposed to be the superuser of the system. Ability to
- invite new users, appoint group owners, create blueprint templates, blueprints, system and normal groups. System level priviledges : Access to the backend database, restart or delete running services.
- Group Owner - Ability to create groups, appoint group managers , create
- blueprints and manage instances running in a group
- Group Manager - Ability to create blueprints and manage instances
- running in a group
- User - Able to launch instances if belonging to a group with
- blueprints.
A group owner is typically associated with costs tracking, e.g. a professor or researcher. The group owner can create groups and promote other users to be group managers to run basic day-to-day tasks.
Use Cases¶
The current main use cases revolve around setting up simple environments for teaching and/or ad-hoc data analysis.
Notebooks in containers¶
See pb for a live example.
- User navigates to page
- User logs in with SSO they already know
- User selects appropriate blueprint and clicks a button
- System provisions a Docker container from an image
- System starts Jupyter/RStudio/similar inside container and forwards a port
- User can access the HTML UI from his own browser
Group owner documentation¶
Documentation relevant to group owners and managers is gathered under Group Owner’s Guide
Administrators and Developers¶
Documentation relevant to system administrators and developers is under Admin guide