You can provide sla parameters to each request you make.
Parameters are analysed that way.
 * If it starts with "-sla-" it is not transmitted to requested instance and is used to do the request as sla.
 * -sla-foo-bar=example (foo being a magic key) will be use for each request considering "foo" as a key to use and the sla parameter is "bar". So for each group using the "foo" key, sla parameter "bar" is used with value "example"
About magic keys:
We can find 2 kinds of magic keys:
 * id : example, in "-sla-2-foo" 2 is the magic key and the parameter will be used for each request with id 2 (in case of kvm: kvm2 and PBS 2)
 * nameid : example, in "-sla-kvm2-foo", foo will be used for kvm2 request. Name for pbs is "pbs" -> "-sla-pbs2-foo".
IMPORTANT NOTE: in case the same foo parameter is asked for the group, the nameid key prevail

Conflicts:
	stack/resilient/buildout.cfg

No need for external NBD by default. No need to wait minutes to boot from installer in VM.

It is in slapos 1.0 itself.

Resilient stack: Experimental: dynamically forward instance parmaeters to requested export instance.

Not stable yet.

Bit of cleanup about now useless backward-compatibility.

So that it doesn't change every day.

So we remove the trailing /.

2.7 is not backward compatible and breaks import-list.

More logical. Also add comments.

s.r.cmmi 0.2.0 switched to buildout2-style, so we follow.
In the meantime, use a fixed target-list if it proper conditional
section is not supported.

for the slaprunner branch and the purpose of development

slaprunner now run in local-ipv4 and is served by nginx which provide ssl