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:16 |
---|---|---|
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:30 |
beantaxi_ | whoops -- I lied. It looks like things picked up there about 3 AM US time | 14:33 |
blackboxsw_ | beantaxi_: probably #lxd-dev | 19:27 |
blackboxsw_ | beantaxi_: and from the topic on that channel it says support questions over in #lxcontainers | 19:28 |
blackboxsw_ | instead of #linux-containers | 19:28 |
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:34 |
jj623 | $ cloud-init --version/usr/bin/cloud-init 20.2-45-g5f7825e2-0ubuntu1~16.04.1 | 22:35 |
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:38 |
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:39 |
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:40 |
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:43 |
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:46 |
rharper | ah, I see; | 22:47 |
blackboxsw_ | here I'm thinking https://github.com/canonical/cloud-init/blob/master/cloudinit/cmd/status.py#L133-L144 | 22:48 |
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:49 |
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:50 |
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:51 |
jj623 | will do, thanks for confirming what the intended behavior is | 22:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!