helm: add config to set default quota limits

[diegodelemos]

Stems from #421 (comment)

Currently, the quota_limit of any resource for a given user defaults to 0, indicating "no limits" quota.

We should add config variables to enable the activation of this feature in a user-friendly manner.

[mvidalgarcia]

I see multiple possibilities to implement this:

Initialization of user quota limits happens on user creation here and by default set limits to 0 (no limit).

We can have a config variable (e.g. REANA_DEFAULT_USER_RESOURCE_CPU_LIMIT) that:

• a) When initialize_user_quota_limits is called, checks if this config exists, if yes, it uses its value to set the limit.

  • Pros: The limit always lives in DB and allows having any combination of different limits accross users.
  • Cons: to change the limit of users already created we have to do it manually. The same would happen if at some point we decide to change the default limit. All the new users would have it, but already created ones would have the old limit.

• b) Create a @property called user_quota_limit or similar and use it always throughout our codebase instead of the Column value. This property can check if the config value exists, if yes it uses it, otherwise it will use whatever it's in the DB.

  • Pros: Flexibility to change the limits easy via config.
  • Cons: This won't allow having different limits accross users when using the config variable.

• b.1) Same as b) but first check if the limit value in the DB != 0. Pseudocode:

  if limit_value_db != 0:
    return limit_value_db
  else:
    if limit_value_config:
      return limit_value_config
    else:
      return limit_value_db  # 0 (no limit)

  • Pros: It's more flexible in terms of having users with different limits.
  • Cons: If there's a config set, it isn't possible to have users with no quota limit.

• c) Other ideas?

[tiborsimko]

What about having: (i) Helm deployment variables to set default quota limit variables; (ii) whever a user is created, use those env variables to put limits into DB for given user upon creation; (iii) offer reana-admin quota-set command that admins can use to bump limits or reduce limits for various users; (iv) write alembic recipe that updates all past users based on default values or that simply prints that admins should run this-and-this reana-admin command; (v) the application code could then always rely on limits being present in the DB, so could take those values as the single-source-of-truth without having to resort to any complex hybrid property logic?

[mvidalgarcia]

So basically option a) if I'm not wrong. Plus the ability to set quota limits via CLI.

(I didn't mention Helm variables but I was considering them implicitly)