[09:02] <rauno> hi
[09:02] <rauno> struggling with cloudinit with debian8 virtual machine, somewhy it doesn't find the config provided via configdrive
[09:03] <rauno> seems to be quite old version also 0.7.6 in this image
[09:03] <rauno> it still tries to find it from  Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed
[10:51] <mjh> Hi all, I hope this is the right place to ask a question about cloud-init usage particularly with regards to aws. The number of additional block devices for our instances is a variable depending upon environment. I would like to format and mount all unused block devices under /data/0 /data/1 etc. I cant see a way to do this in the given examples and my google foo has not been powerful enough.
[10:54] <cesarjorge> Hi, in my cloud-init logs I see the following:
[10:54] <cesarjorge> stages.py[WARNING]: Could not find module named cc_resolv_conf_authkey_fingerprints (searched ['cc_resolv_conf_authkey_fingerprints', u'cloudinit.config.cc_resolv_conf_authkey_fingerprints'])
[10:55] <cesarjorge> What does this warning mean and how is it solved?
[11:11] <mjh> hi cesarjorge. I'm new to cloud-init but I cant find a authkey_fingerprints key for cc_resolv_conf. Is this a typo maybe somehow pulling in cc_ssh_authkey_fingerprints?
[11:13] <cesarjorge> I don't know, but I use in cloud.cnf the following init module - resolv-conf
[11:14] <cesarjorge> And not use nothing for cc_ssh_auth...
[11:14] <mjh> are you able to post your configuration - I'm happy to compare with what I have.
[11:14] <mjh> ah...
[11:16] <cesarjorge> I use the default config file, except, that I add this - resolv.conf in init section
[11:17] <mjh> sorry, we both appear to be a bit lost :-/
[11:19] <cesarjorge> cloud-init-0.7.9-9.el7.centos.2.x86_64
[11:19] <cesarjorge> Other fail:
[11:19] <cesarjorge> My image by default use swap partition as:
[11:20] <cesarjorge> # /dev/mapper/centos_centos-swap swap                    swap    defaults        0 0
[11:20] <cesarjorge> When cloud-init start:
[11:20] <cesarjorge> systemd-fstab-generator[1334]: Failed to create swap unit file /run/systemd/generator/dev-mapper-centos_centos\x2dswap.swap, as it already exists. Duplicate entry in /etc/fstab?
[11:21] <cesarjorge> Then in VM:
[11:21] <cesarjorge> The cloud-init add this:
[11:22] <cesarjorge> # /dev/mapper/centos_centos-swap	none	swap	sw,comment=cloudconfig	0	0
[11:30] <cesarjorge> Howto workaround this problem?
[12:29] <mdt[m]> hi, i just struggled over cloud-init and would like to understand its concepts. i wonder where i can find a highlevel document about its flows and concepts. did i miss something?
[12:52] <CodexRaptr> go for cloud-init.io
[12:54] <mdt[m]> i checked that page, sure. as i do not run cloud-init in aws or such but on my notebook i need some deeper insides in the flows. i am missing this from that page.
[12:55] <mdt[m]> i just installed the cloud-init package into my debian based virtual machine image - i assume i need a server outside providing the meta data? where is that concept explained?
[14:24] <smoser> mdt[m]: cloud-init needs to find a "datasource".  a datasource is
[14:24] <smoser>  http://cloudinit.readthedocs.io/en/latest/topics/datasources.html
[14:41] <mdt[m]> smoser: ok, now i can relate that... thank you. so first step (before cloud-init) is always dhcp to get a working network?and how will the different nodes be differentiated on the meta-data-server? by mac?
[15:06] <smoser> mdt[m]: well that is entirely up to the platform.
[15:07] <smoser> cloud-init does not always dhcp on the first nic now. on certain platforms it reads metadata for network configuration from the datasource (not all datasources require network).
[15:07] <mdt[m]> smoser: so what are usual patterns?
[15:08] <mdt[m]> ah, ok, which other datasources (i saw kernel params already) are possible?
[15:08] <mdt[m]> (ah, and i saw iso media as well)
[15:09] <smoser> well, i'm not privy to how Azure or GCE or Amazon platforms hook up  networking and all.
[15:10] <smoser> to automate things locally without a "full blown cloud", you can use the NoCloud datasource
[15:11] <smoser> i have some examples of using those at https://asciinema.org/~smoser
[15:11] <mdt[m]> my current interest is to learn here on my notebook (where i could establish a network datasource as well) and be prepared to either a vmware environment or aws
[15:12] <mdt[m]> oh, thank you, i will take a look...
[15:14] <mdt[m]> (and cool stuff with asciinema, it allows cut&paste, i personally dont like these yt vids from screens)
[15:15] <smoser> yeah, asciinema (outside of being really hard to type) is really nice.
[15:15] <smoser> also, see the urls in the descriptions, they point to gists on github that have the fiels there for you.
[15:16] <smoser> oh. i see that the debian does not. https://asciinema.org/a/145772 points to gist.
[15:17] <mdt[m]> ok (debian was the first i looked at)
[15:26] <mjh> hi, please can I have a quick hand with the cloud-init commandline. I wish to re-run configuration of disks from a local configuration file. I run: /usr/bin/cloud-init --debug single --name disk_setup --frequency always and I get the volumes formatted but not mounted.
[15:31] <mjh> sorry - found it, I did not twig that is was a separate module.
[15:39] <mjh> It would be really nice if I could mount _all_ unformatted disks under a given dir. please let me know if i am missing something.
[15:41] <dpb1> mjh: mount all unformatted disks? what kind of magic is this? :)
[15:42] <mjh> :-)
[15:44] <mjh> depending on aws environment I may have 0 1 or 2 additional block devices for elasticsearch. I want all of them formatted and mounted under /data/ with the minimum of customisation between environments. So as it stands I am using a pre-service to elasticsearch to write out a could init configuration which I am then running. feels yuck but probably more rubust than writing a format / mount script myself.
[15:45] <smoser> blackboxsw: you left bug numbers in on the changelog.  we cna just roll them into the existing sru. did you want to do those 3 individually?
[15:45] <smoser> wrt https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/337515
[15:46] <smoser> mjh: there isnt anything there. i agree that'd be a nice feature.
[15:46] <mjh> :-) hey ho
[15:48] <dpb1> mjh: ya, I think it's a neat idea.  sounds like zfs. :)
[15:48] <dpb1> (one aspect of zfs anyway)
[15:50] <mjh> not sure about zfs (or lvm) for this, it would still require robust scripting and I'm not sure that I like the idea of striping over remote aws block devices (I probably did not mention this was on aws...)
[15:51] <dpb1> mjh: I mean that when you create zfs filesystems, they automatically get mounted under a particular path.
[15:51] <mjh> I get you.
[15:52] <dpb1> mjh: I like your idea about a nice easy way of saying "automount all unformatted storage using ext4" in the config.
[16:37] <blackboxsw> smoser: artful and xenial pushed for 17.2.35 https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/337516 https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/337515
[16:37] <blackboxsw> testing an azure deployment with preprovision flag now
[16:44] <smoser> blackboxsw: sory...
[16:44] <smoser> you need to have the new chagnelog entry and version
[16:44] <smoser> (we can't re-upload the same version again)
[16:44] <smoser> you can just strip the bug numbers out
[16:44] <smoser> and we'll add the new chagnelog entry to the sru branch
[17:00] <blackboxsw> smoser: I misremembered fixing
[17:00] <blackboxsw> and making not
[17:00] <blackboxsw> and making note
[17:00] <blackboxsw> for some reason I thought since we were replacing and not officially releasing to non-proposed that was an option. but I suppose we already officially published to -proposed. so, makes sense
[17:06] <blackboxsw> smoser: shall I move the SRU bug to the new changelog entry or leave it on the previous changelog New upstream snapshot. (LP: #####)
[17:17] <smoser> blackboxsw: sorry for slow reply.
[17:18] <smoser> leave the old one in place. just put the sru bug on the new commit also i guess.
[17:22] <blackboxsw> smoser: just pused
[17:22] <blackboxsw> pushed even
[17:43] <blackboxsw> thx smoser
[17:43] <blackboxsw> saw unapproved float by
[17:45] <smoser> the other is on its way
[19:10] <blackboxsw> rharper: confirmed my azure pre-provision instance is still timing out /looping :)
[19:10] <blackboxsw> so it is indefinite wait until IMDS tells the instance things are ready /accessible
[19:10] <blackboxsw> non-404
[19:10]  * blackboxsw grabs a bit of lunch
[19:16] <rharper> blackboxsw: cool, yeah, the updated branch is a replacement for what's in trunk now; that was one of the reasons I was confused.  I'm reviewing it now.
[19:16] <rharper> https://code.launchpad.net/~tamilmani1989/cloud-init/+git/cloud-init/+merge/336392
[19:49] <smoser> blackboxsw or rharper can i get a review of https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/337100
[19:49] <smoser> i'd like to have that landed.
[19:49] <smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/337471 should also be striaght forward
[20:44] <blackboxsw> reviewing them
[20:49] <blackboxsw> smoser: why are we not patching sys.exit for other with self.assertRaises calls throughout cloud-init unit tests? https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/337471
[20:49] <blackboxsw> ha! n/m there aren't any
[20:49] <blackboxsw> disregard
[20:49] <blackboxsw> landing
[21:59] <blackboxsw> smoser: do we need  comparable writable/system-data support in cloudinit/sources/DataSourceNoCloud.py for your https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/337100 or do we assume the race condition w/ bindmount is long since past by the time cloud-init datasources get there
[22:00] <blackboxsw> n/m: "It is guaranteed at cloud-init-local.service time"
[22:00] <blackboxsw> ok landing