Design cf-remote config #165
Conversation
Signed-off-by: Victor Moene <victor.moene@northern.tech>
vm-config.md
Outdated
| - Atomic config: either all vms created or none. No in-between states. | ||
| - Top-down run order |
There was a problem hiding this comment.
Not sure what you mean by these 2 points.
There was a problem hiding this comment.
- The idea was that either all the VMs on the config are created, or none are created. There should not be any state where half of the VMs were creating or worse, that the VMs are not attached to the config anymore.
- I think that the creation order in the config would be top-down. It's probably redundant to mention it here.
There was a problem hiding this comment.
- Maybe, this is a bit opposite of what is normal in CFEngine. We try to converge, do as much as possible, maybe it will be able to fix something more if you run it one more time, etc.
- This should not be a goal / default. In many cases it will be desirable to spawn things in parallel, to speed it up.
|
@victormlg Continuing on your example, here is my updated suggestion; spawn-config:
- ubuntu-vm:
provider: aws
aws:
image: ubuntu-24
- local-ubuntu-vm:
provider: vagrant
vagrant:
image: ubuntu/focal64
memory: 1024
cpus: 2
groups:
- cloud-hub:
role: hub
spawn-config: ubuntu-vm
count: 1
cfengine: 3.24.3
scripts: [ ./provision.sh ]
- cloud-clients:
role: client
spawn-config: ubuntu-vm
count: 2
cfengine: 3.24.3
bootstrap: cloud-hub
- local-hub:
role: hub
spawn-config: local-ubuntu-vm
count: 1
cfengine: 3.24.3
bootstrap: cloud-hub
- static-hosts:
role: client
cfengine: 3.24.3
hosts: [ ubuntu@8.8.8.8, ubuntu@1.1.1.1 ]
bootstrap: cloud-hubAnother alternative instead of |
I agree that this looks cleaner. However doesn't it sacrifice some "power" and flexibility if we want to add more features in the future? Why precising the provider two times if you mentioned that there should only be one provider option per spawn-config? I think having fully reproducible configs would be useful, especially in a dev environment. For example, if in ./provision.sh script you use some package with a version and your share your cf-remote config, it's not sure that the installed softwares would have the same version. Scripts and static hosts can break reproducibility. We could track the scripts with git. Lastly, I think that instead of being fixed, the config should be modular. I believe this: should be synonymous to: Basically, you could create "aliases" to repeat some configuration in a modular way. Not only for spawn-config. |
Signed-off-by: Victor Moene <victor.moene@northern.tech>
| ## Idempotency: | ||
| The user defines a desired state in the form of a config in yaml, and cf-remote makes it a reality. If run against an existing environment, it detects changes and 'repairs' the current state using the configuration. |
There was a problem hiding this comment.
| ## Idempotency: | |
| The user defines a desired state in the form of a config in yaml, and cf-remote makes it a reality. If run against an existing environment, it detects changes and 'repairs' the current state using the configuration. | |
| ## Idempotency | |
| The user defines a desired state in the form of a config in yaml, and cf-remote makes it a reality. | |
| If run against an existing environment, it detects changes and 'repairs' the current state using the configuration. |
|
|
||
| ## Example | ||
|
|
||
| ``` |
There was a problem hiding this comment.
| ``` | |
| ```yml |
|
|
||
| To apply the config: | ||
|
|
||
| `cf-remote up config.yaml` |
There was a problem hiding this comment.
This part should be in triple backticked code block with bash as the language.
| To apply the config: | ||
|
|
||
| `cf-remote up config.yaml` | ||
|
|
There was a problem hiding this comment.
Add information about how to bring down an environment / destroy VMs.
Maybe add some example (invented) output of how it should look when you run the up command?
2 participants
No description provided.