Working with Cloud-init
Working with Cloud-init
Creating cloud-init user configs
api.user_configs.create() requires name, kind, and content.
The content argument is flexible and accepts any of:
- a literal string (used verbatim, never interpreted as a file path),
- a
pathlib.Pathpointing to a file to read, or - an open file handle.
Setting up a simulation with nodes
Cloud-init configs are assigned to nodes within a simulation. Here we create a small simulation with two nodes to assign the configs to.
Assigning cloud-init configs to nodes
Assignments are made with the v3 bulk-assign API, simulation.node_bulk_assign().
Each entry maps a node to its user_data and/or meta_data config. Values may be
UserConfig objects, config IDs, or None to clear an existing assignment.
node_bulk_assign() accepts many entries in a single call, so you can configure a
whole simulation at once and reuse the same UserConfig across nodes.
Reading back an assignment
A node’s current cloud-init assignment is available on the node.cloud_init property,
which exposes the assigned user_data and meta_data configs.
Updating cloud-init content
A node’s assignment points to a UserConfig rather than copying its content, so
updating a config’s content automatically applies to every node it’s assigned to —
no reassignment needed.
When does cloud-init take effect?
Cloud-init is consumed on the node’s next boot. Assign your configs before starting the simulation, or rebuild the node afterward for the changes to take effect on an already-running node.
Clearing an assignment
Pass None for a config in node_bulk_assign() to remove it from a node — set a
single field to clear just that one, or both to clear the node’s cloud-init entirely.
Cleaning up
Delete the simulation and the UserConfig resources created above. Deleting the
simulation removes its nodes; the configs are separate resources and must be deleted
explicitly (do this only if they are not assigned to other simulations).