GitLab

[slapconfiguration]
<= slap-connection
recipe = slapos.cookbook:slapconfiguration.jsonschema
jsonschema = ${buildout:directory}/software.cfg.json

The recipe validates instance parameters against the JSON schema, and
automatically fills in values of parameters left unset from defaults
specified in the schema, both for the main instance and for every
shared instance, if any.

Validation error or conflicting defaults - when the instance validates
multiple combined schemas that each set different defaults - can occur.

In case of error in the main instance parameters, the recipe raises an
exception. Otherwise, the completed instance parameters are available
in `configuration`.

For shared instances, valid and conflict-free instances are
collected in `valid-shared-instance-list` as dicts in the form of:
```
{'reference': "...", 'parameters': {...}}
```
with parameters completed by defaults as appropriate.

Invalid shared instances are collected in `invalid-slave-instance-list`
as dicts in the form of:
```
{'reference': "...", 'parameters': {...}, 'errors': [...]}
```
with parameters left as-is without added defaults.
Co-authored-by: Thomas Gambier <thomas.gambier@nexedi.com>

See merge request nexedi/slapos!1642

Directly expose all passlib.hash supported hashes, using a `passwd-`
prefix. For example, to access `sha256_crypt`, use `passwd-sha256-crypt`
option name.

  [secret]
  recipe = slapos.cookbook:generate.password

  [config-file]
  hashed-password = ${secret:passwd-sha256-crypt}

This changes the format of storage-path, it used to be the password in
plain text, it is now a mapping also containing hashed passwords, to
have the same hashed passwords for each buildout run.

This needs collaboration from publish_early recipe, because .pop(k) does
raised a KeyError with the dict.__missing__  approach.

not used and seems not working (using php5)

In some contexts it's required to not stop buildout processing on publishing
errors, thus such recipe is required in those cases.

By providing -error-status-file it's possible to check status of the publish,
the file will be created on error and removed on successful call or during
uninstall. It's responsibility of the caller to handle such errors, for example
by using proper promises.

remove also software/unstable/zimbra-kvm which were still referencing
those recipes