[07:23] <nils_> am I correct in assuming that users are created before disk-setup is run? If I needed to put the home directories for users on a different device then I should have the device mounted and formatted in bootcmd?
[08:03] <felipe_1982_> I am running bookhook scripts in AWS, and the "echo" is not getting logged in /var/log/cloud-init-output.log as the documentation would suggest. Running Amazon Linux 2.
[11:46] <Odd_Bloke> rharper: Hmm, I was going to suggest cc_growpart/cc_resizefs for the partition expansion question from yesterday, but it looks like cc_resizefs _only_ resizes the root FS.
[13:03] <lfain> What is the recommended way to access vendor data in a pre-installed cloud-init script? Right now, I get it by calling http://169.254.169.254/openstack/2018-08-27/meta_data.json but I'm looking for a generic method that will work with any datasource type.
[14:08] <Odd_Bloke> lfain: o/ What do you mean by a "pre-installed cloud-init script"?  You may want to look at `cloud-init query`.  (Run `cloud-init query -a` to see all the instance-data.)
[14:17] <rharper> Odd_Bloke: yeah,  it's always been root volume only;
[14:19] <rharper> nils_: look at /etc/cloud/cloud.cfg , 'cloud_init_modules' shows the order in which they run;  users-groups is next to last, and runs after disk_setup and mounts; which you'll need both to create the disks/partitions to hold the user dirs and then mount entries to mount before the user is created.
[14:23] <nils_> rharper, it may be the ancient version bundled with CentOS, in my case users-groups is last in cloud-init-modules, mounts is first in cloud-config-modules
[14:24] <Odd_Bloke> rharper: Right, but growpart supports non-root volumes, so the discrepancy caught me off-guard.
[14:24] <Odd_Bloke> I guess at _first_ boot, you generally won't have filesystems on anything but your root volume.
[14:24] <rharper> nils_: that's ... odd
[14:25] <Odd_Bloke> tribaal: https://bugs.launchpad.net/cloud-init/+bug/1839854 <-- as a CloudStack(-ish) operator, I'd love your thoughts on this bug
[14:25] <ubot5> Ubuntu bug 1839854 in cloud-init "CloudStack provider cannot determine correct metadata IP with multiple network interfaces" [Undecided,New]
[14:25] <rharper> Odd_Bloke: it's possible that secondary disks could be partial, but unlikely; the resize was mostly about using cloud images overtop a later device
[14:25] <lfain> I made a custom image where I put a script in the /var/lib/cloud/scripts/per-instance/ folder. This script uses parameters that I provide via the meta data.
[14:26] <rharper> lfain: you may want your script to read /run/cloud-init/instance-data.json then; that has the instance metadata available
[14:39] <lfain> rharper: I forgot to write that the image is based on CentOS7 with cloud-init v.18.2 installed. Therefore, I can not run "cloud-init query"   and the /run/cloud-init/instance-data.json also is not available.
[14:40] <rharper> hrm
[14:40] <lfain> Is there a way to install latest cloud-init on CentOS7? I didn't find RPMs for it.
[14:40] <rharper> https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/   we do have daily rpm builds;
[14:41] <rharper> https://copr.fedorainfracloud.org/coprs/g/cloud-init/el-testing/packages/
[14:41] <rharper> has 19.2
[14:45] <lfain> Thank you, rharper. I'll try 19.2. If I run into a problem, then I will return back to my current method (that I don't like...)
[14:48] <rharper> lfain: cool!
=== lfain1 is now known as lfain
[17:04] <AnhVoMSFT> Hi folks, I have a CI build failed for this MP https://code.launchpad.net/~vtqanh/cloud-init/+git/cloud-init/+merge/369785 but the link does not work for me so I can't see what went wrong
[17:51] <rharper> AnhVoMSFT: let me see and I'll let you know
[18:01] <AnhVoMSFT> thanks rharper
[18:06] <rharper> AnhVoMSFT: looks like a harness issues, I'll rerun the job
[18:08] <AnhVoMSFT> thanks
[18:34] <AnhVoMSFT> rharper I got disconnected from IRC but it looked like CI build failed again
[18:34] <rharper> AnhVoMSFT: yes, tracking issue down on our side
[18:35] <rharper> I've poked at jenkins; so this next run should work; but you won't need to do anything; we'll make sure it runs to completion , and if there's an issue in the branch, I'll let you know
[18:46] <Odd_Bloke> rharper: blackboxsw: What is the relation between /v/l/cloud/instance/user-data.txt and user-data.txt.i?
[18:52] <AnhVoMSFT> thanks rharper
[18:59] <rharper> Odd_Bloke: I'd have to look, I thought it was something to do with mime wrappers
[19:00] <rharper> ah, userdata_raw => user-data.txt ,   "processed user-data" => user-data.txt.i
[19:00] <rharper> Odd_Bloke: see cloudinit/stages.py:def _store_userdata()
[19:08] <AnhVoMSFT> looks like it passed this time
[19:18] <rharper> AnhVoMSFT: yeah, I'll review
[19:21] <Odd_Bloke> rharper: Did you get to the bottom of that mkdir cloud_tests error?
[19:23] <rharper> Odd_Bloke: yes; lxd snap on the host needed someone to sudo mkdir a path that we use
[19:23] <rharper> I suspect the upgrading/updating may have removed it from the common dir
[19:23] <Odd_Bloke> Aha, OK, thanks!
[19:24] <Odd_Bloke> Glad I asked, else I was going to spend 3 hours on triage today. :p
[19:25] <powersj> O.o
[20:16] <blackboxsw> rharper: Odd_Bloke care if I publish cloud-init to eoan again (now that Azure v2 networking is landed
[20:17] <blackboxsw> or shall we wait on OCI
[21:20] <blackboxsw> Odd_Bloke: LGTM https://code.launchpad.net/~daniel-thewatkins/cloud-init/+git/cloud-init/+merge/371053 minor comments/questions for clarification but nothing blocking
[21:42] <Odd_Bloke> blackboxsw: Good points, I'll fix those up first thing tomorrow.