You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 16, 2020. It is now read-only.
First of all it would be useful to have access to certain pieces of information about the instance in the cloud-init file that initialises that instance, for example, what its hostname is, what its ip address is, what the gateway ip address is, etc. Controller has all of this information available but it does not pass it to the cloud-init file.
The files themselves are too static. This means that if you have two workloads that are almost identical except for one small change, let's say you wanted to test the same workload on ubuntu and fedora, you'd need to create four separate yaml files and 2 separate workloads.
It would be nice if the workload definitions were more dynamic. This could be achieved by allowing the user to use Go templates inside workload definitions as we do in ciao-down.
Some of the information available to the template scripts would be passed directly from controller, but perhaps some could be provided by the user when launching an instance, e.g.,
Another piece of information that would be useful to pass to the workloads would be proxy information. Proxy settings could be stored in the cluster configuration file and then passed to the cloud-init scripts when creating a new instance. This would allow ciao workloads to handle proxies as gracefully as ciao-down workloads do.
There are a couple of problems here:
First of all it would be useful to have access to certain pieces of information about the instance in the cloud-init file that initialises that instance, for example, what its hostname is, what its ip address is, what the gateway ip address is, etc. Controller has all of this information available but it does not pass it to the cloud-init file.
The files themselves are too static. This means that if you have two workloads that are almost identical except for one small change, let's say you wanted to test the same workload on ubuntu and fedora, you'd need to create four separate yaml files and 2 separate workloads.
It would be nice if the workload definitions were more dynamic. This could be achieved by allowing the user to use Go templates inside workload definitions as we do in ciao-down.
Some of the information available to the template scripts would be passed directly from controller, but perhaps some could be provided by the user when launching an instance, e.g.,
ciao-cli instance add --workload d6e3fddd-8f21-4147-b55f-115ae772fba0 -data="command:apt-get update" -data "command:apt-get install redis-server"
And then in our cloud-init file, we'd have something like
We might also have something like
Which would allow a user to override a default image of a workload on the command line, e.g.,
ciao-cli instance add --workload d6e3fddd-8f21-4147-b55f-115ae772fba0 -data="image:3dbe6806-3faf-4d48-ad7c-2fcb86a0e798"
This would be another way of addressing #1481
The text was updated successfully, but these errors were encountered: