[01:03] wallyworld: show-credential cmd \o/ PTAL when u get a chance?... https://github.com/juju/juju/pull/8429 [01:15] Bug #1488245 changed: Recurring lxc issue: failed to retrieve the template to clone

[01:26] anyone... https://github.com/juju/juju/pull/8430 [01:26] it is an intermittent test fix [01:30] thumper: lgtm [01:45] ta [02:35] another simple review plz, duplicate warning msg on blocked operations... https://github.com/juju/juju/pull/8431 [02:53] * thumper looks [03:01] anastasiamac: i reviewed - have a question about yaml output [03:01] IMO we should try and stay consistent with list-credentials [03:02] people don't want to have to re-parse stuff when running different commands [03:02] when it's essentially the same info [03:16] wallyworld: so I am k with re-ordering output... say, cloud 1st etc... however, personally, i do not think that how we display credentials in list-credentials is helpful, in particularly because there is no distinction btw hidden fields (secrets), etc... [03:17] that's the bit i like about it :-) [03:18] easier to look at the complete set of attrs in one map [03:18] wallyworld: also do not forget that attributes are stored as maps so while u can kind of re-order some attributes to certain degree when u r reading them from a file (locally stored credential case), there is no guarantee what would be pulled from a controller (especially, say a year down the track form an original bootstrap) [03:18] trying to find consistency sometimes can be an insane pursuit.. [03:19] yaml can give you ordered maps [03:19] wallyworld: without separating secrets into a separate collection, the user will not immediately know whther they got a complete content or not [03:20] they will know if they typed --show-secrets :-) [03:20] but this is just IMO [03:20] happy to get input from someone else [03:20] i may well be on my on here [03:20] maybe thumper can be a tie breaker :-) [03:21] wallyworld: k [03:21] if we agree on field ordering, it comes down to whether to group gred attrs and whether to be consistent with list-credentials [03:21] * thumper looks [03:22] which means we avoid showing the same info in different ways [03:22] deoending only on what command was run [03:25] wallyworld: bleh :-P how do i preserve formatting in github comments? [03:25] triple quotes [03:25] no ;( [03:25] triple single quotes [03:26] sorry [03:26] triple backticks [03:26] ``` [03:26] foo [03:26] bar [03:26] ``` [03:26] \o/ hooray \o/ thnx [03:26] anastasiamac, wallyworld: what is the issue with formatting? formatting what and where? [03:27] thumper: pr 8429 - show-credential command output [03:29] thumper: the output is different to list-credentials (which ostensibly shows the same info) and the splitting of attrs into differnet buckets rather than one map like elsewhere [03:31] isn't it just showing one credential rather than multiple? [03:31] wallyworld: there is also additional info like models... [03:31] thumper: it can show more than one [03:31] the command shows controller-stored credential(s) [03:32] sure, models will be a new block [03:32] i would have prefered to b explicit tha the credentials are coming from different places.. one way is t diplay /format output differently [03:32] or we could have local-credentrials: vs controller-credenrials: [03:32] as the top level field name [03:33] the content though is essentillt the same [03:33] one will have a models block, one won't [03:33] all imo [03:34] actually I quite like the local-credentials vs. controller-credentials top level idea [03:34] I was leaning the other way until you mentioned this [03:35] I like consistency, [03:35] wallyworld: controller-credentials is awesome at the top here [03:35] we shouldn't make the users think too much [03:35] so having similar output would be ideal [03:35] credentials: for locallly stored comes from a file... to change it to local-credentials is a bit more work ... [03:35] anastasiamac: I think you can use struct embedding with a special tag so it doesn't get an extra level of indentation in yaml [03:36] anastasiamac: we don't have to make it look like a file [03:36] and there's map ordering support as well [03:36] just show what the controller has [03:36] but showing generally similar structure helps with the general cohesiveness [03:36] thumper: yes, so for controller, i.e. this command output, i can have a header of controller-credentials [03:36] to order a map, have a slice of MapValue (I think) and it wil render as a map [03:36] we should change list-credentails to say "local-credentials" too [03:37] +1 [03:37] thumper: for local credentials, i.e.e the output of list-credential, the header is what we have in credentils.yaml file which is "crednetials" [03:37] k [03:37] yeah, but we should be able to override that for the output [03:37] we don't have to change the file format [03:37] just the output [03:38] thumper: we dont? we usually try to output what can be put into the file... if we change the output, we'd need to change the file content too... [03:38] no... we don't [03:38] most people should never edit the file [03:38] I'm happy for it to be different [03:39] thumper: k [03:39] the only reason we had that early was because we were missing commands [03:39] the other reason perhaps is that the file is quite simple in structure so the output naturally looks similar [03:40] thumper: re: no-access, there is a bit of thorn that wallyworld and i discussed yesterday.. it'll b related to further work... for now, only tests have that... in real life, credential owner will always have some (in fact, probably only) admin access to the model that uses the cred [03:41] thumper: there will beother re-work (happy to discuss) that will fix the no-access in a few places.. ;D [04:49] wallyworld: as part my testing, added a comment... [04:49] i'd need to separate "content" from "models", see the sample on the PR... [07:15] anastasiamac: lgtm, thank you. did you have plans be asking stakeholders if it meets their expectations in case we need to iterate a bit on the output? [07:32] wallyworld: there have been a lot of conversations when cred UX re-design came up. None of it eneded up being definitive. we r in the position now where we need to do it and iterate if needed [07:32] exactly. i think we are saying the same thing. [07:34] :D === frankban|afk is now known as frankban [07:57] veebers: I don't know if you've noticed but the merge description that you have is repeating the first line a bit: https://github.com/juju/juju/commit/29f2a73c702fdacb20eaa231b4db7bcd417b75f1 [07:57] (hard to tell from github, because one is the subject field, and then the first line is repeated) [07:57] I think just dropping it to the URL would be ok [07:58] its a bit more obvious in 'git log' [07:58] veebers: https://paste.ubuntu.com/p/p8jrHnHR5k/ [08:00] my suggestion is to change it to: https://paste.ubuntu.com/p/wTzvdqh9j9/ [08:00] thoughts? [08:00] wallyworld: ^^ do you agree on the alternative merge message? [08:00] looking [08:01] (I also don't think we need 2 blank lines) [08:01] yeah, there has been whitespace there [08:01] lgtm to remove the dupes [08:02] dupe messages [08:10] jam: hey just passing through, yeah makes sense. Seems my reading of the (almost no) docs was wrong and it would always include that header text anyway [08:10] jam: Have you deployed any of the jenkins jobs before? [08:10] veebers: so I tried to update jobs/github/github-merge-juju-description.yml [08:10] veebers: but jenkins-jobs ... [08:11] says that its doing something [08:11] but I don't see it actually changing the ci page [08:11] .../configure still has the old text in it. [08:11] jam: What's the output of jenkins-job, also have you refreshed the configure page? :-) [08:12] veebers: refreshed and loaded on another machine [08:12] ack [08:12] veebers: https://pastebin.canonical.com/p/nTkNw2GyjN/ [08:13] veebers: I pushed the change to github, so it should be in the master branch [08:13] veebers: I can certainly edit the live site, but I'm pretty sure that's the wrong way about it. [08:15] jam: github-merge-juju-description has updated. Not sure if your pastebin was cut short but it doesn't seem right [08:15] veebers: ah, nm, I updated only 1 of them, probably my fault. [08:15] veebers: it was intentionally cut short [08:16] jam: oh you only . . . hah yeah what you just sai [08:16] said* [08:16] veebers: but I don't see that text in the other one [08:16] am I just missing it [08:17] veebers: looks like it had folded off the screen [08:17] jam right down the bottom, in the Post Build Action section [08:19] jam: there is github-merge-goose too :-) [08:19] Sorry about that, I'm surprised it will always have that header text in the merge. [08:42] veebers: np. I was just being blind searching for it [11:36] balloons: when you're around, I had some questions about interpreting CI [11:38] for example, http://10.125.0.203:8080/job/ci-run/393/ seems to be saying that it has been in the "BuildJuju" stage for 7hrs [11:38] but if I go to BuildJuju, all of them are not blinking and are 'green' [11:38] though green vs blue is odd to me [11:38] I assumed it meant active [11:39] also, the console output has lots of: "java.lang.NullPointerExceptionFinished Build :" [11:39] which looks buggy to me [11:39] but it is the same content as http://10.125.0.203:8080/job/BuildJuju/323/console [11:56] balloons: hm. looks like the arm64 slave is down, thus it never built the arm64 content [11:56] which is why it got hung [12:06] balloons: also, http://10.125.0.203:8080/computer/arm64-slave/ seems to say its both offline and has low disk space [12:11] are there obvious tricks for how to clean them up? [12:29] Good morning [12:30] jam, green and blue are the same. Tim wanted green, but it's cached so your browser might be mixing them [12:31] balloons: morning. I think it was just that yesterday or so they were blue, today they're green, and I didn't know why [12:31] hope nobody is red/green color blind :) [12:31] lifeless was, IIRC [12:31] Indeed :) [12:34] jam, wpk: hiya. just wondering if you remember if there's any portability problem with doing: l, _ := net.Listen("tcp", "localhost:0"); net.Dial("tcp", l.Addr().String) ? [12:35] so jam, on the arm64-slave, /tmp is full of artifacts from unit test runs [12:35] a bunch of juju-store-locks, test-mgo, etc. Why aren't those being cleaned up I wonder? [12:36] I'm just rebooting the slave which will clear /tmp [12:37] rogpeppe: I don't think there is a problem, testing now, though. [12:38] jam: it definitely works in most cases, but i have a nagging feeling that it might not in some cases. [12:38] rogpeppe: AFAICT, its valid on all platforms [12:38] jam: there's a comment that worries me: // A net.TCPAddr cannot be directly stringified into a valid hostname. [12:38] it might give you an IPv6 or an IPv4 [12:38] rogpeppe: sure, but that's "valid hostname" [12:38] TCPAddr is likely an IP address, and Addr() would have a port on it, as well [12:39] jam: yeah, but it's not being used there in a place that actually needs a hostname AFAICS [12:40] jam: i *think* the comment is bogus, but i thought you might remember more [12:40] rogpeppe: if you could link me to context, but AFAIK its valid [12:41] jam: the code i'm looking at right now is (in apiserver) func (s *serverSuite) TestStop(c *gc.C) { [12:41] jam: unfortunately we've lost the reviews for that period of juju's history so context is difficult to know [12:42] jam: but the commit says: http://paste.ubuntu.com/p/ppcXVQF5pW/ [12:42] rogpeppe: my best guess on that test is that it wants to allow for either ::1 or 127.0.0.1 [12:43] jam: ah! i see why [12:43] jam: it's a bug in newServerWithConfig [12:43] jam: oh... except [12:43] jam: it can't explicitly listen on localhost there [12:44] jam: ok, it's all starting to come back now [12:44] jam: if you listen on ":0", you're not guaranteed that Addr returns a valid dialable address [12:44] jam, slave is online again. But it will fill /tmp again until we figure out why those tmp files aren't going way [12:46] rogpeppe: why is listen :0 not valid? [12:51] jam: listen :0 is valid, but the address you get from the listener after that doesn't necessarily provide a dialable address [12:52] jam: on Linux, it gives me an address like [::]:36758 [12:52] hm. my testing says it works, but it does tend to give an IPv6 vs an IPv4 [12:52] jam: which is OK under linux as a dialable address but probably not under all platforms [12:52] rogpeppe: oddly, Dial worked fine for that, but shouldn't it be ::1 to dial it? [12:52] jam: i think it's an oddspecial case in the network stack [12:52] (tested on Win10 Dial succeeded, though I don't know if it would allow packets) [12:54] manadart, externalreality have you guys started the release at all? [12:55] jam: so this code works for you on Windows? http://paste.ubuntu.com/p/QV3BYJGv9v/ [12:56] balloons: Hi, yes. Sent the release notes to Nick and Peter. 2.3 branch is bumped. Working through now. [12:57] rogpeppe: I get "some traffic" before it exits. That said, will it work on all versions of all Windows? [12:57] This is Win10, the server tests are on 2012 [12:57] which hash are you using? [13:02] 0303e52 [13:13] 10.13.0.0/16 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.18.0.0/20 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.20.0.0/16 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.22.96.0/21 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.22.112.0/21 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.24.0.0/15 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.26.0.0/16 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.33.0.0/19 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.34.0.0/15 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.35.64.0/22 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.38.0.0/16 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.40.0.0/19 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.48.0.0/15 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.50.0.0/16 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.55.0.0/17 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.55.160.0/24 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.70.0.0/24 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.74.0.0/16 via 10.172.192.1 dev tun0 metric 1000 [13:13] 10.76.0.0/16 via 10.172.192.1 dev tun0 metric 1000 [13:13] 10.80.0.0/24 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.85.48.0/24 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.88.0.0/15 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.96.0.0/16 via 10.172.192.1 dev tun0 metric 1000 [13:13] 10.98.0.0/16 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.100.0.0/21 via 10.172.192.1 dev tun0 metric 1000 [13:13] 10.101.52.0/23 via 10.172.192.1 dev tun0 metric 1000 [13:13] 10.105.0.0/24 via 10.172.192.1 dev tun0 metric 500 [13:13] 10.110.0.0/16 via 10.172.192.1 dev tun0 metric 1000 [13:14] 10.122.36.0/22 via 10.172.192.1 dev tun0 metric 500 [13:14] 10.124.0.0/21 via 10.172.192.1 dev tun0 metric 500 [13:14] 10.125.0.0/21 via 10.172.192.1 dev tun0 metric 500 [13:14] 10.172.0.0/16 via 10.172.192.1 dev tun0 metric 500 [13:14] 10.172.192.0/18 dev tun0 proto kernel scope link src 10.172.193.84 [13:14] 10.189.0.0/18 via 10.172.192.1 dev tun0 metric 1000 [13:14] 10.189.64.0/24 via 10.172.192.1 dev tun0 metric 1000 [13:14] 10.189.72.0/23 via 10.172.192.1 dev tun0 metric 1000 [13:14] 10.189.74.0/24 via 10.172.192.1 dev tun0 metric 1000 [13:14] 10.189.75.0/24 via 10.172.192.1 dev tun0 metric 1000 [13:14] 10.189.84.0/24 via 10.172.192.1 dev tun0 metric 1000 [13:14] 10.189.90.0/24 via 10.172.192.1 dev tun0 metric 500 [13:14] 10.189.128.0/18 via 10.172.192.1 dev tun0 metric 1000 [13:14] 10.193.0.0/16 via 10.172.192.1 dev tun0 metric 1000 [13:14] 10.198.200.0/21 via 10.172.192.1 dev tun0 metric 1000 [13:14] 10.211.37.0/24 via 10.172.192.1 dev tun0 metric 500 [13:14] 10.222.36.0/22 via 10.172.192.1 dev tun0 metric 500 [13:14] 10.222.64.0/20 via 10.172.192.1 dev tun0 metric 500 [13:14] 10.222.128.0/18 via 10.172.192.1 dev tun0 metric 500 [13:14] 10.227.32.0/20 via 10.172.192.1 dev tun0 metric 1000 [13:14] 10.227.240.0/21 via 10.172.192.1 dev tun0 metric 1000 [13:14] 10.228.0.0/16 via 10.172.192.1 dev tun0 metric 1000 [13:14] 10.229.0.0/16 via 10.172.192.1 dev tun0 metric 1000 [13:14] 10.230.0.0/16 via 10.172.192.1 dev tun0 metric 1000 [13:14] 10.231.64.0/21 via 10.172.192.1 dev tun0 metric 500 [13:14] 10.231.96.0/21 via 10.172.192.1 dev tun0 metric 500 [13:14] 10.231.128.0/21 via 10.172.192.1 dev tun0 metric 500 [13:14] 10.231.144.0/21 via 10.172.192.1 dev tun0 metric 500 [13:14] 10.232.0.0/16 via 10.172.192.1 dev tun0 metric 1000 [13:14] 10.235.64.0/22 via 10.172.192.1 dev tun0 metric 500 [13:15] 10.244.0.0/18 via 10.172.192.1 dev tun0 metric 1000 [13:15] 10.244.128.0/18 via 10.172.192.1 dev tun0 metric 1000 [13:15] 10.244.192.0/18 via 10.172.192.1 dev tun0 metric 1000 [13:15] 10.245.0.0/16 via 10.172.192.1 dev tun0 metric 1000 [13:15] 10.245.80.0/22 via 10.172.192.1 dev tun0 metric 500 [13:15] 10.245.128.0/21 via 10.172.192.1 dev tun0 metric 500 [13:15] 10.245.136.0/21 via 10.172.192.1 dev tun0 metric 500 [13:15] 10.245.160.0/19 via 10.172.192.1 dev tun0 metric 500 [13:15] 10.246.0.0/19 via 10.172.192.1 dev tun0 metric 1000 [13:15] 10.246.40.0/21 via 10.172.192.1 dev tun0 metric 1000 [13:15] 10.246.48.0/21 via 10.172.192.1 dev tun0 metric 1000 [13:15] 10.246.56.0/21 via 10.172.192.1 dev tun0 metric 1000 [13:15] 10.246.64.0/21 via 10.172.192.1 dev tun0 metric 1000 [13:15] 10.246.72.0/21 via 10.172.192.1 dev tun0 metric 1000 [13:15] 10.246.80.0/21 via 10.172.192.1 dev tun0 metric 1000 [13:15] 10.246.88.0/21 via 10.172.192.1 dev tun0 metric 1000 [13:15] 10.246.96.0/20 via 10.172.192.1 dev tun0 metric 1000 [13:15] 10.246.112.0/21 via 10.172.192.1 dev tun0 metric 1000 [13:15] 10.247.0.0/21 via 10.172.192.1 dev tun0 metric 500 [13:15] 10.247.0.0/16 via 10.172.192.1 dev tun0 metric 1000 [13:15] 10.248.0.0/16 via 10.172.192.1 dev tun0 metric 1000 [13:15] 91.189.88.0/21 via 10.172.192.1 dev tun0 metric 500 [13:15] 91.189.91.0/24 via 10.172.192.1 dev tun0 metric 1000 [13:15] 162.213.32.0/22 via 10.172.192.1 dev tun0 metric 500 [13:15] 185.125.188.0/22 via 10.172.192.1 dev tun0 metric 500 [13:15] 192.168.64.0/23 via 10.172.192.1 dev tun0 metric 500 [13:15] 192.168.89.0/24 via 10.172.192.1 dev tun0 metric 500 [13:15] 192.168.211.0/24 via 10.172.192.1 dev tun0 metric 500 [13:15] 192.168.220.0/24 via 10.172.192.1 dev tun0 metric 1000 [13:15] 192.168.224.0/22 via 10.172.192.1 dev tun0 metric 1000 [13:16] 192.168.228.0/23 via 10.172.192.1 dev tun0 metric 1000 [13:16] 192.168.230.0/23 via 10.172.192.1 dev tun0 metric 500 [13:16] 192.168.233.0/24 via 10.172.192.1 dev tun0 metric 500 [13:16] 192.168.236.0/22 via 10.172.192.1 dev tun0 metric 1000 [13:16] 192.168.240.0/24 via 10.172.192.1 dev tun0 metric 500 [13:16] 192.168.246.0/23 via 10.172.192.1 dev tun0 metric 1000 [13:16] 192.168.248.0/22 via 10.172.192.1 dev tun0 metric 1000 [13:16] Oops. [13:18] surprised you weren't flood kicked [13:21] jam, do you know why juju-store-lock files stick around in /tmp? [13:23] balloons: not explicitly [13:23] balloons: I'm blaming charmstore, but I'm actually digging into it [13:24] jam, it's odd because we're building and testing in containers, but the host machine ends up being filled with those files in /tmp [13:24] ahh, well, actually we're using tmpfs, so that does make sense [13:25] balloons: yay, 'juju-store-lock' doesn't exist anywhere in the code base, so its clearly a built-up string and I'm sure its using 'juju' 'store' and/or 'lock' to build it up... ugh [13:26] ohh jam, well it comes from jujuclient/file.go: return fmt.Sprintf("store-lock-%x", fullHash[:8]) ? [13:31] balloons: presumably we're supposed to be putting those into $JUJU_HOME ? [13:34] jam, I'm not sure. I'm just noticing we setup tmpfs for the unit tests, but not the builds. And it seems we clean it, probably for that reason. Still, a testrun really shouldn't leave things behind [13:54] balloons: this has the smell of someone escaping our IsolationSuite (which is supposed to set things like JUJU_HOME to invalid values so it doesn't accidentally leak) [14:01] jam, perhaps a card to have a look? [14:03] balloons: looks like all of our on-disk lock objects don't have a Cleanup function, which sort of makes sense, as if it is a shared lock, you don't want to clean it up on process exit, but we *should* be cleaning them up for testst [14:04] balloons: is it actually a lot of disk-space in them? [14:04] that part should be quite small [14:04] but potentially lots of them [14:04] jam, yes. it adds up quickly surprisingly. the filelist is too long to run rm juju-store-lock* :-) So eventually it burns all the disk space up [14:05] jam, 20g was burned in about 3 days, which is the size of that slaves /tmp [14:05] the other slaves all have massive disks, so we wouldn't know for a long time [14:06] balloons: wow. k. I would have thought each juju-store-lock would be tiny, but I can see it still burns inodes, etc. [14:36] balloons: so *an* option is to set TMPDIR for a test run, and then 'rm -rf TMPDIR' when its done [14:37] jam, yea I'm updating things now to clean out /tmp. We were cleaning up test-mgo* files, so I'm adding juju-*. [14:39] balloons: you *might* need to check for gobuild as well [14:39] not sure whether thats 'go-build' or 'gobuild' [14:39] but I've seen bogus stuff there [14:39] that said, I'd like us to have a way to not leave cruftn. [14:39] though the mechanism flock uses makes it hard. [14:44] jam.. ohh, ok, I'll add a check for that too === frankban is now known as frankban|afk [19:46] morning