Idempotent spawn

[victormlg]

Here is a first iteration of idempotent spawn. It can probably be optimized in further iterations, by for example spawning in "parallel"

The way it works is that it will update the environment by comparing the given yaml config to the previously successfully run yaml config. If we want tp ignore the previously run config we can run using the --reset flag.

[cf-bottom]

Thanks for submitting a pull request! Maybe @larsewi can review this?

[olehermanse]

The way it works is that it will update the environment by comparing the given yaml config to the previously successfully run yaml config. If we want tp ignore the previously run config we can run using the --reset flag.

Interesting. My thinking was that we could evaluate the current (new) config, to the "actual state" somehow, not the previous config.

For example, what would happen if:

1. Config has 2 hosts.
2. Run up and spawns 2 hosts successfully.
3. Edit config to have 2 more hosts.
4. Run up, but this time 1 succeeds and second fails.
5. State no longer matches old or new config.

My idea was that if you run the new config in this case, it should recognize that 3 hosts are correctly set up, and it just needs to spawn the last one.

[olehermanse]

Needs to be rebased, has conflicts.

Please open a separate PR to document (markdown) how the spawning and up command should work. We should discuss and decide on this before we continue with the implementation (code), I think. README.md has a very short section, need to expand this with details on how current (actual) state is determined, and how to find the diffs of what to change / fix.

[victormlg]

The way it works is that it will update the environment by comparing the given yaml config to the previously successfully run yaml config. If we want tp ignore the previously run config we can run using the --reset flag.

Interesting. My thinking was that we could evaluate the current (new) config, to the "actual state" somehow, not the previous config.

For example, what would happen if:

1. Config has 2 hosts.

2. Run up and spawns 2 hosts successfully.

3. Edit config to have 2 more hosts.

4. Run up, but this time 1 succeeds and second fails.

5. State no longer matches old or new config.

My idea was that if you run the new config in this case, it should recognize that 3 hosts are correctly set up, and it just needs to spawn the last one.

That was my initial idea as well but then this would require parsing the state.json, which doesn't contain the exact same information than the config. For example, the cfengine installation (what hub it is bootstrapped to, etc..).