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