Commit 1a0feae6 authored by Jérome Perrin's avatar Jérome Perrin

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

from nexedi/slapos!408 (comment 66703)
parent f362eed5
......@@ -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:
......
  • @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).

  • 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 ]

    Edited by Jérome Perrin
  • 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

  • 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.

  • 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.

  • mentioned in merge request erp5!760 (merged)

    Toggle commit list
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment