=== jgrimm-afk is now known as jgrimm [15:05] Hi all, I'm a total cloud-init newbie. I'm working on rolling my own AMI for AWS EC2. [15:07] I'm trying to figure out how to tell cloud-init whichuser to initialize with the ssh key at instance creation time. If anyone can offer me a clue or point me to an example, that would be greatly apprecaiated. [15:20] mjb_: I'm not sure how the key(s) get passed in in AWS, but in OpenStack clouds, the key pair (singular), that you specify on the create server is passed in in server metadata and cloud-init adds it for the default user. The default user is specified in /etc/cloud/cloud.cfg here: https://github.com/openstack/cloud-init/blob/0.7.x/config/cloud.cfg#L87 [15:22] mjb_: If you pass in a #cloud-config style YAML in the userdata / script field, you have complete control over the number of keys you pass in and which users get them. See this example: http://cloudinit.readthedocs.org/en/latest/topics/examples.html#including-users-and-groups [15:26] Thanks guys. I'll be trying it out shortly. [16:00] hey guys. I can see that cloud-init is grabing metadata information from different datasources. I suppose it’s using them internally, but is it possible to know which metadata / userdata were retrieved by the datasource(s) and use them, for example in an external script ? [16:01] take a look into /var/lib/cloud-init [16:01] s,-init,, [16:03] in an openstack environment, can cloud-init take advantage of any custom nova metadata passed during boot, i.e. the --meta= flags [16:04] waldi: thanks, but there’s only “user-data.txt” which contains the user data [16:04] I can’t see metadata information [16:05] sterfield, you can output the last used datasource [16:05] by catting out the datasource file [16:05] and then looking at that specific datasource.. [16:06] hmm [16:07] datasource file contains only one line [16:07] DataSourceEc2: DataSourceEc2 [16:07] that’s it [16:07] thats normal [16:07] now look at your ec2 datasource [16:07] for the metadata it retrieved [16:07] curl 169.254.169.254 [16:08] hmm ok [16:08] so yeah, short answer is “cloud-init retrieves metadata but does not expose them” [16:08] I’m already grabing metadata / userdata through the magic url [16:08] well its written to the ob.pkl [16:09] if u look at the obj.pkl file [16:09] madorn: oh now I’m interested ! [16:09] I just want to “template” a file, with the content of some metadata [16:09] /var/lib/cloud/instances/your_instance_id/obj.pk [16:09] l [16:09] right now, I’ve created a python script which grabs the metadata / userdata and template some file in jinja2 [16:10] but I was thinking of doing it directly in cloud-init [16:11] you should just create a cloud-init python module [16:11] cat /etc/cloud/cloud.cfg [16:12] those modules are basically python scripts [16:12] yeah [16:12] a final module could be cool [16:12] that grabs some templated files and template them using whatever engine available [16:14] another question regarding the differente cloud-init phases [16:14] there’s init, config, and final [16:14] that’s ok [16:14] but there’s a very early phase, which is init —local [16:14] yes [16:14] launch very early in the boot process [16:14] and I cannot get much information from this phase [16:15] it runs before networking is up. and looks for local userdata/metadata [16:15] ok [16:15] for example [16:15] but there’s no module attached to this phase ? [16:15] its the same as init.... [16:15] if it finds local userdata/metadata [16:16] examples of local userdata/metadata would be /var/lib/cloud/seed/nocloud/{user,meta,vendor}-data [16:17] or it could be an optical or block device [16:18] there are requirements for the attached device [16:18] it needs to be vfat with special label of "cidata" [16:18] if it doesnt find any local devices it moves on to regular init. [16:19] after networking boots [16:22] sterfield: if you write your own cc_ module for cloud init you can get at the server metadata. This is the only example I've been able to find of an existing module doing so: https://github.com/openstack/cloud-init/blob/0.7.x/cloudinit/config/cc_seed_random.py#L76 [16:25] it's tempting to use the arbitrary key-value support of OpenStack server metadata to pass arbitrary key-values to cloud-init for some consumption. However I'd personally avise against it since it's not a common case and the more common case is to control such things through userdata and a module to consume a section of userdata. [16:25] smatzek: thanks - do you know whether cloud-init used to take advantage of the nova metadeta key value pairs [16:26] i was looking at some old forum posts online and there are some examples of passing dsmode values via nova boot --meta [16:26] madorn: so init —local is applying the same module as init (per cloud.cfg configuration), but apply them from local (=non-network) data [16:27] sterfield, that is correct -if it cant find any data locally, networking comes up and and then "cloud-init init" runs. [16:28] if the same data is available in local and init phase, what happens ? [16:28] madorn: as noted above, cloud-init does consume the metadata but doesn't expose it to scripts it calls, etc. It looks like the code does have some ability to affect dsmode with key-value from Nova boot. [16:29] sterfield: it will stop with the data it receives at --local, unless otherwise specified to "pass" [16:30] madorn: the code here is checking metadata for dsmode items https://github.com/openstack/cloud-init/blob/0.7.x/cloudinit/sources/DataSourceConfigDrive.py#L98 [16:30] smatzek, thanks checking it out now [16:31] madorn: ok so one module is applied once, whatever the phase [16:32] all modules under the init stage are applied [16:32] and then config runs.. [16:32] all those modules [16:32] and then fina [16:32] l [16:32] but the search for datasources has ended. [16:36] sterfield: this is all configurable by the way, with every datasource thats available (/etc/cloud/cloud.cfg/90_dpkg.cfg) you have the ability to control the "mode". [16:37] for example, pass mode which would suggest that the datasource should be skipped over [16:40] madorn: hmm interesting [16:40] thanks a lot for the information ! [16:41] no prob [16:42] smatzek: thanks for pointing that out [16:42] it does acutally work [16:42] jut booted an instance wit dsmode pass [17:19] waldi, probably the syslog target change is fine. [17:20] just ignoring failure to read a random seed doesn't seem like simply a good idea. even though it looks like that is waht we're already doing by 'quiet=True' [17:22] then add a permissions check -- access(file, R_OK) [17:23] currently it is simply broken [17:32] so this breaks you when you build on azure i guess ? [17:32] is that it ? as the tests fail, right? [17:38] Odd_Bloke, still around ? [17:39] both of waldi's bugs there could be fixed mostly with the fixes he's provided. i wonder if you could take a look at thos tomorrow ? [17:43] smoser: Hey! Any ideas about this error from make rpm: https://bugs.launchpad.net/cloud-init/+bug/1561169/comments/2 [17:44] it looks like running it on azure VMs have some sort of contamination on the build [17:46] ahmetalpbalkan: maybe someone need to fix the spec file? [17:46] waldi: I'm having trouble understanding what the issue is in general. [17:47] ahmetalpbalkan, try http://paste.ubuntu.com/15541645/ [17:47] that woudl probably fix the duplicate file (if that is fatal) [17:48] i dont know the correct way to referecne lib/udev in rpmspec speak [17:48] possibly http://paste.ubuntu.com/15541659/ [17:48] ? [17:49] harlowja_at_home, probably did that originally. i dont have the ability to check that at the moment. [17:51] smoser: hmm that just turned the error into: Directory not found: /root/rpmbuild/BUILDROOT/cloud-init-0.7.7-bzr1188.el7.centos.x86_64/usr/lib64/udev [17:52] ahmetalpbalkan, well need to figure out how to refer to lib/udev [17:52] we're putting files in there now, and you need to collect them. [17:52] hmm perhaps I should try on a non-Azure machine [17:53] looks like there is a [17:53] %{udev_dir} [17:53] http://permalink.gmane.org/gmane.comp.storage.libstoragemgmt.devel/2284 [17:53] oh. no, they define it there. [17:54] that seems very odd. why would they use /usr/lib/ for udev [17:54] no idea [17:54] because they have anything in /usr [17:54] https://fedoraproject.org/wiki/Features/UsrMove [17:58] http://paste.ubuntu.com/15541772/ [17:59] ahmetalpbalkan, ^ try that [18:00] it [18:00] smoser: is it {_udev_dir} or {_udev_dir}} [18:00] I guess single ne [18:00] one* [18:02] smoser: hmm it says File must begin with "/": %{_udev_dir}/udev/ [18:02] I wonder if I applied the patch incorrectly [18:03] hm.. [18:03] hm. [18:04] i just copied mostly from that line, but realize i did typo the macro [18:04] maybe http://paste.ubuntu.com/15541843/ [18:06] hmm [18:06] https://www.irccloud.com/pastebin/0xpz3LLG/ [18:06] send just the patch maybe? [18:17] I actually wonder how others packaged it to rhel/centos so far :) [18:17] and started wondering if something is wrong with me last week [18:28] hi folks, how to build an EL7 rpm of cloud-init? [18:28] smoser: ^^ [18:29] can we build it on a RHEL7 system? [18:29] on RHEL7 system, 'make rpm' is failing complaining about 'rpmbuild' [18:30] harlowja_at_home: ^^ [18:30] suro-patz, i'm really not sure. ahmetalpbalkan was i think dealing with that too. [18:30] and,yeah, harlowja_at_home migth be the best resource. [18:30] ahmetalpbalkan, i dont understand the paste up there. [18:30] i'd have thougth taht http://paste.ubuntu.com/15542154/ as packages/redhat/cloud-init.spec.in would be right. [19:13] smoser: that's the error I'm getting from `make rpm` using the paste you provided [19:13] BTW "Download as text" on paste.ubuntu isn't working [19:13] can you please use another paste site maybe? [19:13] it might be some copy/paste issue from HTML [19:14] (I get error "Plain form not available for deep linking." from paste website) === smatzek_ is now known as smatzek