Pre checks section in experiment defenition

[alexander-gorelik]

Hi again

We are progressing with our experiment and now we need to execute several pre-checks before we actually begin with the steady-state execution.
For example, we need to check if

• There is no DDoS attack
• There are no sales
• There is no maintenance
• etc..

The current way to handle this,
I create Control and put all the functions that implement those pre-checks in the configure_control method, so I am coupling multiple different actions in code and not in configuration.

In another experiment, I need only the DDOS pre-check, so I need to create a control and reuse the DDOS function in code instead of reusing function in the configuration as I do with probes and actions.

In my opinion, this approach is the opposite of declarative experiment definition and separation of actions that I think you believe in.

I thought of something like this.

{
    "pre-checks":[
       {
         "type": "probe",
         "name": "ddos"
       },
       {
         "type": "probe",
         "name": "no-sales"
       }
     ]
    "steady-state-hypothesis": {
        "probes": [
            {
                "type": "probe",
                "name": "name-a"
            }
        ]
   }
}

WDYT?

[Sylvain Hellegouarch]

Hello,

This is an interesting point. I can see the appeal to do what you describe here. Technically controls can be declared per-experiments as therefore are declarative as well. Usually they are declared in the settings because they tend to be common, but you can actually declare them at the experiment level.

If we go the route of a new element like "pre-checks", then we need to dig how to properly specify it and its promises.

[alexander-gorelik]

I agree that Control definition itself is declarative but you don't know when they actually executed from JSON as you know(the order) for steady-state, method, and rollback.
In the case of controls, you have to view the code of the control to understand when it is executed.

So what you actually saying that I should implement it like this to get as much as possible separation.

 "controls": [
    {
        "name": "ddos",
        "provider": {
            "type": "python",
            "module": "chaoshub_commons.ddos"
        }
    },
    {
        "name": "noSales",
        "provider": {
            "type": "python",
            "module": "chaoshub_commons.no_sales"
        }
    }
  ]

[Sylvain Hellegouarch]

That example would be my idea yes.

As said in #188, I'm always hesitant to add new first class citizen elements, specially when they are operationally concerned. However, maybe we do need an operation element somehow?

[Sylvain Hellegouarch]

If that is okay, I will close this one in favour of #196.