caddy-frontend: add a TODO item to evaluate caddy telemetry

from nexedi/slapos!408 (comment 66703)

software/caddy-frontend/TODO.rst

@@ -58,6 +58,7 @@ Generally things to be done with ``caddy-frontend``:
  * drop ``6tunnel`` and use ``bind`` in Caddy configuration, as soon as multiple binds will be possible, tracked in upstream `bind: support multiple values <https://github.com/mholt/caddy/pull/2128>`_ and `ipv6: does not bind on ipv4 and ipv6 for sites that resolve to both <https://github.com/mholt/caddy/issues/864>`_
  * use caddy-frontend in `standalone style playbooks <https://lab.nexedi.com/nexedi/slapos.package/tree/master/playbook/roles/standalone-shared>`_
  * in ``templates/apache-custom-slave-list.cfg.in`` avoid repetetive ``part_list.append`` and use macro like in ERP5 SR (cf `Vincent's comment <https://lab.nexedi.com/nexedi/slapos/merge_requests/373#note_64362>`_)
+ * **Jérome Perrin**: consider privacy implications/GDPR compliance of <https://caddyserver.com/docs/telemetry>_ and decide if we should leave it enabled.
 
 Things which can't be implemented:
 

[Jérome Perrin]

@luke this is what you suggested.

It's not the right place, but I have one note for this TODO:

• tests: add assertion with results of promises in etc/promise for each partition

Shouldn't this be the job of slapos node instance running by test setup ? if promises are not passing, instance should fail (and I suspect this is not the case).

[Jérome Perrin]

also why don't we use markdown here :)

[edit: I was making fun of myself for not being able to use rst, as you can see in my latest commits ... but I don't mind if we use rst ]

[Łukasz Nowak]

Shouldn't this be the job of slapos node instance running by test setup ? if promises are not passing, instance should fail (and I suspect this is not the case).

We do not consider failing slapos node instance as a problem in this test infrastructure, that's why I added this entry to the list. See https://lab.nexedi.com/nexedi/erp5/blob/master/erp5/util/testnode/SlapOSControler.py, and the lines:

      if status_dict['status_code'] in (1,2):
        status_dict['status_code'] = 0

This would be a big change for testing infrastructure.

also why don't we use markdown here :)

Do you mean TODO.rst and README.rst? Well, why? Gitlab renders this file correctly, isn't it? https://lab.nexedi.com/nexedi/slapos/blob/master/software/caddy-frontend/TODO.rst

[Jérome Perrin]

Thanks for feedback

( for reference, the lines are here )

This would be a big change for testing infrastructure.

So the state is really that we retry instanciation serveral times until all promises are OK, but if at the end promise are not OK we run test anyway. I feel this is incorrect. Maybe as a first step we could log a big warning saying that instanciation promise were not successful and that we are running tests anyway.

I wonder if we have lots of test in this status also it's unclear if it's a feature. Maybe at that time the status of instance promise was not good ?

/cc @vpelletier @seb

---

also why don't we use markdown here :)

Do you mean TODO.rst and README.rst? Well, why? Gitlab renders this file correctly, isn't it? https://lab.nexedi.com/nexedi/slapos/blob/master/software/caddy-frontend/TODO.rst

yes, it works well. It was just a joke because I have difficulties writing rst 9a1debc1 and then 36043007 but rst is fine.

[Vincent Pelletier]

Promises are essentially trivial tests which get run at anytime everywhere which tells us whether an instance is healthy. I would think the full-featured heavy tests should have no reason to run on a trivially unhealthy instance, so promise failure should probably be reported as a test failure in its own right.