=== harlowja is now known as harlowja_away [06:25] Hi #cloud-init. Question about upstart jobs -- is it safe to assume that after all of cloud init stuff is done, it starts the service? [10:53] nk121: "The service"? [10:53] i mean the upstart job [10:54] nk121: Which job are you referring to? [10:54] an upstart job included in the cloud-init configuration [10:55] does it get started at the end of everything being run? [10:55] it seems to, but i'm not sure when in the lifecycle its started (like is it the last thing that happens when cloud init is run?) [10:56] (so should runcmd and user data scripts assume that the upstart job is not running) [10:58] Odd_Bloke: ^ [10:58] nk121: I'm not sure how the ordering is determined, I'm afraid. [10:59] Odd_Bloke: That's ok, of course. :) [10:59] smoser might be able to help out, but he's on EST so won't be around for a few hours. [11:00] nk121: Examining the code, it looks like there isn't a defined ordering; so things will be executed in the order Python's dict implementation spits them out. [11:00] But it just takes me missing one line for that to be completely wrong. :) [11:00] Yeah [11:02] hmm, so then its probably not safe to have a dependency on write_files and runcmd (i have a script that is written out in write_files and then executed as a specific user in runcmd) [11:02] so far, it seems to run my runcmd block after the file is created [11:25] nk121: Aha, OK, I think the ordering is defined by cloud.cfg. [11:26] is that a section? [11:26] or you mean, a file in the source [11:26] nk121: That'll (probably) live in /etc/cloud; it should be installed by your cloud-init package. [11:28] hmm [11:28] cloud_config_modules: [11:28] # Emit the cloud config ready event [11:28] # this can be used by upstart jobs for 'start on cloud-config'. [11:28] - emit_upstart [11:29] nk121: So I think the upstart job is written out before any of these things run. [11:30] okay i'll have to continue this in the morning, its way past my bed time (i'm in PST). thanks for your help tonight [11:31] nk121: Sleep well! :) [11:48] smoser: Daily reminder for https://code.launchpad.net/~daniel-thewatkins/cloud-init/fix-smartos/+merge/252874 :) [12:59] Odd_Bloke, is that python2 safe ? [12:59] does ser.readline() return something that can be .decode()ed in python2 ? [13:00] nk121, the job will be written pretty early in boot. [13:00] so unless you're upstart job is set to run really early, it will be started by upstart. [13:01] but cloud-init lets upstart take care of that. [13:01] the 'emit upstart' isn't waht does it. [13:09] merged [13:11] smoser: You can decode() anything in Python 2. [13:11] >>> "".decode().decode().decode() [13:11] u'' [13:11] yeah, just tested that locally. === harlowja_away is now known as harlowja [16:51] logger url [16:57] logger: url [17:08] suro-patz there is no logger in most public channels; thats typically a y! concept ;) [17:09] is there a archive for cloud-init, I do not see that in pipermail [17:10] suro-patz: It is logged to irclogs.ubuntu.com (e.g. http://irclogs.ubuntu.com/2015/03/17/%23cloud-init.html) [17:10] I _think_ that is updated hourly. [17:10] cool! thanks Odd_Bloke [19:08] smoser: thanks. Could you clarify/confirm: 1) Is it a safe assumption to be run a file written in a write_files section in a runcmd or user data script? 2) If an upstart job is added via cloud-init, can you assume that its been installed into /etc/init and started before code in runcmd/user_data_script is run? [19:09] nk121, http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/config/cloud.cfg [19:10] write-files writes the files. [19:11] scripts-user in cloud_final_modules is what runs your 'runcmd' provided stuff. [19:11] so yes. 1 is safe and guaranteed. [19:11] ok, so for 1) write_files is in init, and runcmd is in config and user-data is in final, so that seems correct [19:12] 2 is guaranteed except for if init system is not upstart (which... in vivid it is not and wont be in 16.04) [19:12] oh not, not run-cmd itself? [19:12] run-cmd itself actually just writes the command to a script that will later get run. interestingly :) [19:12] sorry i mean run-cmd doesn't run run-cmd [19:12] ah [19:13] ok, so you are saying though i should not assume in the long run that my upstart job will be running when my runcmd/user-data script is run as that will change in a future ubuntu [19:13] within a stage, is that the order htey are run in? [19:14] err, you are implying ubuntu is moving away from upstart? [19:15] yes. within a stage they're run in that order. [19:15] oh, systemd replacement [19:15] yes, 15.04 will use systemd by default. [19:15] and thus 16.04. [19:16] okay, got it. thank you. [19:16] i'm not planningon making cloud-init in any version magically convert upstart to systemd jobs [19:17] but there will likelyi be in a future cloud-init a way to write systemd jobs like you can write the upstart jobs now. [22:35] smoser: there? [23:32] suro-patz, here for 3 minutes maybe [23:43] hmmm, i think he just wanted your feedback on https://code.launchpad.net/~suro-patz/cloud-init/vm-clone-ip-reusage-issue [23:44] if u get some time; u seem to have thoughts on that idea; so i'm gonna let u decide if thats ok to let in, lol [23:45] thanks harlowja_ ! [23:46] np [23:46] although i think i missed him to, lol [23:46] was 10 minutes to late [23:48] ... [23:48] oh man. [23:48] that is just a mess. [23:48] (not your code, but the whole non-deterministic network state behavior of cloud-init) [23:48] magic fixes in 2.0 [23:49] i have to read/think more than i hve time for now. will try to look tomorrow [23:49] sure smoser [23:50] later. [23:50] and happy st. patricks day :)