[00:04] anastasiamac: ah, I missed that [00:08] timClicks: well, since we are stopping testing against 1.9 there is a chance we'll miss something [00:08] I'd rather say people need to go through juju 2.5 or 2.6 in order to upgrade their maas === meeeks is now known as Guest38070 === mup_ is now known as mup [02:43] babbageclunk: if you have a moment at some point https://github.com/juju/juju/pull/10548 === skay__ is now known as skay [02:48] wallyworld: taking a look [02:48] ty, no rush [03:22] random trivia question [03:22] if you do a juju remote backup [03:23] does it persist it somewhere on the filesystem on the server? [03:23] if so, where is it? [03:25] magicaltrout: you talking abou the juju create-backup command? [03:26] yeah [03:27] by default it will download it to your local client, but you can specify --keep-copy and it (I think) is stored as a blob in mongo [03:27] you can list what ones are stored in the controller via list-backups [03:27] yeah, fair enough, plan b then [03:28] you can choose to 1. contoller copy only, 2. local copy only, 3. both [03:28] via a combination of --no-download and --keep-copy [03:28] ironically if you just want a pool and run a backupscript over them, 1,2 and 3 aren't ideal ;) [03:29] i'll stick juju on another box and hook up some cronjob against it [03:30] if there's a use case you want, you could post a question on discource and we can consider it [03:30] backups do need some love and attention [03:30] ha, i won't waste your cycles on it, i just hoped the backups would land somewhere on the controller and I could just dump them to backblaze rather than the client downloading the file then doing it [03:31] but its not a big deal [05:41] kelvinliu: got a minute for a HO? [05:42] wallyworld: sure [11:17] CR anyone https://github.com/juju/os/pull/10? [11:43] stickupkid: Avin' a butcher's. [12:02] stickupkid: I approved it, but then made a suggestion. [12:57] manadart, i agree with said comment === hml_ is now known as hml [14:37] rick_h, this now correctly handles the Any type https://github.com/juju/python-libjuju/pull/345 [14:43] stickupkid: k, gave it a look but I have a case of not trusting my review eyes and wanting to see a test/code prove it works out. [14:44] rick_h, 100% agree... this isn't pretty as I don't have the context to why it was wired up originally like that - it seems weird [14:45] rick_h, i wonder if the assumption was that an `interface{}` would always be `map[string]interface{}` [14:51] stickupkid: so an interface an map walk into a bar... [14:51] stickupkid: no idea === hml_ is now known as hml [15:56] rick_h, got a sec? [15:56] stickupkid: definitely [15:56] rick_h, ho [15:56] omw === salmankhan1 is now known as salmankhan === salmankhan1 is now known as salmankhan === fenris is now known as ejat [20:58] hello folks [20:58] lazy relation question [20:58] on the far end of a connection, how do I get the network addressable name/ip at the other end? [20:59] unit.blah [22:53] magicaltrout: sorry that we haven't gone an answer to you yet [22:54] magicaltrout: would you mind asking in discourse? [22:56] have updated our tutorials page to be more accessible to new users and to surface up community-contributed how tos https://jaas.ai/docs/tutorials [23:24] magicaltrout: i think that's normally info that the other end is expected to put in relation data. the remote unit uses the network-get hook command to get the address info for a given binding/endpoint and shoves that in relation data for the other unit to read