Synnefo

projects. Due to the central role that projects now acquire, we will alter

the project schema to facilitate project creation and modification without

the extra overhead of submitting and approving applications.

Private projects

----------------

Since the introduction of base projects will explode the number of total

projects, we will need to control their visibility. We add a new flag

*private* in project definitions. A private project can only be accessed by

its owner and members and not be advertized in the UI. Base projects are

marked as private.

Decouple projects from applications

-----------------------------------

Base projects do not fit well in the current project/application scheme,

because no user has applied for them. Moveover, we would like to easily

modify project properties, particularly quota limits, without the need to

apply for an application for each project and then approve it.

We will decouple projects from applications by incorporating the project

definition into the project object rather than relying on an application.

The system will directly make a new (base) project upon user creation and a

privileged user will be able to modify an existing project by directly

modifying it. An unprivileged user will still need to make an application.

The project model is adapted to reference the *last* application that is

related to the project, if any---projects automatically created by the

system reference no application. For an uninitialized project, this

denotes the original application through which the project was made. If

the application is denied or cancelled, the whole project is considered

deleted.

Applications as modifications

`````````````````````````````

Application for a new project is created in state ``pending`` and its

properties are copied into a new project object, which is in state

``uninitialized``. To preserve this equality, we disallow modifications of

uninitialized projects, either in-place or through an application. An

already activated project can be modified by submitting an application

containing just the desired changes. An application object stores the

specified changes and should remain read-only.

System default quota and resource registration

----------------------------------------------

When a project is activated, either directly in the case of base projects

or through the approval of a project application, limits for resources not

specified are automatically completed by consulting the appropriate

skeleton.

way: it will always be charged at the user's base project.

API changes

-----------

``GET /service_project_quotas`` will be used in a similar way as ``GET

/service_quotas`` to get the project-level quotas for resources associated

with the Synnefo component that makes the request.

Changes in the projects API

```````````````````````````

``PUT /projects`` will be used to make a new project replacing ``POST``.

``POST /projects/<proj_id>`` now expects a dictionary with just the desired

changes, not a complete project definition. It is only allowed if the

project is already activated.

``GET /projects/<proj_id>`` changes to include a ``last_application`` field,

if applicable.

Application actions (approve, deny, dismiss, cancel) are integrated into

project actions and expect an extra ``app_id`` argument to specify the

application. Actions are allowed only on a project's last application;

the application id is required in order to avoid races.

The applications API is removed, incorporated into the projects API.

A new command ``snf-manage project-modify`` will enable in-place

modification of project properties, such as their quota limits.

``project-modify`` will get options ``--all-base-projects`` to

allow updating base quota in bulk.