ipython_notebook SR hooked with ERP5 kernel.
This kernel helps in interaction between erp5 and Jupyter frontend.
The patches have been cleaned up

Features:

- All the code execution is being done at erp5 side, Jupyter just acts as dumb client.
- Receives result as string and its mime_type and thanks to kernel, displays it accordingly.
- Interactions b/w erp5 and Jupyter frontend are based on HTTP requests.

Major changes:

- Addition of erp5 kernel
- Improvement in code according to guidelines(name, section name)
- Use jinja template as instance file and make it more dynamic
- Debugging added for ipython_notebook service.

Note: The certificate authentication changed has been reverted to the previous
one(done by creating wrapper around openssl command) for now.

/cc @Tyagov
/reviewed-by @kirr, @jerome  (on nexedi/slapos!33)

@jerome added --matplotlib=inline in 48eefab5 (ipython notebook) but it is
really neither needed:

   @jerome
   I remember adding this --matplotlib=inline line, but I am not sure it was
   ever needed. Using magic %matplotlib in notebook should be enough.

   @tiwariayush
   Yeah, for inline matplotlib in default python kernel, magics do there
   work(therefore neither pylab nor matplotlib alias are needed while starting the
   server), so I'd say leave this commit as it is and regarding version updation:
   a new patch making change wherever required.

nor supported:

   $ cat .slappart0_ipython_notebook.log
   [W 15:51:35.454 NotebookApp] Unrecognized alias: '--matplotlib=inline', it will probably have no effect.

Remove it.

P.S.

'--logfile' isn't available for ipython version 3.2.0 but we are not removing
it since we are planning to upgrade IPython to versions 4.x where it is supported.

Based on patch by @tiwariayush  (see nexedi/slapos!33)

Jupyter: Change section name to instance-jupyter so as not to raise conflict in case of multiple extends

/reviewed-by @kirr  (on nexedi/slapos!33)

Maintain consistency with the slapOS SR format.
This SR can be hooked with other SR(ex:wendelin) and its better
to follow one way of publishing result parameters

[ kirr: This essentially changes publication format to JSON:

    $ xslapos proxy show --params

    # before
    slappart0: ipython_notebook (type default)
        url = https://[2001:67c:1254:e:49::952d]:8888
        monitor_url = https://[2001:67c:1254:e:49::952d]:9685

    # after
    slappart0: ipython_notebook (type default)
        _ = {"url": "https://[2001:67c:1254:e:49::952d]:8888", "monitor_url": "https://[2001:67c:1254:e:49::952d]:9685"}

  I'm not convinced we really need this, nor that the .serialized version is
  the most oftenly used one:

    slapos$ git grep 'slapos.cookbook:publish$' |wc -l
    59
    slapos$ git grep 'slapos.cookbook:publish.serialised$' |wc -l
    13

  but we can have it and see how it goes, reverting if needed ]

/cc @jerome
/proposed-for-review-on nexedi/slapos!33

This helps in logging up the requests made by ipython_notebook service

[ kirr: To be clear - until log-level is set to DEBUG, IPython notebook does
  not log HTTP requests, and since logging of HTTP requests is considered normal
  for most of our services (Zope, Apache, etc), it makes sense to enable such
  functionality for notebook too.

  There is not much additional noise produced by --log-level=DEBUG - in
  practice ipython only prints what config files it uses on startup, so this
  should be ok to go. ]

/reviewed-by @kirr, @jerome  (on nexedi/slapos!33)

ERP5 kernel basic info/workflow:

1. User enters code on notebook cell and executes
2. Code is sent to kernel via websockets
3. Kernel sends request to ERP5
4. Code is executed by ERP5 and the result is returned back via request.
5. Result is received and rendered on the notebook frontend.
6. Other message formats such as error and status are also conveyed by the Kernel.

[ kirr: in IPython notebook speak kernel is something that allows IPython
  notebook server side to talk to execution backend. ERP5 kernel is a thing that
  allows ipython notbook to talk to ERP5 (with help on-ERP5-server special bt5
  installed which accepts and executes commands).

  The bt5 to handle notebook calls on ERP5 side - erp5-data-notebook - is
  proposed to be merged into erp5.git on erp5!29 ]

/initially-reviewed-by @kirr, @Tyagov  (in a lot of places, last time on !33)

IPython Notebook: Explicitly add environment variable around wrapper and use ipython directory inside instance in env

[ kirr: By default IPython keeps configuration and other files location in
  ~/.ipython . What this patch does is organize explicit directory in instance
  tree to keep such files  ]

/reviewed-by @kirr  (on nexedi/slapos!33)

IPython Notebook: Add dynamic-template-base section for common jinja related file section and extend them with this section

[ kirr: to-Jinja2 conversion is required because jinja is more suitable to
  describing instances compared to buildout, because jinja2 has e.g. control
  structures ]

/reviewed-by @kirr  (on nexedi/slapos!33)

Commit cee110b2 (IPython Notebook: Fixing coding crimes for section
names) changed IPython notebook section name to use '-' as word
delimiter but forgot to update users, and this way wendelin build
started to fail:

    INFO While:
    INFO   Installing.
    INFO   Getting section ipython_notebook.
    INFO Error: The referenced section, 'ipython_notebook', was not defined.

Fix it. (And I've made sure with whole-tree git grep that there is no
more ipython notebook users except wendelin in whole slapos.git so far)

/reported-by @Tyagov
/cc @tiwariayush
/reviewed-by TrustMe

This is required so that buildout does not fallback to installing
non-dev egg if version of wendelin.core from -dev differs from what has
been pinned.

For example the following

    [buildout]
    extends =
      https://lab.node.vifib.com/nexedi/slapos/raw/1.0.12/software/wendelin/software-dev.cfg

    # pin wendelin.core-dev to latest assumed-good revision with ZBlk1 support
    [wendelin.core-repository]
    revision = c507d9009f59fec2041bac9c31c5b08a48d3897d

will install wendelin.core-0.4.egg from pypi instead of installing
c507d9009f59fec2041bac9c31c5b08a48d3897d from repository, because that
latter revision says it is already version 0.5 and 1.0.12 wendelin SR
pins wendelin.core to 0.4 .

So unpin wendelin.core from versions and let software-dev.cfg work
always.

/cc @klaus
/reviewed-by @Tyagov  (on nexedi/slapos!36)

IPython Notebook: Add download-file-base section which would be extended by sections requiring common usage

/reviewed-by @kirr  (on nexedi/slapos!33)

/reviewed-by @kirr  (on nexedi/slapos!33)

Use spinal-case('-' separated) instead of snake_case('_' separated) in section names.

/reviewed-by @kirr  (on nexedi/slapos!33)

If restrict mode is set to true, nat interface (eth0) will be isolated, no network access, only host and guest forward rules will work throught that interface.
This option is true by default for kvm-cluster, and false for single and resilient kvm.

In case there are errors when creating cluster / setting up its
configuration files, currently we leave pgsql database left
half-installed and next time instantiation runs do not do anything,
because os.path.exists(pgdata) is already true.

I've personally hit this situation via providing ipv4 and ipv6
parameters as strings and the recipe wanted to do `ipv4.join(ipv6)` but this
works only for sets and raises for strings.

What is worse is that the above error becomes hidden in our default
setup, because webrunner tries to do instantiation _several_ times, and
on the second run instantiation succeeds, because pgdata directory
already exists and recipe thinks there is nothing to do _and_ webrunner
already removed instance.log from previous run.

So do not hide errors, and if we see there are problems, remove the
wholly created pgsql database directory.

/cc @kazuhiko, @jerome
/proposed-for-review on nexedi/slapos!29

If the list of families does not change, their ports must not change, and it's
wrong to get this by relying on CPython implementation details. Even if we
automated the update of frontends with new urls, this couldn't be done
atomically and we'd get random failures.

Currently, frontends are only updated manually so we also want to minimize
changes when families are added/renamed/removed. By sorting alphabetically,
we have something predictable. Of course, this does not cover cases like the
following one:
- before: A, B, C
- after: A, C
Even if we added a 'port-base' parameter for the balancer, the port would
change for one of the 2 families.

We have no need for the moment, but we could go further with an optional list
parameter to choose the order, and a special value to skip ports. Another
option is to use publish-early but it's more complicated to implement and
we lose everything when we reinstanciate.

The sort in haproxy.cfg.in is for the stats page.

that is a long-deprecated syntax and removed in haproxy 1.6.