Commit f0b5af3a authored by Giorgos Korfiatis's avatar Giorgos Korfiatis
Browse files

docs: Add resource defaults design

parent 312f51f0
Resource default limits and visibility
We wish to keep track of resources which are not visible to the user or
resources that we don't care to impose a certain limit on. For example, we
wish to know the total number of CPUs per user without checking a limit and
without the user needing to specify a value when applying for a new project.
However, the administrator should be able at any time to change either of
these parameters.
Resource registration
A new resource will be registered with an infinite base quota limit (denoted
by 2**63-1). A holding is created in the quotaholder for each accepted user
with the said limit. This means that the resource is ready to be used in a
commission, but we are not interested in checking a senseful limit.
Resource ``cyclades.cpu`` will from now on denote the number of active cpus.
Its description will change to explain this. A new resource,
``cyclades.total_cpu``, will also be registered in the system, with the
semantics ``cyclades.cpu`` used to have. The reason for this change is that
(in our default policy) we would like to control the number of active CPUs
but not the total CPUs (the latter would have an infinite limit). However,
existing projects have specified a value for the resource ``cyclades.cpu``.
If we don't reinterpret it as active CPUs, then this grant will be
useless: It will add a value to infinite total CPUs, but provide no active
CPUs. Likewise we will change ``cyclades.ram`` and register
There now exists attribute ``allow_in_projects`` in resource definitions,
which controls whether a resource appears in a project application in the
UI. Currently, this is set to False only for resource
``astakos.pending_app``. This will be renamed to ``ui_visible`` and affect
also the appearance in the Usage page. A new attribute ``api_visible`` will
also be included in resource definition (True by default), to control
whether the resource can appear in related API calls: GET /resources, GET
/quotas, POST /projects (applying for a project), etc. ``ui_visible`` will
entail ``api_visible``. Both attributes will be adjustable through
``snf-manage resource-modify``.
Resources ``cyclades.total_cpu`` and ``cyclades.total_ram`` will be marked
with ``ui_visible=False`` and ``api_visible=False``.
Changing base quota
Base quota for a certain user is currently determined by looking up
the default base quota that is registered for the resource, unless there
exists a custom limit for the user/resource pair in the model
AstakosUserQuota. Resource limit can change with::
snf-manage resource-modify <resource_name> --limit <value>
This not only changes the quota scheme for future users but also affects all
existing users that have no custom limit for this resource. This is
troublesome, because it doesn't allow simply changing the future quota
scheme. One is forced to rather set custom quota for new users, just in
order to express the new default.
This behavior will change: we will discard the distinction between users
having default or custom quota. Resource default limits will be viewed
as a skeleton for determining base quota for new users. When a new user
is accepted, resource defaults will be consulted in order to fill the
user-specific entries in AstakosUserQuota. When a resource default
changes, this will not affect quota of existing users.
For clarity, option ``--limit`` will be renamed ``--default-quota``.
We can currently change a user's base quota with::
snf-manage user-modify <id> --set-base-quota <resource_name> <value>
This command will be extended with option ``--all`` to allow changing base
quota for multiple users; option ``--exclude`` will allow introducing
Inspecting base quota
Management command ``quota`` will split into ``quota-list`` and
``quota-verify``. The former will be used to list quota and will provide
various filters. Option ``--with-custom`` will allow filtering quota that
differ from the default or equal to it. Option ``--filter-by`` will enable
filtering specified values, e.g. ``--filter-by "usage>1G"``
......@@ -120,19 +120,24 @@ counters would differ.
cyclades.vm project:uuid None 5 1
cyclades.vm user:uuid project:uuid 5 1
System default base quota
System default quota
Each resource registered in the system is assigned a default quota limit.
A newly-activated user is given these limits as their base quota. Up to now,
a change in a default quota limit propagates to all users' base quota
(except if they have been customized). Since all users' base quota will be
controlled through their base projects, the default behavior of
``resource-modify`` will change to affect only future users (i.e.
construction of new base projects). However, new option
``--update-existing-base-projects`` will allow setting the limits to
existing base projects, too. This is useful, for example, when setting a
newly registered resource.
A newly-activated user is given these limits as their base quota. This is
till now done by copying the default limits as user's entries in
AstakosUserQuota. Default limits will from now on be copied into the base
project's resource definitions.
Conventional projects are created through a project application, which
may not specify limits for all resources registered in the system. In
fact, it may even be impossible to specify a resource, if it is set
``api_visible=False``. We have to somehow specify these limits. Defaulting
to zero is not appropriate: if we don't want to control a resource, we
would like it set to infinite. We thus need an extra skeleton, like the
one specifying the default base quota, in order to fill in missing limits
for conventional projects. It will be controled by a new option
``--project-default`` of command ``resource-modify``.
Private projects
......@@ -392,9 +397,6 @@ Quota can be queried per user or project::
cyclades.vm 100 50
``snf-manage quota`` will be removed; checking the integrity of the
Quotaholder will be provided by a new command ``reconcile-quota``.
A new command ``snf-manage project-modify`` will automate the process of
applying/approving applications in order to modify some project settings,
such as the quota limits.
......@@ -402,7 +404,9 @@ such as the quota limits.
Currently, the administrator can change the user base quota with:
``snf-manage user-modify <id> --set-base-quota <resource> <capacity>``.
This will be removed in favor of the ``project-modify`` command, so that all
quota are handled in a uniform way.
quota are handled in a uniform way. Similar to ``user-modify --all``,
``project-modify`` will get options ``--all-base`` and ``--all-non-base`` to
allow updating quota in bulk.
Migration steps
......@@ -150,6 +150,7 @@ Drafts
Sample design <design/sample>
Resource-pool projects design <design/resource-pool-projects>
Resource defaults design <design/resource-defaults>
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment