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:
These fields are required and must be filled.
|Chargegroup||Which element will be managing the project. Chargegroups correspond to Experiments, Departments or even Functional Elements. This 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.|
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]
Network shared filesystem, more about it here.
Scalable storage service compatible with the Amazon S3. More about it here.
The CERN OpenStack environment provides virtual machines on the CERN networks (such as the GPN and OPN). More about it here.
Please note any specific requirements you may have.
- 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.