=== benj_8 is now known as benj_
[16:07] <blackboxsw> falcojr: I'm finally going through your pr, will have minor unrelated suggestions on https://github.com/canonical/pycloudlib/pull/148/files. Just testing to confirm
[16:17] <blackboxsw> falcojr: also I know I'm way late to this discussion and we've brought it up in standup multiple times, this branch is essentially doing away with a restart primitive, and making "restart" just a wrapper for shutdown(wait=True)/start. Generally, I don't think this really matters, but it does exercise a slightly different path on a platform. shutdown/start on a platform != restart.    So, we could be exposed to something there on a 
[16:17] <blackboxsw> platform by not using the discrete restart operation on a given cloud.
[16:18] <falcojr> blackboxsw: right, I'm out backing that part out (I intentionally did it as a separate commit) if we think that's going to cause problems
[16:18] <blackboxsw> on first blush, I don't really honestly believe its a problem, but it's a blind spot in pycloudlib cloud operations if we don't use the cloud/platform-specific restart operation.
[16:19] <blackboxsw> falcojr: " I'm out backing that part out" is not parsing for me
[16:19] <blackboxsw> *ok*? or *not* 
[16:19] <blackboxsw> :)
[16:20] <blackboxsw> maybe paride also has more context on the ec2instance.restart in pycloudlib as he most recently extended the error handling there.
[16:21] <blackboxsw> I have a suggestion for lxc.restart if were keeping platform-specific restart logic intact where applicable
[16:26] <falcojr> blackboxsw: sorry, meant to say "I'm fine backing that part out"
[17:05] <shalok> Is there a comprehensive reference for the cloud-config? I've found lots of examples, but these don't appear to use all of the supported configs.
[17:06] <falcojr> shalok: https://cloudinit.readthedocs.io/en/latest/topics/modules.html should be what you're looking for
[18:05] <blackboxsw> shalok: other significant  examples are @ https://cloudinit.readthedocs.io/en/latest/topics/examples.html
[18:06] <shalok> Yeah, I've mostly been relying on those examples. The modules docs is more what I was looking for.
[18:40] <blackboxsw> falcojr: trying to work on the patch for your pycloudlib branch. about ~30 mins left. I'm re-running ua-client integration tests on lxc to see performance improvement/check for failures
[19:05] <blackboxsw> falcojr: done review posted https://github.com/canonical/pycloudlib/pull/148#pullrequestreview-676584230
[19:05] <blackboxsw> see what you think
[20:51] <powersj> https://christine.website/blog/cloud-init-2021-06-04
[20:57] <Xe> powersj: that's my article yeah!
[20:58] <powersj> awesome - thanks for the write up. :) I like coming across folks who are trying out cloud-init and see where we can do better
[20:58] <Xe> the documentation could use some love, but i'm probably doing an obscure thing
[21:01] <powersj> I think a good majority of folks are interacting with cloud-init via a cloud itself and less so via qemu, but that said I wrote a post on this very thing last week after co-workers asked me to: https://powersj.io/posts/ubuntu-qemu-cli/ so I woulnd't say it is too obscure :)
[21:03] <Xe> oh, that post
[21:03] <Xe> i used it as reference when i was getting stuff working for the first time!
[21:05] <powersj> ha :)
[22:24] <haitch> "cloud-init analyze blame" gives me multiple boot record for a single boot
[22:25] <haitch> is this common and anyone know how can I troubleshoot this?
[22:32] <rharper> haitch: not common,  but in the past we've had some log formatting issues on different OSes which have cloud-init installed but different logging configurations for cloud-init configured.  If you can, use paste.ubuntu.com to capture your output, and maybe /var/lib/cloud-init.log ;   boot records are found by looking for the various times with cloud-init is invoked;  so if the system is running cloud-init init command outside of 
[22:32] <rharper> booting, you may see more records as they get appended to the log file that's parsed by cloud-init analyze 
[22:56] <haitch> https://paste.ubuntu.com/p/SZ6xsRzKC4/
[22:57] <haitch> I confirmed just have 1 real VM boot
[23:20] <rharper> oh, I know what this is .. 
[23:21] <rharper> on azure, they pre-provision VMs, so they're launched and then paused, then when they're needed, they wake up and resume the rest of boot;      that said, I thought we had  a bug to fix the parsing of cloud-init.log for analyze ... it'd be good to file one just to track the issue;