Loop elements became unnecessary

[0x41gawor]

In current Lupus design (which in my opinion occurs to be the best one. But maybe we should start again and some other direction will develop?) all of the loop workflow modelling occurs in Decide element with Actions on Data object.

As for now loop elements diagram/schema always looks like*:

*As there is no need to spawn more Decide elements

And actual workflow/pipeline design occurs in Decide:

So..... if every loop looks the same and user has nothing to do in Observe and Decide? Why put their spec in maser yaml file? Or maybe why do they even exist?

Rethink this.

[0x41gawor]

The follow-up idea from Mr. Bursztynowski is to fuse the Observe, Decide, and Execute element types into one generic type—let's call it Element for now. This is because all these types share three general steps:

1. An external force updates their status.
2. They execute some logic.
3. They update the status of the next element (except for Execute).

Observe

1. The external force in this case is the Ingress-Agent.
2. The logic was meant to handle the translation between the managed system and Lupus, but this role has been taken over by the Ingress-Agent.
3. The next element in this case is Decide.

Decide

1. The external force in this case is the Observe element.
2. The logic here involves managing the Data object through actions.
3. The next element in this case is Execute.

Execute

1. The external force in this case is the Decide element.
2. No logic is executed here. The translation role between the managed system and Lupus has been taken over by the Egress-Agent.
3. There is no next element, but Execute has a specified HTTP address where the Data is sent.

This approach allows us to:

Develop a generic Element that can be spawned multiple times by the user/designer to fit the needs of a specific loop. Develop a single Element that is instantiated once, containing all necessary specifications.

[0x41gawor]

Ok, so the next discussion arises on top of this ... It looks like a lot of work has to be done inside Ingress/Egress Agents. This work is called translation. The idea was to use Kubernetes, but the whole translation will occur outside of it.

But I think the managed-systems are so various that we have to give our users opportunity to "translate" with any programming technology (recommended python).