Related tickets in this case also include all tickets related to the Hosting Subscriptions which are
allocated on this computer.

Not everything that is installed is registed into Software Release Module.

errors will be much more visible

Some testnodes were failing more or less randomly while calling "slapos node instance".
On failing nodes, unlike other ones, there was this unexpected log:

2016-10-06 15:35:18 slapos[11671] INFO Processing computer partitions...
2016-10-06 15:35:18 slapos[11671] INFO Launching supervisord with clean environment.
2016-10-06 15:35:18 slapos[11671] INFO Could not find platform independent libraries <prefix>
2016-10-06 15:35:18 slapos[11671] INFO Could not find platform dependent libraries <exec_prefix>
2016-10-06 15:35:18 slapos[11671] INFO Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
2016-10-06 15:35:18 slapos[11671] INFO ImportError: No module named site
2016-10-06 15:35:18 slapos[11671] WARNING Supervisord unknown problem:
2016-10-06 15:35:18 slapos[11671] INFO Processing Computer Partition test0-0.

Then slapgrid was later failing with :

slapgrid_cp :   File "/opt/slapgrid/75e907b4c1523ecfa2aa210ec2754db4/eggs/supervisor-3.3.1-py2.7.egg/supervisor/xmlrpc.py", line 521, in connect
slapgrid_cp :     self.sock.connect(self.socketfile)
slapgrid_cp :   File "/opt/slapos/rebootstrap/parts/python2.7/lib/python2.7/socket.py", line 228, in meth
slapgrid_cp :     return getattr(self._sock,name)(*args)
slapgrid_cp : error: [Errno 2] No such file or directory

But the initial suspect logs sounds be the original issue that is the source
of next ones.

So it looks like supervisord was not able to start at all.

After playing with subprocess.Popen, is sounds not a good idea to play
with the keyword 'executable'. It looks like not always be strictly equivalent
to a replacement of the first argument of the first Popen args. It's much better
to directly set the process we want to call in the invocation list :
- it avoid to rely on a feature that is "very seldom needed" as we see
  in subprocess documentation
- it makes the code much readable, it avoid the guy reading the
  code wasting time understanding that the invocation_list is not
  really what is going to be executed.

Those alarms aims to improve the Administrator Decision, closing tickets which has no solution (destroyed instances) or suspending tickets which are resolved (or false positives) without Administrator intervention.

The local ERP5Document_getHateoas should be removed and replaced by new erp5 JIO implementation.

There is no need to commit this messages.

Switch to Web UI to make simple actions is inconvient, so this commit moves the scripts to ERP5 UI to share the feature over the 2 UIs.

Buildout cannot request destroy sub instances when it is removed from
instance parameters by the user. Ex: request a cluster of KVM, with
kvm1 and kvm2 instances, edit parameters and remove kvm2 in the list.
Buildout will just ignore that instance and it will be removed only when
the hosting subscription will be destroyed.

                 -- kvm1
root instance --|
                 -X- kvm2

So when processing a partition, we send to master the list of requested sub
instance(s). If the previous list was ['kvm1', 'kvm2'], then after remove kvm2
the list will be ['kvm1'] (for the root instance). Commit this list to the
master will unlink between root instance and kvm2 (predecessor categorie).

A new alarm will search for unlinked instances: Instance which has no parent,
and destroy them (also destroy the sub tree).