[14:16] <AnhVoMSFT> @rharper - continuing from our discussion yesterday. Is the best course of action is to have cloud-init do a mount -a -0 _netdev to avoid mouting NFS mounts?
[14:30] <beantaxi_> Where's a good place to ask basic lxc/lxd questions? I've tried #linux-containers but there does not appear to be any activity of any kind there
[14:33] <beantaxi_> whoops -- I lied. It looks like things picked up there about 3 AM US time
[19:27] <blackboxsw_> beantaxi_: probably #lxd-dev
[19:28] <blackboxsw_> beantaxi_: and from the topic on that channel it says support questions over in #lxcontainers
[19:28] <blackboxsw_> instead of #linux-containers
[22:34] <jj623> Hello, I was expecting `cloud-init status --wait` to poll until all stages of cloud-init have completed, but it looks like it exits before cloud-final has finished running if a module within cloud-config fails. My current idea is to execute `cloud-init status --wait` in a systemd unit that has an After= dependency on cloud-init.target, but is there
[22:34] <jj623> a more accepted approach for waiting until cloud-init is done executing all stages?
[22:35] <jj623> $ cloud-init --version/usr/bin/cloud-init 20.2-45-g5f7825e2-0ubuntu1~16.04.1
[22:38] <blackboxsw_> jj623: that sounds like it would be worth a bug. I want cloud-init status --wait to block until everything is done executing error or not.
[22:39] <blackboxsw_> please do file a bug so we can keep that approach simple for non systemd units/scripts
[22:39] <rharper> status --wait most certainly should block until final is done ..
[22:39] <rharper> blackboxsw_: +1
[22:40] <blackboxsw_> that said it should be possible to add After=cloud-init.target for systemd units/services... per this earlier blog post  https://ubuntu.com/blog/cloud-init-v-18-2-cli-subcommands
[22:40] <blackboxsw_> but, really we do need to fix that bug you mention in cloud-init status --wait for your error condition
[22:43] <blackboxsw_> it'd be worth an FAQ doc topic added  to https://cloudinit.readthedocs.io/en/latest/topics/faq.html on startup scripts waiting on cloud-init as this question is really asked a *lot*
[22:43] <rharper> blackboxsw_: xenial uses systemd ...
[22:43] <rharper> so I'm not sure what's going on
[22:46] <blackboxsw_> rharper: I think the issue as jj623 alluded to, is that status --wait only blocks until any error is seen any stage of /run/cloud-init/status.json
[22:46] <blackboxsw_> so if we have any error in config:modules stage, status exits as ERROR
[22:47] <rharper> ah, I see;
[22:48] <blackboxsw_> here I'm thinking https://github.com/canonical/cloud-init/blob/master/cloudinit/cmd/status.py#L133-L144
[22:49] <blackboxsw_> which we bail on wait if ! (STATUS_RUNNING or STATUS_ENABLED_NOT_RUN) https://github.com/canonical/cloud-init/blob/master/cloudinit/cmd/status.py#L57
[22:50] <rharper> yeah, we'll need a flag;  as existing behavior bails on first error;
[22:50] <blackboxsw_> so I think we may need to avoid tracking ERROR until DONE is also achieved in the status --wait call
[22:51] <rharper> --wait --ignore-errors/--no-errors/--stages-only   ...  not sure what color the bikeshed should be
[22:51] <blackboxsw_> jj623: hiya thanks for the heads up, we agree it's probably a bug with status --wait related to  https://github.com/canonical/cloud-init/blob/master/cloudinit/cmd/status.py#L133-L144. if you get a chance, please file a bug  https://bugs.launchpad.net/cloud-init/+filebug and we can get that fixed
[22:51] <blackboxsw_> rharper: :) +1 agreed
[22:52] <jj623> will do, thanks for confirming what the intended behavior is