will request the third frontend on COMP-1234. All frontends will be of software type ``custom-personal``. The second frontend will be requested with the state stopped
will request the third frontend on COMP-1234 and with SR https://lab.nexedi.com/nexedi/slapos/raw/someid/software/caddy-frontend/software.cfg. All frontends will be of software type ``custom-personal``. The second frontend will be requested with the state stopped.
*Note*: the way slaves are transformed to a parameter avoid modifying more than 3 lines in the frontend logic.
*Note*: the way slaves are transformed to a parameter avoid modifying more than 3 lines in the frontend logic.
...
@@ -392,6 +392,8 @@ Additional partition with KeDiFa (Key Distribution Facility) is by default reque
...
@@ -392,6 +392,8 @@ Additional partition with KeDiFa (Key Distribution Facility) is by default reque
By adding to the request keys like ``-sla-kedifa-<key>`` it is possible to provide SLA information for kedifa partition. Eg to put it on computer ``couscous`` it shall be ``-sla-kedifa-computer_guid: couscous``.
By adding to the request keys like ``-sla-kedifa-<key>`` it is possible to provide SLA information for kedifa partition. Eg to put it on computer ``couscous`` it shall be ``-sla-kedifa-computer_guid: couscous``.
Also ``-kedifa-software-release-url`` can be used to override the software release for kedifa partition.
{% do request_dict.__setitem__(request_section_title,
{% set request_content_dict = {
{
'config': config_dict,
'config': config_dict,
'name': frontend_name,
'name': frontend_name,
'sla': sla_dict,
'sla': sla_dict,
'state': slapparameter_dict.pop(state_key, None)
'state': slapparameter_dict.pop(state_key, None)
}) %}
} %}
{% set frontend_software_url_key = "-frontend-%s-software-release-url" % i %}
{% do request_content_dict.__setitem__('software-url', slapparameter_dict.get(frontend_software_url_key) or '${slap-connection:software-release-url}') %}
{% do request_dict.__setitem__(request_section_title, request_content_dict) %}
@@ -96,11 +96,14 @@ You will use slapos.cookbook:promise.plugin to generate your promise script into
...
@@ -96,11 +96,14 @@ You will use slapos.cookbook:promise.plugin to generate your promise script into
[promise-check-site]
[promise-check-site]
<= monitor-promise-base
<= monitor-promise-base
module = check_port_listening
module = check_port_listening
name = check_site.py
config-hostname = ${publish:ipv6}
config-hostname = ${publish:ipv6}
config-port = 2020
config-port = 2020
config-foo = bar
config-foo = bar
The section `monitor-promise-base` is defined in the monitor stack. Then you will have to add `promise-check-site` section to buildout parts, so it will be installed.
The section `monitor-promise-base` is defined in the monitor stack, `name` is the filename of the script that will be generated under `etc/plugin` directory, `module` is the name of your promise module (you can find a list of existing module in https://lab.nexedi.com/nexedi/slapos.toolbox/tree/master/slapos/promise/plugin).
Then you will have to add `promise-check-site` section to buildout parts, so it will be installed.
In your promise code, you will be able to call `self.getConfig('hostname')`, `self.getConfig('port')` and `self.getConfig('foo')`. The returned value is `None` if the config parameter is not set.
In your promise code, you will be able to call `self.getConfig('hostname')`, `self.getConfig('port')` and `self.getConfig('foo')`. The returned value is `None` if the config parameter is not set.
