Skip to content

Requesting projects

Projects are intended to group related virtual machines into a single set with shared administrators and quota. This provides an alternative to the per-machine hardware/VM request form and grants the right to use a set of virtual resources up to a quota limit.

Each user who subscribes to the cloud service is given a personal project. Personal projects are good for sandboxes to test ideas or virtual desktops (such as needing multiple different linux environments to try out different software but with a Mac laptop as a client)

A project would generally correspond to a particular service such as CMS Frontier or IT Twiki.

Using department group names such as IT OIS is to be avoided as re-organisations lead to out of date names and incorrect role assignments. Thus, staying with a small grain functional area is better than large scale projects for a particular department or group.

If you need a new project, please click the Request New Project on the OpenStack Project Overview page and fill this form:

Request new project

General

These fields are required and must be filled.

Field Description
Experiment or department Which organisation will be managing the project. This also determines the appropriate usage and utilisation tracking
Name of the project The name describing the project. Example: "LHC File Catalog development"
Description Brief (one or two lines) description of the project
Owner (primary account) The primary account name of the person owning this project.

Note: this account should already exist in the Cloud Infrastructure service.
Administrator E-group(s) The e-group of accounts which will be members of the project. Using an e-group is recommended since it allows additional members to be added without requiring further service tickets. These people will be able to create/delete/start/stop virtual machines for the shared project. The membership can be adjusted afterwards through the Resources Portal. You can specify several groups separated by commas
Set group as default responsible in landb This setting gets the first group of the administrator egroup and sets it as the project landb-responsible property. Machines created in the project will use this value instead of the user creating it when the property landb-responsible is not specified as instance metadata.
Set group as default mainuser in landb This setting gets the first group of the administrator egroup and sets it as the project landb-mainuser property. Machines created in the project will use this value instead of the user creating it when the property landb-responsible is not specified as instance metadata.

Compute

Requested resources. In general, a ratio of 1 core to 2GB of RAM corresponds to the flavors of VMs which are available. Required.

  • number of virtual machines
  • number of cores
  • amount of memory [GB]

Volumes

Attached disk volumes for the project. By default, these volumes are provided with standard storage type. Note that these volumes could be used to boot operating systems.

Shares

Network shared filesystem, more about it here.

Object Store

Scalable storage service compatible with the Amazon S3. More about it here.

Network

The CERN OpenStack environment provides virtual machines on the CERN networks (such as the GPN and OPN). More about it here.

Additional comments

Please note any specific requirements you may have.


Please note:

  • As part of the request work flow, projects will be reviewed by the IT resource co-ordinators.
  • Request for resources from users of the LHC experiments will also be vetted by the experiments themselves. Experiment resource coordinators are added to the watchlists of the resource requests.
  • In addition, some LHC experiments have their internal workflows for OpenStack resource requests. In particular:
  • ATLAS resource requests are described in the (ATLAS-only) Compute Resources Twiki page.
  • CMS resource requests are described in the Wiki page for Cloud Shared projects for CMS.

As described in upcoming enhancements, there will be a method to group projects together into domains which will be defined at the experiment level. Thus, smaller projects are recommended so this implementation can be made when the function is available.