( mostly because old version is no longer on CPAN )

( mostly because old version is no longer on CPAN )

We stop using slapos.recipe.build:cpan , but these unstable components are
not ready and not being actively maintained, so move them inline in
mioga software, which was the only user of these components.

When the work on this is resumed, we should switch to perl-CPAN-package
here as well.

Generate a wrapper with all dependencies available

${perl:location} is now a perl without any package, components using
perl with one specific package must switch to using the perl with the
dependent CPAN packages installed.

Installing everything in site_perl is not the "buildout way" and is
incompatible with the upcoming shared slapos.recipe.cmmi

  This version contains optimisation for restore (and a bit for backup), specially in case of large sets of unmodified files.

this parameter is used for external service like saucelab to access test url

Drop support for Go 1.8; Add support for Go 1.10 and make it the
default.

It comes a bit late because previously we were hitting
https://golang.org/issues/24285, and so have beeing waiting for
slapos.core!42 to be
deployed there on slapos nodes everywhere.

As of 9 Aug 2018 it seems that deployment has been completed.

/reviewed-by @alain.takoudjou, @rafael.
/reviewed-on !372

/reviewed-on nexedi/slapos!368

the recipe slapos.cookbook:generate.password will install the password only after the [request-xx] was called for the first time. Then the second run of buildout the password can change as it was not stored yet. We use publish-early to make it persistent on master and avoid inconsistency between published password and stored one.

/reviewed-on nexedi/slapos!370

This option is not advertised and it is not needed at all in Caddy
configuration.

As monitor stack uses values directly from buildout convert them to buildout
safe values, otherwise the the magic !py! is not stripped.

Also add a test proving that monitor with default values is going to be
correctly configured.

It sometimes results with returning passwords with newlines, thus they have
to be trimmed.

Features:

 * jinja2 is used to generate instance templates
 * downloads are done the same way for all resources
 * create with shared content for all instance profiles
 * fill in instance-common with shared sections
 * render templates late in order to ease its extenension and development
 * drop not needd duplicated section
 * drop slap-parameter in frontend and replicate template
 * simplify monitor configuration
 * move instance-parameter to instance file
   Thanks to this only one and topmost profile is reponsible for parsing and
   passing through the information which comes from the network

make sure password section is installed before request runner{0,1} and pbs instance for webrunner because the password is send in the request.

The path of software release in webrunner is like: `/srv/slapgrid/slappartXX/srv//runner/project/slapos/software/soft/software.cfg`  because ~/srv directory in webrunner is set with a / at the end:

Changing that path will modify the URL of software release in webrunner, this is why we should always keep it as: `/srv/slapgrid/slappartXX/srv//`

if backup.signature is present in tmp/ folder (during push) promise will fail because find return 2 elements and 1 is expected