Revision 4398adc9 docs/design/resource-pool-projects.rst

b/docs/design/resource-pool-projects.rst
41 41

  
42 42
Projects will be the sole source of resources. Current base quota offered to
43 43
users by the system will be expressed in terms of special-purpose *base*
44
projects.
44
projects. Due to the central role that projects now acquire, we will alter
45
the project schema to facilitate project creation and modification without
46
the extra overhead of submitting and approving applications.
45 47

  
46 48
Implementation details
47 49
======================
......
120 122
  cyclades.vm   project:uuid   None           5       1
121 123
  cyclades.vm   user:uuid      project:uuid   5       1
122 124

  
123
System default quota
124
--------------------
125
Private projects
126
----------------
127

  
128
Since the introduction of base projects will explode the number of total
129
projects, we will need to control their visibility. We add a new flag
130
*private* in project definitions. A private project can only be accessed by
131
its owner and members and not be advertized in the UI. Base projects are
132
marked as private.
133

  
134
Decouple projects from applications
135
-----------------------------------
136

  
137
Base projects do not fit well in the current project/application scheme,
138
because no user has applied for them. Moveover, we would like to easily
139
modify project properties, particularly quota limits, without the need to
140
apply for an application for each project and then approve it.
141

  
142
We will decouple projects from applications by incorporating the project
143
definition into the project object rather than relying on an application.
144
The system will directly make a new (base) project upon user creation and a
145
privileged user will be able to modify an existing project by directly
146
modifying it. An unprivileged user will still need to make an application.
147

  
148
The project model is adapted to reference the *last* application that is
149
related to the project, if any---projects automatically created by the
150
system reference no application. For an uninitialized project, this
151
denotes the original application through which the project was made. If
152
the application is denied or cancelled, the whole project is considered
153
deleted.
154

  
155
Applications as modifications
156
`````````````````````````````
157

  
158
Application for a new project is created in state ``pending`` and its
159
properties are copied into a new project object, which is in state
160
``uninitialized``. To preserve this equality, we disallow modifications of
161
uninitialized projects, either in-place or through an application. An
162
already activated project can be modified by submitting an application
163
containing just the desired changes. An application object stores the
164
specified changes and should remain read-only.
165

  
166
System default quota and resource registration
167
----------------------------------------------
125 168

  
126 169
Each resource registered in the system is assigned a default quota limit.
127 170
A newly-activated user is given these limits as their base quota. This is
......
139 182
for conventional projects. It will be controled by a new option
140 183
``--project-default`` of command ``resource-modify``.
141 184

  
142
Private projects
143
----------------
144

  
145
Since the introduction of base projects will explode the number of total
146
projects, we will need to control their visibility. We add a new flag
147
*private* in project definitions. A private project can only be accessed by
148
its owner and members and not be advertised in the UI. Base projects are
149
marked as private.
185
When a project is activated, either directly in the case of base projects
186
or through the approval of a project application, limits for resources not
187
specified are automatically completed by consulting the appropriate
188
skeleton.
150 189

  
151 190
Allocation of a new resource
152 191
----------------------------
......
198 237
linked to a project. Pithos should link containers to projects.
199 238

  
200 239
Astakos will handle its own resource ``astakos.pending_app`` in a special
201
way: it will always be charged at the user's base project. This resource
202
is marked with ``allow_in_projects = False`` in its definition. Since quota
203
is now project-based, this flag will now be interpreted as forbidding usage
204
in non-base projects.
240
way: it will always be charged at the user's base project.
205 241

  
206 242
Resource reassignment
207 243
---------------------
......
268 304
          }
269 305
  ]
270 306

  
271
API extensions
272
--------------
307
API changes
308
-----------
273 309

  
274 310
API call ``GET /quotas`` is extended to incorporate project-level quota. The
275 311
response contains entries for all projects for which a user/project pair
......
312 348
      }
313 349
  }
314 350

  
351
``GET /service_project_quotas`` will be used in a similar way as ``GET
352
/service_quotas`` to get the project-level quotas for resources associated
353
with the Synnefo component that makes the request.
354

  
315 355
All service API calls that create resources can specify the project where
316 356
they will be attributed.
317 357

  
......
336 376
Field ``x-container-policy-project`` will be retrieved by a ``HEAD`` call at
337 377
the container level.
338 378

  
379
Changes in the projects API
380
```````````````````````````
381

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

  
384
``POST /projects/<proj_id>`` now expects a dictionary with just the desired
385
changes, not a complete project definition. It is only allowed if the
386
project is already activated.
387

  
388
``GET /projects/<proj_id>`` changes to include a ``last_application`` field,
389
if applicable.
390

  
391
Application actions (approve, deny, dismiss, cancel) are integrated into
392
project actions and expect an extra ``app_id`` argument to specify the
393
application. Actions are allowed only on a project's last application;
394
the application id is required in order to avoid races.
395

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

  
339 398
User interface
340 399
--------------
341 400

  
......
397 456
  ------------------------
398 457
  cyclades.vm 100    50
399 458

  
400
A new command ``snf-manage project-modify`` will automate the process of
401
applying/approving applications in order to modify some project settings,
402
such as the quota limits.
459
A new command ``snf-manage project-modify`` will enable in-place
460
modification of project properties, such as their quota limits.
403 461

  
404 462
Currently, the administrator can change the user base quota with:
405 463
``snf-manage user-modify <id> --base-quota <resource> <capacity>``.
406 464
This will be removed in favor of the ``project-modify`` command, so that all
407 465
quota are handled in a uniform way. Similar to ``user-modify --all``,
408
``project-modify`` will get options ``--all-base`` and ``--all-non-base`` to
409
allow updating quota in bulk.
466
``project-modify`` will get options ``--all-base-projects`` to
467
allow updating base quota in bulk.
410 468

  
411 469
Migration steps
412 470
===============

Also available in: Unified diff