| wallyworld | tlm: did you find the issue with the controller upgrade? | 02:25 |
|---|---|---|
| tlm | not yet wallyworld just finished having some lunch | 02:54 |
| wallyworld | no worries | 03:03 |
| tlm | wallyworld: got time for another HO, This isn't going great | 03:37 |
| wallyworld | tlm: sure, after current meeting,soon | 03:38 |
| wallyworld | tlm: free now | 04:38 |
| 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:40 |
| tlm | i've noticed | 04:41 |
| wallyworld | \o/ | 04:41 |
| kelvinliu | thumper: or anyone got one minute to take a look? https://github.com/juju/juju/pull/11694 | 06:04 |
| wallyworld | looking | 06:06 |
| 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:07 |
| wallyworld | kelvinliu: awesome, lgtm. great to see this fixed | 06:11 |
| kelvinliu | ta | 06:12 |
| kelvinliu | wallyworld: this one goes to 2.7 https://github.com/juju/juju/pull/11695 | 06:29 |
| 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:08 |
| 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:09 |
| manadart | I have some work locally to add. Should be up for review today. | 08:10 |
| achilleasa | cool. I will also be adding the virtual port type to the link layer devices doc | 08:11 |
| stickupkid | I wish juju passed context.Context through the stack | 08:25 |
| 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:44 |
| 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? | 08:45 |
| achilleasa | manadart: you mean to cherry-pick it and land it standalone to 2.8? | 09:00 |
| 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:42 |
| manadart | achilleasa: Do veth devices usually go away immediately? This is only for the OVS case? | 09:50 |
| manadart | achilleasa: And yes to the question above, just cherry-pick forward. | 09:51 |
| achilleasa | manadart: I happened to notice this for OVS; I will check a normal lxd to see what happens | 09:52 |
| achilleasa | btw, you can review https://github.com/juju/juju/pull/11697 instead of the LXD one which I will close now | 09:53 |
| 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:20 |
| achilleasa | manadart: the lingering veth issue only seems to affect the OVS bridge; the nic is dropped as expected from lxdbr0 | 10:35 |
| achilleasa | quick sanity check on a clean 2.8 -> develop PR https://github.com/juju/juju/pull/11699 | 11:29 |
| stickupkid | how do you know if a charm has been upgraded from status | 11:33 |
| stickupkid | is there a revision somewhere | 11:33 |
| stickupkid | charm-rev | 11:36 |
| achilleasa | stickupkid: removed the gitignore bit; can you take another look? | 12:14 |
| stickupkid | hml, https://github.com/juju/juju/pull/11700 | 15:38 |
| hml | stickupkid: suggest an upgrade-charm hook as well | 15:39 |
| stickupkid | hml, yeah I'll add, it takes time haha | 15:40 |
| hml | at first quick glance | 15:40 |
| stickupkid | we should totally point the lxd image server to the host image server... we download the images twice | 15:55 |
| 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:35 |
| hml | wallyworld: reading | 20:36 |
| 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:39 |
| 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:40 |
| hml | wallyworld: how often do we have an lxd cloud with manual kvm machines? | 20:41 |
| wallyworld | shrug | 20:41 |
| wallyworld | how big is the fix? can we do it quickly? | 20:42 |
| hml | wallyworld: looking | 20:49 |
| 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:54 |
| hml | wallyworld: nope, since manual machines don’t go thru the provisioner afaik | 20:55 |
| 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:05 |
| wallyworld | k | 21:06 |
| timClicks | where are the default machine constraints specified? they're not available via get-model-constraints | 21:44 |
| === _thumper_ is now known as thumper | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!