[09:02] hi [09:02] struggling with cloudinit with debian8 virtual machine, somewhy it doesn't find the config provided via configdrive [09:03] seems to be quite old version also 0.7.6 in this image [09:03] it still tries to find it from Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [10:51] 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] Hi, in my cloud-init logs I see the following: [10:54] 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] What does this warning mean and how is it solved? [11:11] 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] I don't know, but I use in cloud.cnf the following init module - resolv-conf [11:14] And not use nothing for cc_ssh_auth... [11:14] are you able to post your configuration - I'm happy to compare with what I have. [11:14] ah... [11:16] I use the default config file, except, that I add this - resolv.conf in init section [11:17] sorry, we both appear to be a bit lost :-/ [11:19] cloud-init-0.7.9-9.el7.centos.2.x86_64 [11:19] Other fail: [11:19] My image by default use swap partition as: [11:20] # /dev/mapper/centos_centos-swap swap swap defaults 0 0 [11:20] When cloud-init start: [11:20] 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] Then in VM: [11:21] The cloud-init add this: [11:22] # /dev/mapper/centos_centos-swap none swap sw,comment=cloudconfig 0 0 [11:30] Howto workaround this problem? [12:29] 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] go for cloud-init.io [12:54] 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] 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] mdt[m]: cloud-init needs to find a "datasource". a datasource is [14:24] http://cloudinit.readthedocs.io/en/latest/topics/datasources.html [14:41] 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] mdt[m]: well that is entirely up to the platform. [15:07] 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] smoser: so what are usual patterns? [15:08] ah, ok, which other datasources (i saw kernel params already) are possible? [15:08] (ah, and i saw iso media as well) [15:09] well, i'm not privy to how Azure or GCE or Amazon platforms hook up networking and all. [15:10] to automate things locally without a "full blown cloud", you can use the NoCloud datasource [15:11] i have some examples of using those at https://asciinema.org/~smoser [15:11] 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] oh, thank you, i will take a look... [15:14] (and cool stuff with asciinema, it allows cut&paste, i personally dont like these yt vids from screens) [15:15] yeah, asciinema (outside of being really hard to type) is really nice. [15:15] also, see the urls in the descriptions, they point to gists on github that have the fiels there for you. [15:16] oh. i see that the debian does not. https://asciinema.org/a/145772 points to gist. [15:17] ok (debian was the first i looked at) [15:26] 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] sorry - found it, I did not twig that is was a separate module. [15:39] 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] mjh: mount all unformatted disks? what kind of magic is this? :) [15:42] :-) [15:44] 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] 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] wrt https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/337515 [15:46] mjh: there isnt anything there. i agree that'd be a nice feature. [15:46] :-) hey ho [15:48] mjh: ya, I think it's a neat idea. sounds like zfs. :) [15:48] (one aspect of zfs anyway) [15:50] 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] mjh: I mean that when you create zfs filesystems, they automatically get mounted under a particular path. [15:51] I get you. [15:52] mjh: I like your idea about a nice easy way of saying "automount all unformatted storage using ext4" in the config. [16:37] 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] testing an azure deployment with preprovision flag now [16:44] blackboxsw: sory... [16:44] you need to have the new chagnelog entry and version [16:44] (we can't re-upload the same version again) [16:44] you can just strip the bug numbers out [16:44] and we'll add the new chagnelog entry to the sru branch [17:00] smoser: I misremembered fixing [17:00] and making not [17:00] and making note [17:00] 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] 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] blackboxsw: sorry for slow reply. [17:18] leave the old one in place. just put the sru bug on the new commit also i guess. === blackboxsw changed the topic of #cloud-init to: Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting: Monday 2/19 16:00 UTC | cloud-init 17.2 released (Dec 14, 2017) [17:22] smoser: just pused [17:22] pushed even [17:43] thx smoser [17:43] saw unapproved float by [17:45] the other is on its way [19:10] rharper: confirmed my azure pre-provision instance is still timing out /looping :) [19:10] so it is indefinite wait until IMDS tells the instance things are ready /accessible [19:10] non-404 [19:10] * blackboxsw grabs a bit of lunch [19:16] 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] https://code.launchpad.net/~tamilmani1989/cloud-init/+git/cloud-init/+merge/336392 [19:49] blackboxsw or rharper can i get a review of https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/337100 [19:49] i'd like to have that landed. [19:49] https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/337471 should also be striaght forward [20:44] reviewing them [20:49] 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] ha! n/m there aren't any [20:49] disregard [20:49] landing [21:59] 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] n/m: "It is guaranteed at cloud-init-local.service time" [22:00] ok landing