| exarr | Hi all. Please prepare for some n00b questions. | 11:59 |
|---|---|---|
| === shardy is now known as shardy_afk | ||
| exarr | So, I am planning to use openstack with rhel 6.9 and need to learn about cloud-init a bit. But the docs seem to go from "here's a file structure" straight into a here's a load of config. | 12:00 |
| exarr | So, for an ice-breaker here, how can I set the /etc/hostname from the metadata passed form openstack? | 12:01 |
| exarr | I believe this is a built-in function | 12:02 |
| exarr | nvm, I'm gonna youtube and stop pestering you guys :-) | 12:04 |
| === shardy_afk is now known as shardy | ||
| smoser | bug 1734939 | 16:59 |
| ubot5 | bug 1734939 in cloud-init (Ubuntu) "#include fails silently." [High,Confirmed] https://launchpad.net/bugs/1734939 | 16:59 |
| smoser | sigh | 16:59 |
| blackboxsw | hrm did I break that? checking the bug | 16:59 |
| smoser | blackboxsw: no | 17:08 |
| smoser | you did not. | 17:08 |
| smoser | no idea how long its been broken :-( | 17:08 |
| rharper | smoser: isn't that bionic no-dns issue? did you try that on xenial instead ? | 17:23 |
| rharper | ah, this is a reporting of the failure | 17:24 |
| smoser | rharper: yeah, it is that issue. and will become harder to reproduce if that were fixed :) | 17:39 |
| smoser | (probably we can use 404) | 17:39 |
| smoser | blackboxsw: what am i missing at https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/333513 | 17:39 |
| blackboxsw | smoser: was just looking that over. I'm not sure what the prob is. The new subcommand is 'cloud-init status' not systemctl status | 17:40 |
| blackboxsw | I didn't wire that into systemctl cmd entrypoints | 17:40 |
| blackboxsw | maybe it's just a disconnect about what we really want for 'cloud-init status' I was expecting scripts could call into our cli to 'cloud-init status --wait' if their services needed to hold until cloud-init was done. | 17:42 |
| blackboxsw | smoser: should we instead wire that subcommand into systemctl status so that custom params can be provided? | 17:43 |
| smoser | blackboxsw: i must not have been clear. | 18:05 |
| smoser | you are using the presense of systemctl binary to indicate "this is systemd" | 18:05 |
| smoser | at least i think | 18:05 |
| blackboxsw | smoser: we mentioned in comment "moving distro.uses_systemd" where should that live? It seems specific to distro-related attributes and be hesitant to further bloat cloudinit.util | 18:17 |
| blackboxsw | maybe it could just be a separate public function in cloudinit.distro instead of a class attribute of Distro | 18:18 |
| blackboxsw | cloudinit.distro.__init__ | 18:18 |
| blackboxsw | though cloud.distro.uses_systemd() method is called from cc_mounts, ntp, fan and rsyslog modules (as well as rhel/opensuse distros). So, we'd have to explicitly import the public function there and use that instead (or have Distro.uses_systemd be a wrapper that just calls the separate function uses_systemd). | 18:22 |
| blackboxsw | maybe I'll just do that. I'm in hangout if you want to chat through other options | 18:22 |
| smoser | joining | 18:25 |
| blackboxsw | I could be swayed to moving uses_systemd it to cloudinit.util too. We'll have to take a pass extracting functions out of cloudinit.util anyway at some point to make it more modular and focused | 18:25 |
| rharper | smoser: surely urllib returns something on DNS resolution failure vs. 404 | 18:29 |
| smoser | rharper: right. but shoudl also fail and exit failure on 404 | 18:32 |
| smoser | and that is easier to create a test for | 18:32 |
| smoser | than to break dns | 18:32 |
| rharper | for sure | 18:32 |
| rharper | I see, you were referring to how to reproduce/test | 18:32 |
| paulmey | Hi all, what's the process for adding features to a datasource? | 19:38 |
| paulmey | Azure is adding a feature where they are going to keep VM's 'warm' and hold it at boot till a customer needs it... | 19:39 |
| paulmey | here's the MP with the code they have been working on https://code.launchpad.net/~dojordan/cloud-init/+git/cloud-init/+merge/334341/+index?ss=1 | 19:42 |
| paulmey | do we need an LP bug? | 19:42 |
| smoser | paulmey: you dont strictly need a bug, but for a feature like that i guess i'd like one. gives a place to "hold" | 19:48 |
| smoser | i'm not bent on it, but its not like it is hard to file a bug either. | 19:48 |
| paulmey | ok, you want a bug... 😉 | 19:56 |
| paulmey | https://bugs.launchpad.net/cloud-init/+bug/1734991 | 20:02 |
| ubot5 | Launchpad bug 1734991 in cloud-init "cloud-init doesn't yet support azure vm preprovisioning" [Undecided,New] | 20:02 |
| blackboxsw | hrm smoser rharper systemctl status cloud-init.target isn't conclusive. Even when cloud-init is pending (but runcmd is camping on a sleep) | 20:22 |
| blackboxsw | then ActiveState remains 'inactive' and is-enabled remains 'static' until the magical moment when cloud-init is done and transitions to 'enabled' | 20:22 |
| blackboxsw | or 'active' | 20:22 |
| blackboxsw | I'm looking for another mechanism to detemine 'cloud-init is pending in systemd' | 20:23 |
| blackboxsw | it really feels like cloud-init's manipulation of systemd's $gen_d/${target_name}.wants/${CLOUD_TARGET_NAME} link is our best source of knowing if cloud-init really is going to run | 20:26 |
| blackboxsw | or systemctl list-dependencies | 20:27 |
| blackboxsw | feels like systemctl list-dependencies | grep cloud-init.target is probably the best bet | 20:33 |
| blackboxsw | as tracking details of the link file names would be fragile if that link path changes in future releases. | 20:33 |
| rharper | blackboxsw: you can query the list of jobs to see if it's pending | 20:43 |
| rharper | I didn't think we needed that state though | 20:43 |
| rharper | the tri state was (disabled, never going to run), (enabled and is pending), (enabled is done) | 20:43 |
| rharper | is there something missing there? | 20:43 |
| blackboxsw | rharper: yeah double checking today on xenial.... we have is-enabled returns 'static' if cloud-init.target is active, and if it is disabled via kernel cmdline or /etc/cloud/cloud-init.disabled | 20:45 |
| blackboxsw | so I can't inspect disabled if we've disabled our systemd generator via /etc/cloud/cloud-init.disabled or kernel cmdline | 20:46 |
| blackboxsw | s/inspect/introspec/ | 20:46 |
| rharper | I didn't think that was the case | 20:46 |
| * rharper reads the unit file states again | 20:46 | |
| blackboxsw | I tried adding a #cloud-config\nruncmd: ['sleep 60'] and I also don't get to see an enabled status untl http://pastebin.ubuntu.com/26066805/ | 20:48 |
| blackboxsw | until cloud-init.target completes | 20:49 |
| rharper | static == off (never going to run) | 20:49 |
| blackboxsw | on a system currenty in runcmd final stage http://pastebin.ubuntu.com/26066812/ | 20:49 |
| rharper | on xenial the default is (it runs less it's told not to) | 20:49 |
| rharper | ie, ds-identify is report-only | 20:50 |
| blackboxsw | static is on a system where cloud-init is enabled | 20:50 |
| smoser | blackboxsw: https://hastebin.com/raw/qetelayimi | 20:50 |
| smoser | that is what i put together to collect info. | 20:50 |
| smoser | i ran it for xenial, but yeah, didnt see anything that said "expected to be run" | 20:50 |
| rharper | "static"The unit file is not enabled, and has no provisions for enabling in the "[Install]" unit file section. | 20:51 |
| blackboxsw | rharper: then I guess systemd is lying or how cloud-init links or doesn't link the wants file is breaking systemd? | 20:51 |
| rharper | not following | 20:51 |
| rharper | cloud-init.target gets dynamically installed | 20:52 |
| rharper | so, an at-rest system is going to say static | 20:52 |
| rharper | early, we generator run, and on xenial, the default is to enable unless we disable via file or cmdline | 20:52 |
| blackboxsw | our cloud-init generator only dynamically links for wants file if we don't have /etc/cloud/cloud-init.disabled or the cloud-init=disabled in the kernel cmdline | 20:52 |
| rharper | correct | 20:52 |
| rharper | but you can't run status before the generator runs | 20:53 |
| rharper | a cloud-init user cannot | 20:53 |
| blackboxsw | but systemd is-enabled must be checking something else, because it doesn't report 'enabled' on a system that has those links | 20:53 |
| rharper | it enabled"Enabled via .wants/, .requires/ or Alias= symlinks (permanently in /etc/systemd/system/, or transiently in /run/systemd/system/). | 20:53 |
| rharper | so, once generator adds it to a .wants | 20:53 |
| rharper | then it will show enabled (that's post generator) | 20:54 |
| rharper | that means cloud-init status should show *pending* until you have a file that indicates cloud-init is done (result.json) | 20:54 |
| rharper | disabled; or pending -> done | 20:54 |
| blackboxsw | rharper: here's a system that has already run all of cloud-init note is-enabled still shows 'static' | 20:54 |
| blackboxsw | http://pastebin.ubuntu.com/26066859/ | 20:54 |
| rharper | and you have a result.json ? | 20:54 |
| blackboxsw | yeah with no errors | 20:55 |
| rharper | the output of systemctl isn only relevant when we don't know | 20:55 |
| rharper | we only need to know, disabled (never going to run, this is 'static') or we have a result file ; if not those cases, then pending | 20:55 |
| rharper | recall, that is-enabled refers to the *unit* file | 20:56 |
| rharper | not the active job | 20:56 |
| rharper | systemd builds a tree of units, for each unit, it spawns a job | 20:56 |
| rharper | the job runs and is removed from the job queue | 20:56 |
| smoser | well, cloud-init remain Active when they're done. | 20:59 |
| rharper | the units, yes | 20:59 |
| rharper | but really the status command is meant to refer to the runtime element, (ie, the systemd job) | 20:59 |
| smoser | we're interestd in asking systemd "are you expecting to reach the cloud-init target." thats what we need to know. | 21:00 |
| smoser | we're not using status now. | 21:00 |
| smoser | we're using show. | 21:00 |
| smoser | if you're suggesting we look at the unit instead of a target, i dont know if that would hcange anything or not. | 21:00 |
| rharper | a target is just a special unit AFAIK | 21:01 |
| rharper | even if we ignore the jobs; I think we have enough, given the result file an disabled; if we're not disabled and we don't have a result file, then we're pending | 21:02 |
| blackboxsw | I'm still lacking how we determine that we are disabled. as I don't see anything from systemd cli that properly reports whether we are disabled | 21:03 |
| smoser | right. | 21:03 |
| smoser | there is nothing there. | 21:03 |
| smoser | its obnoxious | 21:03 |
| rharper | static means disabled | 21:03 |
| blackboxsw | we can determine ourselves by looking at cloud-init.disabled OR kernel cmdline | 21:04 |
| blackboxsw | static also means enabled | 21:04 |
| blackboxsw | and not yet run | 21:04 |
| rharper | no it does not | 21:04 |
| rharper | well, yes, but you can't ask that | 21:04 |
| rharper | before the generator runs | 21:04 |
| smoser | static does not mean disabled | 21:04 |
| blackboxsw | rharper: even after generator runs | 21:04 |
| blackboxsw | I still see 'static' | 21:04 |
| smoser | right. | 21:04 |
| rharper | well, modulo bugs | 21:05 |
| rharper | systemd says that once it's added to a .wants it's enabled (or enabled-runtime) | 21:05 |
| rharper | so, maybe we have bug in xenial systemd w.r.t state | 21:05 |
| rharper | notice in artful/bionic | 21:05 |
| rharper | it says enabled-runtime | 21:05 |
| rharper | which is the correct answer | 21:06 |
| rharper | in xenial | 21:06 |
| blackboxsw | right, artful/bionic look sane. <= zesty behave differently | 21:06 |
| rharper | https://www.freedesktop.org/software/systemd/man/systemctl.html# | 21:06 |
| rharper | well, they have newer systemd | 21:06 |
| rharper | the man page is pretty clear on this | 21:06 |
| rharper | "enabled"Enabled via .wants/, .requires/ or Alias= symlinks (permanently in /etc/systemd/system/, or transiently in /run/systemd/system/). | 21:07 |
| rharper | so, it should be 'static'; then when generator runs, if enabled, it will transition to enabled (or enabled-runtime) due to a symlnk in /run/systemd/system/multi.user.target.wants/cloud-init.target | 21:07 |
| rharper | I don;t think I'm misreading that man page | 21:07 |
| smoser | the results differ. | 21:08 |
| rharper | aka, bug in xenial systemd's systemctl status ; are you referring to something else? | 21:10 |
| rharper | s/status/is-enabled | 21:10 |
| blackboxsw | http://pastebin.ubuntu.com/26066998/ | 21:11 |
| blackboxsw | referring to a bug in is-enabled | 21:11 |
| blackboxsw | the above is on zesty | 21:11 |
| blackboxsw | running in an enabled world first, then disabled 2nd | 21:11 |
| rharper | not the units, the target | 21:12 |
| rharper | we only put cloud-init.target in .wants in /run | 21:12 |
| blackboxsw | I ran against cloud-init, cloud-init.target and cloud-init.service | 21:12 |
| rharper | so querying the unit files (cloud-init-local , cloud-init, cloud-config, cloud-final) isn't helpful | 21:13 |
| rharper | blackboxsw: right, but do target only on artful/bionic | 21:13 |
| rharper | does it not report enabled-* vs. static ? | 21:13 |
| blackboxsw | rharper: right we are good on artful ++ http://pastebin.ubuntu.com/26067021/ | 21:14 |
| blackboxsw | just broken on xenial & zesty (from our point of view) | 21:14 |
| rharper | ok, so we file a bug | 21:15 |
| rharper | so we can get proper is-enabled status for cloud-init.target | 21:15 |
| rharper | I don't think any other trickery is going to help w.r.t systemd commands | 21:15 |
| * rharper relocates | 21:15 | |
| blackboxsw | smoser/rharper: Ok so, systemctl list-dependencies does give us an idea about 'pending' cloud-init wants target, and 'systemctl is-enabled' works on artful and above. But, filing a bug aside, it's probably just best for us to only look at the /etc/cloud/cloud-init.disabled file and kernel cmdline for determining if we are disabled for the time being, if not disabled... assume pending until result.json | 21:19 |
| blackboxsw | exists right? | 21:19 |
| blackboxsw | the other gap in that logic (checking disabled file or cmdline) is ds-identify disabling us | 21:21 |
| blackboxsw | maybe the 'fix' is for ds-dentify to precipitate a /etc/cloud/cloud-init.disabled file with 'disabled by ds-identify' content. | 21:21 |
| blackboxsw | then we've covered that gap without relying on older systemd tooling which doesn't currently work | 21:22 |
| smoser | blackboxsw: writing something. almost done. | 21:24 |
| smoser | http://paste.ubuntu.com/26067095/ | 21:26 |
| smoser | blackboxsw: ^ | 21:30 |
| smoser | basically, forget about asking systemd. it seems useless to me | 21:30 |
| blackboxsw | reading | 21:30 |
| blackboxsw | yeah agreed on systemd | 21:30 |
| blackboxsw | not enough info there yet (but we'll file a bug) | 21:31 |
| blackboxsw | ahh didn't realize the ds-identify writes an enabled file | 21:31 |
| blackboxsw | ok so yeah we can look for presence of (disabled file or kernel cmdline disable) or absence of /run/cloud-init/enabled | 21:34 |
| blackboxsw | that makes sense (and works today) | 21:34 |
| blackboxsw | ok, smoser I'm not going to move around the uses_systemd function/method then as we don't need it | 21:35 |
| smoser | well, blackboxsw when not running on systemd | 21:39 |
| blackboxsw | smoser why does that matter? | 21:40 |
| blackboxsw | as sysvinit is always on? | 21:40 |
| blackboxsw | because there is no generator? | 21:40 |
| smoser | right | 21:40 |
| blackboxsw | roger | 21:40 |
| smoser | the generator writes /run/cloud-init/enabled | 21:40 |
| blackboxsw | ahh right times two | 21:40 |
| blackboxsw | ok keeping uses_systemd :/ | 21:41 |
| smoser | on systemd we get that benefit. -- easy and complete knowledge of "disabled". | 21:41 |
| blackboxsw | hahah | 21:41 |
| smoser | well, assuming we do not run before the generator | 21:41 |
| smoser | but i'm willing to acept that for now. | 21:41 |
| rharper | we can check whether the cloud-init generator has run via the /run/cloud-init dir presence | 21:46 |
| rharper | that can catch the inb4-cloud-init-generator case | 21:46 |
| blackboxsw | sure ds-identify creates that dir if it doesn't exist | 21:50 |
| smoser | rharper: well, but the generator creates that | 21:50 |
| smoser | no? | 21:50 |
| rharper | yes | 21:50 |
| rharper | so, if the dir doesn't exist | 21:50 |
| blackboxsw | I see it in ds-identify | 21:51 |
| rharper | then it hasn't run | 21:51 |
| rharper | that's for the case of testing status before the generator runs | 21:51 |
| rharper | if we wanted to support status that early, we could say something like (too early) or whatever | 21:51 |
| rharper | ask-later | 21:51 |
| blackboxsw | looks like both generator and ds-identify try to create that dir if !present | 21:51 |
| smoser | oh. well we can't determine what the status is anyway then. we can know we're in that state i guess. | 21:51 |
| rharper | right, similar to systemd-analyze saying 'boot not finished yet' | 21:52 |
| rharper | not particulary helpful but it is some sort of non-answer-answer | 21:52 |
| rharper | I'm perfectly fine with not handling the case as that's super early | 21:53 |
| smoser | in my tests with my script above, we're in at "1.0" seconds per lxc's /proc/uptime. | 21:55 |
| smoser | and it exists already. | 21:55 |
| smoser | there isnt a *lot* of opportunity to run 'cloud-init wait' earlier than that | 21:55 |
| smoser | ie: | 21:55 |
| smoser | lxc start name; lxc exec name -- cloud-init wait | 21:55 |
| blackboxsw | finally wrapped it up and overhauled cloud-init status to use cloudinit.helpers.Paths object https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/333513 | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!