[WIP] Demo operations

[nelsonkopliku]

Description

This PR aims to add the ability to have faked operations, similarly to what we have for checks executions.

The underlying idea is the same: we have a configuration file that specifies what to assume agents return - operation reports in this case.

Alternatives to this approach could be:

• fully faked agents (well, we don't have it)
• a more sophisticated mechanism where we spawn different processes (ie genservers) that behave like an agent:
  • listen to the same OperatorExecutionRequested message as an agent would do
  • determine which mocked report to emit
  • emit the mocked report via a OperatorExecutionCompleted message as an agent would do

[nelsonkopliku]

@arbulu89 I would appreciate feedback on this approach.

Decoupling this Reporting module enables the mocking we want to introduce, besides improving the general code structure in terms of responsibility of components.

If you look at checks execution a similar approach made it possible in the first place to have such mocking.

Naming can be further improved: both the module name and functions name (I mainly kept similar if not the same to the ones that were embedded in the server)

[nelsonkopliku]

Here we'd have a list of targets, initially we can think of them in terms of host ids

[nelsonkopliku]

This structure is meant to define what report each target is going to return for a given operation/step.

References to target1, target2 will be resolved with relevant uuids when parsing the file.
It is handy to keep the yaml tidy and less noisy by avoiding repetition of uuids

[arbulu89]

Hey @nelsonkopliku ,
I have been thinking about other alternative solution that maybe is simpler to implement. It consists on using the real operations server in the fake server and sending the receive_reports message from it.

It would we something like:

defmodule Wanda.Operations.FakeServer do

@behaviour Wanda.Operations.ServerBehaviour

@impl true
def start_operation(operation_id, group_id, operation, targets, config) do
    # maybe we need to handle the return from this, specially the already_running one
    Server.start_operation(operation_id, group_id, operation, targets, config)

    # we start reporting for each step and each target
    Enum.forEach(steps, ...
        Enum.forEach(targets, ...
            report = get_report() # we get report from yaml or created with faker
            Server.receive_operation_reports(operation_id, group_id, 0, agent_id_1, report)
            # sleep, other things...
            ...
end

@impl true
def receive_operation_reports(_, ...), do: :ok

Maybe it is simpler, we use all the already existing logic, so we don't need to extract things from the current code, and at the end, the difference between the demo and the real one are just the how the reports are received.

What do you think?

Other aspects:
Knowing that the demo environment is a fully controlled environment and we know exactly the state of all hosts, I think we could already have a predefined state of returns, including the states. For example:

• We don't need to check the predicate. We know that this step in this host should be skipped
• We can compose the whole report (result, diff, error (if it failed), etc)

[arbulu89]

Maybe we could change this to instead of only having the diff, to have the complete report (whether is a correct change or error):

0:
    target1:
        result: "updated"
        error_message: ""
        diff:
            before:
                solution: ""
            after:
                solution: "HANA"
        ....

[nelsonkopliku]

Hey @arbulu89, thanks! It looks worth trying that path. Let me look into that.

I still have the feeling that some sort of decoupling of what happens inside the server might be beneficial, but for the sake of the task at hand - demoing things - such refactor can be not considered here.