There is now `EmptyResult` object which is an empty promise result. This result is send if the promise test or anomaly was skiped (if disabled).
To prevent raise because `EmptyResult` is unknonwn on old slapos-node with `slapos.core < 1.4.17` we will send an empty TestResult instead.

Support for promise test-less or anomaly-less allow to disable either the test phase or the anomaly phase.

by default, test and anomaly are enabled, `__is_tested = True` and `__is_anomaly_detected = True`. Test will run when buildout is processing the computer partition, and anomaly when the partition is processed.

Call `self.setTestLess()` in `__init__.py` of the promise will disable Test and set `__is_tested = False`. Call `self.setAnomalyLess()` will rather disable Anomaly and set `__is_anomaly_detected = False`.


    def __init__(self, config):
        GenericPromise.__init__(self, config)
        # Skip test check on this promise
        self.setTestLess()

If the promise is test less, then slapgrid will not run the promise while processing the partition which mean that the promise will not report error, only Anomaly will be checked. Samething, if promise is anomaly less, only test will run when slapgrid is processing the partition.

/reviewed-on nexedi/slapos.core!93

Support for promise test-less or anomaly-less allow to disable either the test phase or the anomaly phase.

by default, test and anomaly are enabled. Test will run when buildout is processing the computer partition, and anomaly when the partition is processed.

Call `self.setTestLess()` in __init__.py of the promise will disable Test and set `__is_tested = False`. Call `self.setAnomalyLess()` will rather disable Anomaly and set `__is_anomaly_detected = False`.

If the promise is test less, then slapgrid will not run the promise while processing the partition which mean that the promise will not report error, only Anomaly will be checked. Samething, if promise is anomaly less, only test will run when slapgrid is processing the partition.

This can hide problems when tests are not isolated correctly.

/reviewed-on nexedi/slapos.core!84

 - rename test files as test_*.py, this is how tests are collected by
   py.test

 - take into account that test runner might disable log level and patch
   sys.stdout already

/reviewed-on nexedi/slapos.core!92

  It incldudes minor fixes on the scripts

This may reduce code duplication across tests of several bt5 tests

this will be usefull when looking for all HS belonging to someone.

/cc @alain.takoudjou @rafael @guillaume.hervier

/reviewed-on nexedi/slapos.core!90

the related keys were missing in master/bt5/slapos_cloud/bt/template_catalog_method_id_list

the related keys were correctly commited in master/bt5/slapos_cloud/CatalogRelatedKeyTemplateItem/related_key_list.xml but not in master/bt5/slapos_cloud/bt/template_catalog_related_key_list

- fix upgrade decision duplicated when an hosting subscription is deployed in many partitions
- Prevent concurrent transaction to create 2 upgrade decision for the same Hosting Subscription

/reviewed-on nexedi/slapos.core!79

I added and fixed some URL columns on some views:
- `slapos_cloud/ComputerUsage_view`
- `slapos_cloud/HostingSubscription_view`

The goal is to make the process to look for the needed informations faster by reducing clicks between views on listbox objects, by making some changes such as clicking on an object name on a column should redirect to the object view page instead of the row's object view page.

Additionally, these changes are made to be compatible with the RenderJS UI.

As this is not the default behaviour in ERP5, it may sound counter-intuitive, but this special behaviour is made to improve efficiency/productivity over intuitivity.

Personally, I wondered about having some "compromise" which is having the "Plane" icon on these columns beside the content to clearly indicate that this icon will redirect to the object's view (as the current "Plane icon" behaviour in ERP5)

/reviewed-on nexedi/slapos.core!89

slapos_cloud: HostingSubscription_view: Add links to access elements from columns in instances list.

Typo fix of commit 7467ef4c

/reviewed-on nexedi/slapos.core!87

If there is not changes in slapformat.xml, current slapformat will not dump computer
resources (as well as partition resources).

For compatibility with olders version of slapformat, dump partition resources
if it's not created yet event if the file slapformat.xml didn't change.

/reviewed-on nexedi/slapos.core!88

https://docs.python.org/dev/whatsnew/3.2.html python3 warns about not unclosed files and sockets.

Use context managers with files to close them.

Use context manager to close socket to supervisor on python 3. On python 2 these sockets remain not closed as before.

There are a few warnings left, but output starts to be readable again.

/reviewed-on nexedi/slapos.core!78

[slapos_pdm] Prevent concurrent transaction to create 2 upgrade decision for the same hosting_subscription

[slapos_pdm] fix upgrade decision duplicated when hosting subscription is deployed in many partitions

tap_ipv6 option let you chose if you want IPv6 on the taps or not. Some
customers may decide to have only IPv4 inside their VMs.

We put only 1 address on the tap itself (e.g.
2001:67c:1254:e:89:69b0:ffff:ffff/128 instead of
2001:67c:1254:e:89:69b0:ffff:ffff/96) otherwise, when we assign the
address 2001:67c:1254:e:89:69b0::/96 inside the VM, the address has
"dadfailed" status (dad = "Duplicate Address Detection"). The problem
appears only with address "0" (ending in ::) but not with others
addresses. We had 2 solutions:
 * put only one address on the tap (the solution we choose)
 * forbid address "0" inside the VM

The chosen solution has the advantage that the host machine won't
answer the ping on behalf of the VM since the tap has only 1 address
(its own).

/cc @alain.takoudjou

/reviewed-on nexedi/slapos.core!86

This indicates on the transaction and on indexation that a payment was created for the invoice. This allow us to avoid duplicated creation due race conditions on activities.

slapos_payzen: Skip invoice if payment was created on the same transaction or if the payment wasn't indexed yet

  Otherwise it will lead to random failures caused by some race conditions

Update tests to follow up changes on the UI and replace repeated parts by macros.

There ins't a major change of behavious here