[01:19] wallyworld: took a look at your PR. mostly looks fine, left some questions about possible simplification [02:16] axw: got a minute? [02:16] axw: trying to debug a prodstack issue [02:17] thumper: ok [02:18] axw: 1:1 HO ? [02:19] thumper: brt [03:58] axw: thanks for review. i commented on the caas model update worker - i think we can keep it as we will surely be adding upgrade support etc soon. plus it sets model status to "available" [03:59] wallyworld: seems like a bit of an odd place to be setting the status, but fair enough on keeping it for probable future use [03:59] axw: thst's what the IAAS model upgrade worker does - i just cribbed from that [04:00] i guess it sets to available when everything like upgrades etc has been done [04:01] wallyworld: I've approved, please see my comment on the authoriser. I'm going for a ride to get some lunch, bbs [04:01] axw: tyvm [04:06] babbageclunk: I'm hitting an upgrade-juju problem [04:06] babbageclunk: got 5 minutes to discuss? [04:14] thumper: oops, yup? [04:14] in 1:1 HO? [04:15] yeah [04:16] babbageclunk: yeah [04:28] poop, rear wheel is buggered, no ride for me [04:42] axw: bums [04:42] flat tyre or something more serious? [04:44] babbageclunk: wobbling, rubbing against the brake pads. also the kick stand was getting in the way of the pedals... not sure what happened [04:45] axw: I've had something similar with a broken spoke (although not the kick stand part). [04:45] babbageclunk: yeah there's a broken spoke too :) probably has warped on the way home after it broke [06:05] is there a way to specify options for the lxd profile when deploying a unit? [07:20] jam: small PR based on yesterday's work - logs are not as noisy https://github.com/juju/juju/pull/8119 === frankban|afk is now known as frankban [08:06] wallyworld: lgtm [08:14] wallyworld jam: if either of you have time, https://github.com/juju/juju/pull/8120 fixes https://bugs.launchpad.net/juju/+bug/1733259 [08:14] Bug #1733259: API server validator should allow other API server connectings during upgrade process

[08:54] axw: so what is the Pinger for the controller agent now? Just when it is a controller logging in exactly to itself? Does that mean we always have exactly 1 pinger, or do we have 2 (one for RPC one for Logging) [08:55] jam: if you looked earlier than a few minutes ago, you would've caught a mistake. the old code for starting the pinger was correct, just highly confusing (to me at least) [08:56] axw: because of the "is controller" stuff and it only being set when a controller logs in for a different model? [08:56] I don't think that logic is very clear [08:57] jam: we should be starting the pinger if it's a non-controller connecting, or if it's a controller connecting to the controller model [08:57] axw: arguably the latter isn't 100% true. it should be if the controller is connecting to itself in the controller model (IMO) [08:57] axw: Tim's changes to pubsub mean that the controllers connect to each other [08:57] but we shouldn't treat them as alive/dead based on that [08:58] jam: sorry, which "latter" are you referring to? controller connecting to controller model is what I said just before... [08:59] axw: Tim changed pub-sub so that machine-0 will connect to machine-1 in the controller model, but IMO we still shouldn't start a Pinger for it [08:59] we should only start one when machine-0 connects to machine-0 for the controller model [08:59] jam: right, I see [09:02] jam: if we were to do that, then older API servers that didn't prefer localhost wouldn't have a pinger at all [09:02] maybe no big deal, because they should upgrade pretty quickly [09:02] axw: we never have mixed api servers [09:02] axw: they wait to upgrade for the other ones to notice [09:03] because otherwise they can't talk to the db schema [09:03] axw: we might have machine agents older than controllers, but the controllers actually wait for all controllers to ack that they're ready to upgrade before any will upgrade. [09:04] jam: and they do that through state directly, without involving the API server? [09:04] axw: that's actually the cause of the deadlock, because machine 0 & 1 go into "we're ready to upgrade, waiting for 2" and 2 ends up in a reboot loop [09:04] * axw is trying to find the code [09:04] axw: yeah, they record in the database ready-to-upgrade-to, IIRC [09:08] jam: I think I'd like to move the pinger for controller agents outside of the apiserver, but will do after 2.3. I'll have it run only if the tag matches the local machine [09:11] jam: by which I mean presence pingers. we currently don't run connection pingers for user connections, or for connections from controller-to-controller-model; that doesn't seem right, does it? [09:12] axw: we stopped doing connection pingers for users because of long lived connections that were dying (maybe that was gui issues?, or maybe just transferring data issues). [09:13] axw: personaly, I'd rather have the connection-keep-alive-pinger *be* the presence trigger [09:13] rather than 2 separate things [09:13] * axw nods [09:16] jam: pushed a small change to stop running pingers for other controllers [09:48] jam: just back from dinner, ty for review [11:12] jam: I don't understand your comment on https://github.com/juju/juju/pull/8116. why would $gt fail with a time.Time? [11:12] axw: the record in the database is a ISODate [11:12] and ISODate is never $gt: 0 [11:12] we need to compare to a {$gt: time.Time{}} [11:12] jam: but it can be $lt something else? [11:13] axw: Time struct vs integer [11:13] jam: my point is we already compare with integers using $lt, why is $gt different? [11:13] axw: it doesn't [11:13] axw: there is an iportant "if p.unitTime == Nanoseconds" earlier [11:14] axw: so for the statusesC collection, it uses UnixNano and compares with 0 [11:14] axw: for actions, it is a "GoTime" and compares against a time.Now().Sub(somtehing) [11:14] jam: aha, my bad [11:14] thanks [11:15] * axw disappears again [11:15] axw: I worked with eric on debugging why some tests were failing, and just did a quick bootstrap and then was playing with db queries [12:32] Bug #1733847 opened: same ip got assigned to two different container === rogpeppe1 is now known as rogpeppe === frankban is now known as frankban|afk === niedbalski is now known as ikslabdein === ikslabdein is now known as gyosaboy === gyosaboy is now known as niedbalski [21:44] thumper: so I should be ripping out all of the observer stuff? Is it ever used for anything other than audit logging? [21:45] It's kind of vague [21:45] no [21:45] lets talk [21:45] but otp just now [21:50] ah, metrics [21:51] thumper: ok, ping when you're ready [22:13] ready [22:14] babbageclunk: now? [22:14] babbageclunk: 1:1 [22:15] Bug #1733968 opened: virtual IP addresses should not be registered

[22:21] babbageclunk... [22:21] bueller [22:21] bueller [22:21] bueller [22:21] gah sorry, looking at the bottom of the monitor, didn't notice the bubbles at the top