=== ctracey|away is now known as ctracey === helgi- is now known as helgi [14:57] harlowja, thoughts: [14:57] https://code.launchpad.net/~vlastimil-holer/cloud-init/net-reconfigure/+merge/186352 [17:09] Hi, I have configured cloud-init in a linux image, but when I boot the image, the systemd services crash. When I start them manually it works. What could it be? [17:12] pedroalvarez_, i'm not sure. i've never used systemd. [17:12] what is 'crash' ? [17:12] logs ? [17:17] smoser: http://paste.ubuntu.com/6124789/ [17:17] ya, maybe logs, i haven't used systemd either myself (yet) [17:19] well it sure thinks it failed to create the user [17:19] If I do: `systemctl start cloud-init` it works. [17:19] And if I reboot the image, sometimes it starts. [17:20] I want cloud-init to execute commands at boot time, through the "customization-script" of OpenStack [17:21] ya, thats fine [17:21] pretty normal use-case [17:21] And, correct me if I am wrong, the services running are essential [17:21] likely :) [17:21] *likely u are right [17:22] pedroalvarez_ is this systemd via fedora [17:22] or systemd via some other distro? [17:23] customized core linux [17:23] baserock [17:26] I have located the systemd files on /etc/systemd/system [17:26] And I made a symlink in /lib/systemd/system/multi.user.bla.wants [17:27] Also in /lib/systemd/system/ [17:27] hmmm, eck, defintly outside of my area of expertise :( [17:28] smoser: Does the install script try to copy them? [17:28] harlowja: no worries :) tvm [17:29] pedroalvarez_ can u just use the init.d versions instead of the sytemd ones? [17:29] that might work better, idk [17:29] harlowja: I'll try init.d version then :) thanks [17:29] those work on RHEL6 and such [17:30] and i know the upstart ones work [17:30] since smoser uses them [17:30] the systemd ones i think work with fedora, but i don't know if smoser or me have to much experience with them [17:32] yeah, i have no idea on systemd. [17:32] harlowja, did you see above? [17:32] smoser that review looks ok, an interesting approach with the 'pretend' [17:32] why is it 'pretend' ? [17:32] what was that for. i didn't understand. [17:32] def _write_network(self, settings, pretend=False) [17:33] right. what is that doing ? [17:33] other than for testing. why would i want that. [17:33] ah, k, got your question [17:33] digging deeper, incase i missed why its being used, ha [17:34] i think its for [17:34] dev_names = self._write_network(settings, pretend=True) [17:34] self._bring_down_interfaces(dev_names) [17:34] which is like a way to figure out the device names to bring down [17:35] although i would think its a little convoluted :-P [17:35] just have a 'list_interfaces' function and bring those down, ha [17:35] so from my understanding, whats happening [17:36] is that its pretending to write out the network interfaces, the result of this gives u the device names, and then the code is ifdown those [17:36] and then it writes out in non-pretend mode [17:36] so the reason for this being is https://bugs.launchpad.net/cloud-init/+bug/1225922 [17:37] in short, if the system is booting, eth0 might have already been 'ifup'ed. and then we write a new /etc/network/interfaces file. [17:37] gotcha [17:37] (ifup'ed successfully or non-successfully) [17:37] we need to bring it down and then back up. [17:37] and ideally we dont run 'ifdown -a' [17:37] so the pretend thing is really just a way to list the interfaces by using the same code that writes out the interfaces (which returns a list of device names) [17:37] and 'ifup -a' [17:37] (although that i a hacky solution) [17:38] ah. [17:38] pretend make sense now? [17:38] thats my interpreation [17:38] but where does he call with 'pretend'? [17:39] ah. i see. [17:39] 19 + if bring_up: [17:39] 20 + dev_names = self._write_network(settings, pretend=True) [17:39] 21 + self._bring_down_interfaces(dev_names) [17:39] it is a little convoluted i guess, haha [17:40] a function like 'list_interfaces(settings)' [17:40] that returns the device names [17:40] probably would be clearer to understand [17:40] yeah. [17:40] parse the existing [17:40] parse the new [17:41] ya, since all that write_network does is parse settings and write out a file [17:41] *or files [17:42] want me to comment on that review [17:42] or u got it under control boss [17:47] Ok, after see that cloud-init service tries to create an "ubuntu" user, and then another service tries to use "apt", I think it thinks I'm running ubuntu [17:51] :) [17:51] haha [17:51] hahahahaha [17:51] ya, so u need to edit the cloud.cfg for that [17:52] harlowja: good news then? [17:52] yup [17:52] # System and/or distro specific settings [17:52] # (not accessible to handlers/transforms) [17:52] system_info: [17:52] # This will affect which distro class gets used [17:52] distro: rhel [17:52] something like that [17:52] you are probably using the default ('ubuntu') [17:52] and the other part is what modules u have left active by default in cloud.cfg [17:53] some of them are more ubuntu speicfic [17:53] *aka ones starting with 'apt' and such [17:53] all smoser fault, ha [17:54] The other problem of initialization is just because cloud-init needs ssh services running, and cloudinit doesn't wait I think. [17:54] harlowja, i'd appreciately comement. [17:54] pedroalvarez_, the user is configurable. [17:55] smoser: that's cool [18:11] I think I found all my problems on this file! :) [18:12] :) [18:12] I'm going home happy today [18:12] I owe you a couple of beers [18:13] ha [18:13] np [18:13] cloud.cfg is the magic file [18:24] cloud.cfg is the magic. [18:24] all the magic === shardy is now known as shardy_afk