[01:25] <wallyworld> kelvinliu: no hurry, this PR fixes a couple of action test races https://github.com/juju/juju/pull/10612
[01:31] <kelvinliu> wallyworld: yep looking
[01:48] <kelvinliu> wallyworld: lgtm, just small question. thanks
[01:48] <wallyworld> ty
[01:48] <kelvinliu> np
[01:49] <wallyworld> kelvinliu: that's the issue - using defer is insufficient because the Stop() does not occur soon enough -it needs to happen immediately when Exec() returns
[01:49] <wallyworld> the defers are there to ensure Stop() is called in the case of early exit
[01:50] <wallyworld> and that's why also Stop() was made idempotent
[01:52] <kelvinliu> ok, ic
[01:52] <wallyworld> hopefully that makes sense
[01:52] <wallyworld> under --race it can lead to incorrect capture of stdout
[01:53] <wallyworld> the original local only exec used a non-defer Stop()
[01:53] <wallyworld> i changed to defer and that broke
[01:53] <kelvinliu> is it ok to combine Stdout n StdoutLogger?
[01:54] <wallyworld> in the adaptor struct?
[01:54] <kelvinliu> yeah
[01:54] <wallyworld> don't quite follow, quick HO?
[01:54] <kelvinliu> sure
[02:45] <hpidcock> small one https://github.com/juju/juju/pull/10613
[02:51] <timClicks> wallyworld: is there a spec for user friendly actions IDs in juju/names?
[03:08] <hpidcock> https://github.com/juju/names/commit/a74eaa582535eb78813038ae2d8166522518ae90
 or <UUID>
[04:23] <hpidcock> anyone?
[04:35] <anastasiamac> hpidcock: anyone for? review of 10613?
[04:42] <anastasiamac> fwiw i disagree witht the original implementation -that check againsta an arbitrary regular expression should really be a chack against names pkg valid definition of action 'id' (whichever version of that pkg was shipped with that Juju)
[04:43] <anastasiamac> otherwise it's an ongoing headache to keep changing this reg exp to match our improved understand of id... or as per ur pr making it braod enough to work for all scenarios...
[04:43] <anastasiamac> broad*
[05:54] <wallyworld> anastasiamac: the CI test in Python does replicate the same check as is done in the juju names pkg. the names pkg was recently updated but the python test wasn't
[05:55] <anastasiamac> wallyworld: i understand but it has a copy of reg exp, rather than use the actual pkg that Juju was shipped with... anyway
[05:55] <wallyworld> one is Go, the other is Pythin though
[05:56] <wallyworld> gawd, why do I keep typing "puthin"
[05:56] <wallyworld> fark, fail
[05:56] <wallyworld> "pythin" even
[05:56] <wallyworld> i like test that break when we change implementation as it forces you to reevaluate the correctness of the test etc
[05:57] <anastasiamac> with all my typos, i got it :) thank you for understanding me over the years \o/
[05:57] <wallyworld> i need an autocorrect for it
[05:58] <wallyworld> but i have have stand up arguments with other people in the past who disagree with me on that aspect of test writing
[06:05] <hpidcock> wallyworld: pythin or pythick?
[06:08] <wallyworld> lol
[06:19] <SeubertE> Hi there everyone! I'm new to using Juju and trying to set it up on my home lab. I had a few questions that came up while reading the docs (https://jaas.ai/docs/getting-started-with-juju). First, do I need to use JAAS with juju? Or can I run juju all on my home network?
[06:27] <wallyworld> SeubertE: hi there. you can run juju locally using LXD containers (no need for JAAS to get started). The current docs do not reflect that so well. These are being updated to give a much better getting started experience. So long as you have snap installed LXD, you can "juju bootstrap lxd" to get up and running
[06:30] <SeubertE> Thanks wallyworld, that's what I've been doing so far, but got confused since the docs kind of push JAAS in getting started. I've also been having issues with the gui, would it be better to just post on discourse?
[06:31] <wallyworld> that would work yeah, so then others can benfit from the answers
[06:32] <SeubertE> Awesome, thanks, I'll post my issue there!
[13:34] <rick_h> hmm
[13:34] <rick_h> works here, but not in another channel geeze
[14:03] <jam> guild can I get a review of https://github.com/juju/juju/pull/10615 (its quite small)
[14:04] <stickupkid> jam, should this be on 2.6 as well, or are we not bothered?
[21:25] <timClicks> does it make sense to say something like this: "
[21:25] <timClicks> Charms can define "storage" endpoints. Clouds provide "storage pools", tied to the capabilities of the underlying provider."?
[21:26] <timClicks> in particular, do charms define storage endpoints? I'm trying to figure out the best way to express what's defined in metadata.yaml
[21:29] <timClicks> answering self - the terminology we use currently is a storage label.
[21:58] <anastasiamac> timClicks: yeah i would not call them "endpoints" :)
[22:26] <wallyworld> timClicks: generically, clouds tend to have ways to provision storage, either as a block device, or a filesystem. some clouds use a "storage pools" concept but at the end of the day, juju models it as asking the cloud for either a block device or filesystem