Conversation
|
@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> Sketching cf-remote idempotent config Signed-off-by: Victor Moene <victor.moene@northern.tech>
Signed-off-by: Victor Moene <victor.moene@northern.tech>
No description provided.