| esv | is there a particular trick to make "cloud-init single --name=disk_setup --frequency=always" work as if the VM were starting for the 1st time? | 12:46 |
|---|---|---|
| minimal | esv: are you wanting disk_setup to run on every boot? | 13:30 |
| esv | I'm trying to build an automatic evaluation process for a cloud-init class | 13:38 |
| minimal | is that a yes or a no? | 13:39 |
| esv | was a no. | 13:39 |
| esv | I am trying to make it work for a very specific purpose | 13:39 |
| minimal | ok, I had an answer if it was a "yes" ;-) | 13:39 |
| esv | was it "are you insane?"" | 13:40 |
| minimal | nope | 13:40 |
| esv | we have an on-demand cloud-init class for our support engineers, so we're switching to a hands-on evaluation of it. Since one of the topics is how to create a custom layouts using c-i, I wanted to test that. | 13:43 |
| minimal | esv: oh, so you're not doing a "cloud-init clean" before you run your command? | 13:45 |
| esv | cloud-init single fails miserably when I do that. | 13:45 |
| minimal | never used "single" so can't help with that | 13:46 |
| esv | I can use what I have now, thx | 13:46 |
| blackboxsw | esv: I may not be understanding, but for easy/interable testing of various cloud-configs for different layouts. I'd propose trying to use lxd with. kvm you can easily setup kvm instances in lxd adding mulitple storage devices prior to instance launch and you can provide lxc config your-vm -c cloud-init.user-data="$(cat some.yaml)" at launch that contains your specialized disk_setup stuff | 13:46 |
| minimal | do the cloud-init.log not show any problems? | 13:47 |
| blackboxsw | an example of lxd setup can be pieced together from https://github.com/canonical/cloud-init/blob/main/tests/integration_tests/modules/test_disk_setup.py#L56 | 13:48 |
| esv | it shows the layout to be a single partition. | 13:48 |
| minimal | esv: and your user-data contents for disk_setup didn't specify a single partition? | 13:49 |
| esv | https://paste.opensuse.org/pastes/1a3ba74b69b4 | 13:52 |
| minimal | so was the 99-swapspace.cfg file created after the machine originally booted? | 14:00 |
| esv | yep, it does the trick to manage the ephemeral resource in Azure, not completely understand how that stuff works | 14:04 |
| esv | I'll have to do with what I have or find a way to manipulate the state of the VM while testing. | 14:05 |
| minimal | so during normal boot (blackboxsw correct me if I'm wrong) cloud-init will merge user-data and any relevant /etc/cloud/ config and place the result in /var/run/cloud-init/ where it willb e used by the modules, so adding a file to /etc/cloud/cloud.cfg.d/ AFTER boot and then just running a single module (not "reinitialising" cloud) will use the config from /var/run/cloud-init and therefore not see/use the contents of the new file in /etc/cloud/cloud.cfg. | 14:07 |
| minimal | d/ | 14:07 |
| blackboxsw | minimal: yes very close to correct, single will run and fetch the datasource's cached merged configuration from /var/lib/cloud/instance/obj.pkl which was already processed at datasource discovery. You **can** see the merged config in newer cloud-init from /run/cloud-init/combined-cloud-config.json which likely will show you your new config isn't "seen" | 14:16 |
| minimal | blackboxsw: ah got the patchs wrong as didn't have VM handy to consult (doing the annoying post-Virtualbox-update "get their external modules signed in order to work with SecureBoot dance" lol) | 14:22 |
| === fabiomirmar_ is now known as fabiomirmar | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!