[14:13] <sidx64> Hello! I'm new to cloud-init and I am using this with an openstack set up, to run some commands (create a specific user, etc) after VM is created. I was wondering if there was a way to run Cloud-init on the same VM without rebooting it ?
[14:48] <sidx64> never mind, I found it here: https://gist.github.com/maoueh/8662b8e0da0ccd99296a9a9a6b67dad0
=== rharper` is now known as rharper
[15:26] <brunobro_> I'm trying to find a good pattern for using cloud-init to provision Raspberry Pi devices.
[15:36] <brunobro_> I found that the Raspbian repo had 0.7.9 and that lacked the more in depth NoCloud features. So, I figured out how to install from source. https://stackoverflow.com/a/48845732/117471
[15:42] <brunobro_> So at this point I'm trying to use /var/lib/cloud/seed/nocloud-net/ because it is pretty easy to get some positive feedback. But, I'm struggling to get the solution I need.
[15:42] <brunobro_> I really have 2 goals:
[15:44] <brunobro_> 1. Have the `user-data` and `meta-data` files live on the volume labeled `boot` that is mounted at `/boot`
[15:45] <brunobro_> 2. Have a script (/boot/on_boot.sh) called on every boot if it exists.
[15:46] <brunobro_> That's it. But, I'm facing these challenges:
[15:47] <brunobro_> 1. /var/lib/cloud/scripts/per-boot seems to do nothing for me.
[15:48] <brunobro_> 2. Changes to `/boot/user-data` are not picked up by the `#include` directive in `/var/lib/cloud/seed/nocloud-net/user-data`
[15:56] <brunobro_> 3. The `meta-data` file does not seem to support `#include` so I'm stuck with whatever goes into `/var/lib/cloud/seed/nocloud-net/meta-data`
[15:59] <brunobro_> 4. Putting ` ds=nocloud[;seedfrom=/boot/;instance-id=raspberrypi]` at the end of `/boot/cmdline.txt` did not seem to make it locate `/boot/user-data` and `/boot/meta-data`. That is why I am using `/var/lib/cloud/seed/nocloud-net/`.
[15:59] <brunobro_> I think that covers it.
[16:19] <rharper> brunobro_: can you share your cloud-init.log ? /var/log/cloud-init*.log
[16:22] <blackboxsw> sidx64: on cloud-init v 17.1 or later you can run "cloud-init clean --logs"   instead of those rm -rf lines. Also it'd be worth checking your initially provisioned datasource name in /run/cloud-init/result.json.  If it is a datasource with Local in the name you might have to run "cloud-init init --local" before "cloud-init init"
[16:23] <sidx64> thankyou @blackboxsw
[16:23] <sidx64> will tryu this
[16:24] <blackboxsw> no prob: otherwise you risk using a cached local datasource which wouldn't update metadata (if your metadata has changed)
[16:25] <sidx64> Oh okay!
[16:25] <sidx64> Did not know that!
[16:25] <sidx64> I actually have been changing the metadata
[16:25] <sidx64> so this helps a lot!
[16:25] <sidx64> thank you
[16:26] <rharper> brunobro_: you may want to instead label your  volume 'cidata';  and cloud-init will find that volume and read it like the nocloud-net seed in /var/lib/cloud/seed/noncloud-net instead
[17:02] <brunobro_> rharper: I can't relabel the volume. It is the boot volume. I'm not going to try to convince the Raspbian distribution to change their volume name. But, there is supposed to be a way to tell cloud-init somewhere else to look.
[17:02] <rharper> brunobro_: ok
[17:03] <rharper> brunobro_:  so, no wait to tell cloud-init to find a nocloud-net datasource somewhere else; but in the embedded seed, you should be able to refer to your volume for additional sources of user-data
[17:03] <rharper> s/wait/way
[17:07] <brunobro_> rharper: I added logs to https://gist.github.com/RichardBronosky/fa7d4db13bab3fbb8d9e0fff7ea88aa2
[17:08] <rharper> thx
[17:14] <brunobro_> what can I do about per-boot?
[17:23] <rharper> brunobro_: looking at the logs;
[17:36] <rharper> brunobro_: from the logs, I think it's not finding your nocloud seed in /boot;  it emits the "Using Fallback Datasource" which isn't going to run your user-data that was provided;
[17:36] <rharper> next to see why the seedfrom=/boot didn't work for you
[17:36] <rharper> I need to look at the cloud-init NoCloud source to see how it processes that
[17:40] <brunobro_> rharper: What should a "nocloud seed" in /boot look like? I never can get clear info on the directory structure expectations.
[17:42] <brunobro_> http://cloudinit.readthedocs.io/en/latest/topics/dir_layout.html says that "seed/" is TBD and "scripts/" is also pretty vague.
[17:45] <rharper> brunobro_: /boot/{meta-data,user-data} ; I think you've that part correct;
[17:47] <brunobro_> okay, good. I originally did /var/lib/cloud/seed/{meta-data,user-data} and that did not work. But I found a blog example that told me about nocloud-net
[17:47] <rharper> so, it's /var/lib/cloud/seed/nocloud-net/{user-data, meta-data}
[17:48] <rharper> and you may have something in there; the stacktrace looks like it was comparing the instance_id found in one of the two meta-data files, and they didn't match;
[17:48] <brunobro_> I do have both of those populated.
[17:49] <rharper> I've never tested having multiple locations and referencing them both
[17:49] <rharper> so I suspect we need to pick one location and getting your config working
[17:52] <rharper> I think if you remove /var/lib/cloud/seed/nocloud-net and then 'cloud-init clean' to remove any per-instance generated data from /var/lib/cloud and logs; and reboot; that should get things goign if your gist is accurate
[17:52] <brunobro_> I don't intend to have multiple. I'm experimenting. And not remembering what artifacts I've left around.
[17:53] <rharper> the seedfrom=/boot allows nocloud datasource to read that directory like it's a nocloud source; your files look fine w.r.t meta-data and user-data;
[17:53] <rharper> if that works, then we can move to getting your scripts to run;
[17:53] <rharper> I'm stepping out for lunch, but just let me know how it goes and I'll see what I can do to get your going
[17:53] <brunobro_> thanks!
[19:40] <brunobronosky> rharper this is brunobro_ from earlier. (I didn't have a ZNC container running before.)
[19:40] <rharper> brunobronosky: hi
[19:41] <brunobronosky> I'm updating that gist to make it more accurate. i will also purge the logs and start them fresh. I'll let update you shortly. But for now I'll lead with a question...
[19:44] <brunobronosky> In the log I'm seeing "2018-02-20 18:05:39,432 - main.py[DEBUG]: No kernel command line url found." even though `cat /proc/cmdline` gives...
[19:44] <brunobronosky> 8250.nr_uarts=0 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=PARTUUID=3e8f7ed9-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait ds=nocloud[;seedfrom=/boot/;instance-id=iid-raspberrypi-nocloud]
[19:45] <rharper> brunobronosky: lemme look
[19:45] <brunobronosky> that last KV pair is my interpretation of the docs http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html
[19:47] <rharper> brunobronosky:  I don't think that is related, the code is looking for  'cloud-config-url', 'url'  keys in the kernel command line for
[19:48] <rharper> it's used in a read-only-root configuration with MAAS, a baremetal cloud product
[19:49] <rharper> brunobronosky: you should see something like
[19:49] <rharper> Looking for data source in: ['NoCloud', 'None'], via packages ['', 'cloudinit.sources'] that matches dependencies ['FILESYSTEM']
[19:49] <rharper> 2018-02-15 16:23:32,828 - __init__.py[DEBUG]: Searching for local data source in: ['DataSourceNoCloud']
[19:49] <rharper> 2018-02-15 16:23:32,828 - handlers.py[DEBUG]: start: init-local/search-NoCloud: searching for local data from DataSourceNoCloud
[19:52] <brunobronosky> The use of "url" concerns me. Can it accept a local file path? (maybe with the file:// scheme?)
[20:11] <brunobronosky> Okay rharper https://gist.github.com/RichardBronosky/fa7d4db13bab3fbb8d9e0fff7ea88aa2#file-cloud-init-log is current.
[20:12] <rharper> brunobronosky: thanks, reading
[20:14] <brunobronosky> Also, I'm seeing https://github.com/cloud-init/cloud-init/blob/master/doc/sources/kernel-cmdline.txt is consistent with your description. Though, both you and smoser are inconsistent with my understanding of http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html
[20:17] <brunobronosky> I didn't want to trouble you with my lack of understanding when you said, "I don't think that is related" earlier. I think that is more important than I originally presumed. I guess my follow up should be "You don't think what is related to what?"
[20:17] <rharper> the message comes code looking for cloud-config-url, which is used separately from the NoCloud Datasource,
[20:17] <rharper> it's not related to the current failure
[20:21] <brunobronosky> Got it. So, the part of the docs that I am hanging onto... Are they valid? Does that mean what I think it means? Inigo Montoya?
[20:21] <rharper> I think so, I'm looking at cloudinit/sources/DatasourcesNoCloud.py:parse_cmdline_data
[20:21] <rharper> to see what, if anything it doesn't like
[20:24] <rharper> I think the brackets
[20:25] <rharper> [ ] means the contents are optional
[20:25] <rharper> you can use: ds=nocloud   or ds=nocloud;seedfrom=;instance-id=bar
[20:25] <rharper> adjusting it
[20:25] <brunobronosky> GAH!!
[20:25] <rharper> parse_cmdline_data('ds=nocloud', fill, cmdline=cmdline)
[20:25] <rharper> True
[20:25] <rharper> >>> fill
[20:25] <rharper> {'instance-id': 'iid-raspberrypi-nocloud', 'seedfrom': '/boot/'}
[20:26] <rharper> brunobronosky: I think it's worth an update to documentation to show an example there
[20:26] <brunobronosky> Yes! Moar Examples everywhere!
[20:27] <rharper> =)
[20:32] <brunobronosky> woohoo! it created /var/lib/cloud/instances/iid-raspberrypi-nocloud that time.
[20:32] <rharper> \o/
[20:37] <brunobronosky> Now I'm wondering about this /var/lib/cloud/scripts/per-boot thing
[20:38] <brunobronosky> for one. I noticce that it gets wiped out on `cloud-init clean`
[20:41] <rharper> yes, clean wipes the system to make it like "new" to cloud-init
[20:45] <rharper> right, per-boot;
[20:46] <brunobronosky> holy carp! per-boot is working now.
=== r-daneel_ is now known as r-daneel
[21:39] <brunobronosky> This is working pretty smooth. I've got per-boot working as a symlink to /boot/per-boot.sh
[21:40] <brunobronosky> Now I need some design advice.
[21:40] <brunobronosky> I guess I should describe the greater project at this point. I'll try to keep it short.
[21:49] <brunobronosky> In 6 days, this project will be 5 years old! https://www.raspberrypi.org/forums/viewtopic.php?t=35224 The basic goal is to have a script in the vfat /boot partition of a newly imaged Raspbian microSD card that will get run on boot.
[21:50] <brunobronosky> I've done this lots of ways over the years (mostly using rc.local) building dozens of single purpose machines.
[21:53] <brunobronosky> My projects have been forked and reused and I'm feeling kind of bad about spreading bad habits. I've decided finally do it right and get it accepted into Raspbian. My options were to create my own oneshot systemd service, or use cloud-init. I'd like to keep it as Standard™ as possible. So, I'm leaning towards this.
[21:56] <blackboxsw> well you're in good company here :) it's right in cloud-init's wheelhouse
[21:57] <brunobronosky> Some other users have expanded my original intent to have both an "on-boot.sh" and a "run-once.sh". Both of them get run if they are present, but the later gets renamed run-once.$(date +%F@%H.%M.%S) after execution.
[21:59] <brunobronosky> So here is the design question (finally): implementing my on-boot.sh with /var/lib/cloud/scripts/per-boot is pretty simple. Should I try to implement run-once.sh with /var/lib/cloud/scripts/per-once or stray from the cloud-init Standard™ for that?
[22:02] <brunobronosky> my meaning of per-once is "per once, every time it reappears", and cloud-init's meaning of per-once is "per once, ever, dammit". (at least from what I can tell)
[22:02] <blackboxsw> brunobronosky: I'm wondering why not per-instance instead of per-boot? per-boot is every boot
[22:04] <blackboxsw> per-instance would only fire again if your NoCloud seed directories provide a different instance-id
[22:04] <blackboxsw> and it wouldn't fire again across reboots
[22:04] <blackboxsw> unless that data changed
[22:07] <blackboxsw> or per-once might actually be what you need right, sorry because you only want to do that once ever
[22:08] <blackboxsw> as long as your workflow never runs "cloud-init clean"  per-once scripts will never fire again after that first boot
[22:09] <brunobronosky> So, the target audience for this is students and teachers. I'm trying to both make it easy and teach good practices... fine line. I want there to a script that runs on every boot, because a LOT of users want that.
[22:10] <brunobronosky> The per-instance is interesting. I didn't know the difference between per-once and per-instance. that gives me something to think about.
[22:12] <brunobronosky> And yes, the per-boot is basically like rc.local, and that is the point. The difference is that a Windows (or Mac) user can mount the vfat partition and edit files in the /boot folder, but they cannot get to /etc.
[22:13] <blackboxsw> if you don't expect metadata in the seed directory to change between boots when provisioning, per-instance effectively behaves like per-once.
[22:14] <blackboxsw> yeah per-boot is probably what most folks would want;  in their own per-boot script they'd be able to change behavior to only perform an operation once if they want to.
[22:14] <blackboxsw> well, it least if gives the most flexibility I suppose.
[22:18] <brunobronosky> So, is it terrible of me to use the names /boot/per-boot.sh and /boot/per-once.sh even though my per-once is totally different? Am I doing the student a disservice?
[22:19] <brunobronosky> I just really like the consistency of the per-* and that they will sort together for the student to find.
[22:20] <rharper> brunobronosky: it could be useful to bikeshed a name for per-every-occurance.sh or something
[22:20] <rharper> I do think the per-once (and only once per instance) is pretty straightfoward in the cloud-init space; though I think outside of cloud-init , the 'instance' concept is not quite as clear
[22:24] <brunobronosky> rharper yes, instance is totally unclear outside of the cloud paradigm.
[22:25] <brunobronosky> I'd love to have rpi clusters be a gateway for teaching cloud concepts... but that is a big bite for a beginner.
[22:26] <rharper> brunobronosky: it may be useful then to include a script in your per-boot.sh which does an existance check on some directory, and if present call run-parts on it;
[22:27] <rharper> so you can tell users, if they create a directory named something your per-boot checks, it'll then call run-parts on it (which just executes any scripts/programs marked executable )
[22:27] <brunobronosky> nice!
[22:28] <brunobronosky> (eveything is executable on vfat)
[22:31] <brunobronosky> well, mount mask 0022 so...
=== brunobronosky is now known as brunobron-afk
[22:47] <rharper> brunobron-afk: lol @ vfat