[11:59] <exarr> Hi all. Please prepare for some n00b questions.
=== shardy is now known as shardy_afk
[12:00] <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:01] <exarr> So, for an ice-breaker here, how can I set the /etc/hostname from the metadata passed form openstack?
[12:02] <exarr> I believe this is a built-in function
[12:04] <exarr> nvm, I'm gonna youtube and stop pestering you guys :-)
=== shardy_afk is now known as shardy
[16:59] <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
[17:08] <smoser> blackboxsw: no
[17:08] <smoser> you did not.
[17:08] <smoser> no idea how long its been broken :-(
[17:23] <rharper> smoser: isn't that bionic no-dns issue? did you try that on xenial instead ?
[17:24] <rharper> ah, this is a reporting of the failure
[17:39] <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:40] <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:42] <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:43] <blackboxsw> smoser: should we instead wire that subcommand into systemctl status so that custom params can be provided?
[18:05] <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:17] <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:18] <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:22] <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:25] <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:29] <rharper> smoser: surely urllib returns something on DNS resolution failure vs. 404
[18:32] <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
[19:38] <paulmey> Hi all, what's the process for adding features to a datasource?
[19:39] <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:42] <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:48] <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:56] <paulmey> ok, you want a bug... 😉
[20:02] <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:22] <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:23] <blackboxsw> I'm looking for another mechanism to detemine 'cloud-init is pending in systemd'
[20:26] <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:27] <blackboxsw> or systemctl list-dependencies
[20:33] <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:43] <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:45] <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:46] <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:48] <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:49] <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:50] <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:51] <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:52] <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:53] <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:54] <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:55] <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:56] <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:59] <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)
[21:00] <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:01] <rharper> a target is just a special unit AFAIK
[21:02] <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:03] <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:04] <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:05] <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:06] <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:07] <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:08] <smoser> the results differ.
[21:10] <rharper> aka, bug in xenial systemd's systemctl status ; are you referring to something else?
[21:10] <rharper> s/status/is-enabled
[21:11] <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:12] <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:13] <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:14] <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:15] <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:19] <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:21] <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:22] <blackboxsw> then we've covered that gap without relying on older systemd tooling which doesn't currently work
[21:24] <smoser> blackboxsw: writing something. almost done.
[21:26] <smoser> http://paste.ubuntu.com/26067095/
[21:30] <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:31] <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:34] <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:35] <blackboxsw> ok, smoser I'm not going to move around the uses_systemd function/method then as we don't need it
[21:39] <smoser> well, blackboxsw when not running on systemd
[21:40] <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:41] <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:46] <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:50] <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:51] <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:52] <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:53] <rharper> I'm perfectly fine with not handling the case as that's super early
[21:55] <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
[23:56] <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