[01:20] <fling> Odd_Bloke: trying ubuntu focal
[01:21] <fling> [FAILED] Failed to start LXD - agent - virtio-fs mount.
[01:21] <fling> [FAILED] Failed to start LXD - agent.
[01:22] <fling> What is the default username and password?
[05:37] <meena> faa, i know that dch has a monster aarch64 machine in his cellar, but from what i gather, every ARM machine is a bit special
=== cpaelzer__ is now known as cpaelzer
[14:37] <Odd_Bloke> fling: Can we take this to #ubuntu-server?  (Can you re-ask your question there?)
[15:04] <Odd_Bloke> asakkurr: Landed! \o/
[17:01] <Odd_Bloke> Very small Travis PR modifying non-voting tests if a committer wants an easy review: https://github.com/canonical/cloud-init/pull/683
[17:20] <blackboxsw> Odd_Bloke: done
[17:20] <Odd_Bloke> blackboxsw: Thanks!
[17:20] <blackboxsw> one nibble at a time :)
=== ijohnson is now known as ijohnson|lunch
=== ijohnson|lunch is now known as ijohnson
[20:36] <Odd_Bloke> lucasmoura: What's the reasoning behind using a custom profile for launching LXD VMs?  (I can't find justification in the code, and it seems to be causing me problems, so I'm just trying to understand the problem space. :)
[21:01] <falcojr> Odd_Bloke: this file might provide more context
[21:01] <falcojr> https://github.com/canonical/pycloudlib/blob/master/pycloudlib/lxd/defaults.py
[21:02] <falcojr> xenial and bionic need some custom config to work
[21:10] <Odd_Bloke> falcojr: Aha, right, thanks!
[22:46] <AnhVoMSFT> @Odd_Bloke @blackboxsw running tox on master failed on xenial - is that expected? I think some recent change in tox.ini broke it.
[22:47] <AnhVoMSFT> https://paste.ubuntu.com/p/9kwnmxCsdW/
[22:47]  * blackboxsw checks tox on xenial (currently running on focal here). and I think CI runs on bionic
[22:48] <AnhVoMSFT> updating tox to 2.3.2 fixed the issue, but xenial's latest package for tox is 2.3.1
[22:48] <blackboxsw> yep CI on bionic https://github.com/canonical/cloud-init/blob/master/.travis.yml#L2
[22:49] <AnhVoMSFT> yeah, we moved our CI to bionic as well so no issue there. Mostly for developer machine who is on xenial.
[22:49] <AnhVoMSFT> If this is by-design that's all good.
[22:50] <blackboxsw> I tihnk we have a xenial and xenial-dev target in tox to expressly allow developers to try running tox locally if on xenial (and not be pinned to the public release available in xenial)
[22:50] <blackboxsw> tox -e xenial-dev ?
[22:50] <blackboxsw> # but the version of pytest in xenial has a bug
[22:50] <blackboxsw> # (https://github.com/tox-dev/tox/issues/208) which means that the {posargs}
[22:50] <blackboxsw> the above target may work for that developer  AnhVoMSFT
[22:51] <blackboxsw> "tox -e xenial-dev" I mean
[22:53] <blackboxsw> hrm... nope still hitting the problem on my one xenial dev lxc  container
[22:53] <blackboxsw> though an older checkout of cloud-init was succeeding
[22:54] <blackboxsw> bisecting now
[22:58] <blackboxsw> looks like it was commit cd752df6154c403e6dccaf5e797c1d4f8396f756 maybe
[23:03] <blackboxsw> yeah if I were to drop  the integration-tests-ci substitutions here https://github.com/canonical/cloud-init/blob/master/tox.ini#L150-L152 then tox succeeds on xenal
[23:05] <blackboxsw> AnhVoMSFT: I'll put up a proper PR to allow xenial devs to continue
[23:06] <blackboxsw> same sort of fix we had to use for xenial-shared-deps in tox already. substvars are buggy on xenial
[23:22] <AnhVoMSFT> thanks @blackboxsw
[23:35] <blackboxsw> If it helps AnhVoMSFT https://github.com/canonical/cloud-init/pull/684
[23:35] <blackboxsw> some eyes will get on that tomorrow I'm sure