[02:04] wallyworld: so renaming caasprovisioner -> caasoperatorprovisioner? [02:05] wallyworld: and adding caasunitprovisioner === axw_ is now known as axw [02:05] um, yeah, i think so [02:23] wallyworld: https://github.com/juju/juju/pull/8166 [02:23] looking [02:25] axw: lgtm [07:45] wallyworld: https://github.com/juju/juju/pull/8169 [07:46] ok [07:46] axw: i've got one up also but there's a feature test failure i'm looking at - there's an issue with directory names [07:47] ok === frankban|afk is now known as frankban === frankban is now known as frankban|afk === frankban|afk is now known as frankban === niedbalski_ is now known as niedbalski [15:17] wpk, did you get a chance to look at the spaces test PR? https://github.com/juju/juju/pull/8165 [17:11] https://bugs.launchpad.net/juju/+bug/1736022 [17:11] Bug #1736022: failed to bridge devices: bridge activaction error: bridge activation failed: Killed old client process [17:12] any idea whats going on there^ [17:12] ? === frankban is now known as frankban|afk [22:55] Hi everyone, I am interested on developing the ability to use LXD as a provider for juju, in order to be able to use an existing remote LXD server. I have read an article from 2015 that it is not possible due to the LXD lack of interface to manage the storage and the firewalling. I have been following closely the development of LXD and I can see that the interface to manage the storage is there [22:55] already but not the firewalling. I am willing to write some code so that LXD has some interface to manage firewalling towards the containers and have already spoken with them. Besides the firewalling and storage part, is there anything else that I should be looking into in order to be able to use LXD as a remote for juju ?