[02:25] <wallyworld> tlm: did you find the issue with the controller upgrade?
[02:54] <tlm> not yet wallyworld just finished having some lunch
[03:03] <wallyworld> no worries
[03:37] <tlm> wallyworld: got time for another HO, This isn't going great
[03:38] <wallyworld> tlm: sure, after current meeting,soon
[04:38] <wallyworld> tlm: free now
[04:40] <tlm> wallyworld: think I sorted myself out and found the problem
[04:40] <wallyworld> awesome ok
[04:40] <tlm> the trick was to pull a little more hair
[04:40] <wallyworld> glad it was you cause i have none
[04:41] <tlm> i've noticed
[04:41] <wallyworld> \o/
[06:04] <kelvinliu> thumper: or anyone got one minute to take a look?  https://github.com/juju/juju/pull/11694
[06:06] <wallyworld> looking
[06:07] <kelvinliu> ty wallyworld
[06:07] <wallyworld> kelvinliu: we were going to land in 2.7?
[06:07] <kelvinliu> will back port to 2.7 in next PR
[06:11] <wallyworld> kelvinliu: awesome, lgtm. great to see this fixed
[06:12] <kelvinliu> ta
[06:29] <kelvinliu> wallyworld: this one goes to 2.7 https://github.com/juju/juju/pull/11695
[08:08] <achilleasa> manadart: when we convert the interface info into LinkLayerDeviceArgs (setLinkLayerDevicesAndAddresses in networkconfigapi.go), why is only a subset of the information persisted?
[08:08] <achilleasa> for example, shouldn't the origin be persisted?
[08:09] <achilleasa> (I am on develop)
[08:09] <stickupkid> achilleasa, origin was never extended to it's fullest
[08:09] <manadart> achilleasa: Yes. This patch will set it for the provider: https://github.com/juju/juju/pull/11683
[08:10] <manadart> I have some work locally to add. Should be up for review today.
[08:11] <achilleasa> cool. I will also be adding the virtual port type to the link layer devices doc
[08:25] <stickupkid> I wish juju passed context.Context through the stack
[08:44] <manadart> achilleasa: Was just looking at bringing 2.7 forward again. The patches are 11695, 11682 and 11682. The only one we want is the last one (your bundle-diff changes).
[08:45] <manadart> I had a crack, but couldn't update the dependency. You mentioned this in standup, so do you want to bring it into 2.8?
[09:00] <achilleasa> manadart: you mean to cherry-pick it and land it standalone to 2.8?
[09:42] <achilleasa> manadart: doing the ovs detection as we discussed allows the bridge policy to work out its magic and the lxd containers get assigned to the bridge. However, I noticed that when the container gets removed, the veth device remains attached to my switch; guess we need to fix that as well
[09:50] <manadart> achilleasa: Do veth devices usually go away immediately? This is only for the OVS case?
[09:51] <manadart> achilleasa: And yes to the question above, just cherry-pick forward.
[09:52] <achilleasa> manadart: I happened to notice this for OVS; I will check a normal lxd to see what happens
[09:53] <achilleasa> btw, you can review https://github.com/juju/juju/pull/11697 instead of the LXD one which I will close now
[10:20] <achilleasa> manadart: or stickupkid https://github.com/juju/juju/pull/11698 (forward port of diff-bundle fix and a drive-by for a spurious warning by lxd container)
[10:35] <achilleasa> manadart: the lingering veth issue only seems to affect the OVS bridge; the nic is dropped as expected from lxdbr0
[11:29] <achilleasa> quick sanity check on a clean 2.8 -> develop PR https://github.com/juju/juju/pull/11699
[11:33] <stickupkid> how do you know if a charm has been upgraded from status
[11:33] <stickupkid> is there a revision somewhere
[11:36] <stickupkid> charm-rev
[12:14] <achilleasa> stickupkid: removed the gitignore bit; can you take another look?
[15:38] <stickupkid> hml, https://github.com/juju/juju/pull/11700
[15:39] <hml> stickupkid: suggest an upgrade-charm hook as well
[15:40] <stickupkid> hml, yeah I'll add, it takes time haha
[15:40] <hml> at first quick glance
[15:55] <stickupkid> we should totally point the lxd image server to the host image server... we download the images twice
[20:35] <wallyworld> hml: does the latest comment on bug 1829393 look like it's something we need to be worried about?
[20:35] <mup> Bug #1829393: model upgrade tries to upgrade the lxd profile of kvms <juju:Fix Released by hmlanigan> <https://launchpad.net/bugs/1829393>
[20:36] <hml> wallyworld:  reading
[20:39] <hml> wallyworld:  something to fix… looks like a situation we haven’t seen before… not a breakage of the bug fixed at first glance
[20:40] <wallyworld> i wonder if a blocker for 2.7.7, i guess there's no workaround
[20:40] <hml> wallyworld:  no work around is coming to mind right now
[20:41] <hml> wallyworld: how often do we have an lxd cloud with manual kvm machines?
[20:41] <wallyworld> shrug
[20:42] <wallyworld> how big is the fix? can we do it quickly?
[20:49] <hml> wallyworld:  looking
[20:54] <hml> wallyworld:  need to thread a check for manual machines thru to the instancemutater… from state to the worker. in theory not too difficult.   pondering if fix to deploy needed as well….
[20:55] <hml> wallyworld:  nope, since manual machines don’t go thru the provisioner afaik
[21:05] <wallyworld> hml: "nope" as in no change needed to deploy as well?
[21:05] <hml> wallyworld: i do not believe so.  would have to double check
[21:06] <wallyworld> k
[21:44] <timClicks> where are the default machine constraints specified? they're not available via get-model-constraints
=== _thumper_ is now known as thumper