[02:26] anastasiamac: https://github.com/juju/juju-restore/pull/1 - I can't request a review from you for some reason, maybe you need to be made a repo owner or something? [02:26] \o/ [02:26] just saw :) [02:26] * anastasiamac looking [02:27] thanks! [02:44] anastasiamac: could you please test the vids on this page again for me please? https://jaas.ai/docs/microk8s-cloud [02:46] timClicks: in ff, all good [02:46] timClicks: in chrome, i get a line-height black space :( [02:47] :/ [02:47] did u set a concrete height? [02:48] no, Discourse is writing the HTML itself [02:48] it looks like i'll need to write HTML manually [02:50] i wonder if it's html or if we can modify css?... mayb worthwhile reaching out to ppl who wrote discourse?... [04:22] babbageclunk: i agree with u re: comments that are obvious like // Name contains the name [04:22] babbageclunk: but we've had these discussions previously on the project too and got overruled... [04:23] i'd rather we did the agreed standard here so htat we can use it as a sample code, say [04:41] babbageclunk: anastasiamac: although I agree with this, the example of `// Name is the name` is definitely just writing the obvious. Names quite often have constraints e.g. `// Name of the Person and must conform to the regex blabla`. Even explain the value can't be empty etc. There is always something to say about an exported value or function. [04:41] this applies to all values [04:42] i agree nand in fact like the idea of naming variables in an onvious manner to avoid writing comments... [04:43] but we've had discussions in the past where the consensus was to always comment exported stuff even when the naming is obvious [04:43] I don't know what else I'd write for ReplicaSet.Name, other than `// Name of the replica set` - if there are interesting constraints, I don't know them. [04:44] nad to be honest, the constraints on the name of the replicaset maybe defined elsewhere... [04:44] `if there are interesting constraints, I don't know them` probably is a sign that you don't know enough about that value [04:44] hpidcock: What would you write for that? This is for reading the replica set from the db - it's not for creating them. [04:44] anastasiamac: yep, and probably you can refer elsewhere [04:44] if we wanted to be particularly difficult we could say 'name of the replicaset as known to juju/db'... but realisitically u probably can only say 'name contains name' [04:45] `// Name of the replica set` is fine better than `// Name is the name` [04:45] I think adding a link to the Mongo docs for the replica set struct makes sense, but I don't think it helps anyone to add individual field docs for things that are straightforward. [04:46] realistically this tool will not be used by other non-juju users [04:46] it'll only be used with juju setup.. that means that the replicaset name does not need to refer to mongo doc but to juju doc, surely [04:46] and in juju the replicaset is always named 'juju" i think... it's hardcoded.. no? [04:47] yeah all I'm saying is sometimes we just write the simple comment thinking it is straightforward, but when something stands out like that, it's worth trying to see from the perspective of someone reading that might not be obvious [04:47] fwiw m not keen on commenting obvious names but the consensus is the consensus.. mayb we should discuss at the next x-team [04:47] +1 [04:47] hpidcock: yeah, but I don't think `// Name of the replica set` is net positive. It's just noise that takes up valuable screen space. Definitely if there's anything to say about the field it's worth doing. [04:47] babbageclunk: can u ho? m struggling with model vs environment in backup... [04:48] it's just a general Go consensus to comment exported things [04:48] sure [04:48] stdup? [06:53] develop -> 2.7 if anyone is free https://github.com/juju/juju/pull/11203 [06:53] sorry 2.7 -> develop [09:09] new juju post up on the ubuntu blog https://ubuntu.com/blog/devops-tools-in-2020-why-consider-juju [09:18] manadart, achilleasa: cr for a smaller patch? https://github.com/juju/juju/pull/11195 [09:18] manadart: I commented with background information on your comment https://github.com/juju/juju/pull/11186 happy to exchange for review/qa from my side :D [09:56] manadart, quick HO? [09:57] is he around, or was he taking today off [09:58] guess I'm going to have to figure out if a networkID string is the same as corenetwork.Id [09:58] one way to find out [10:02] * stickupkid answers his own question, yes they do [10:11] stickupkid: yeah just saw in calendar, seems like hes taking of today. Vaguely remembering that he mentioned that he may or may not take off today [10:14] in that case for the smaller patch stickupkid achilleasa: mind smaller cr? https://github.com/juju/juju/pull/11195 manadart already took a look and gave a comment. I am not 100% sure whether he and I were on the same page there. Maybe one of you can take a look and tell me that I may have overlooked something? [10:14] nammn_de: looking [10:16] achilleasa: in past we only made it possible to show-space per name, where we searched the `name` field in the database. New patch enables search in `name` and `spaceid` [10:16] nammn_de: I am curious, what's the rationale behind displaying the space IDs? IIRC we wanted to avoid exposing internal IDs to the operators [10:17] (e.g. the rebind command works with space names and translation happens server-side) [10:18] achilleasa: displaying in show-space output? was part of the usage spec. juju list-spaces does this as well [10:18] or do you mean searching by ID? [10:19] both actually... [10:20] the first: was following the spec provided here https://docs.google.com/document/d/1tE5GMF9Uw8W7QQoybgA_vs_RqCHQdbKXmQT_Kaaj6Pk/edit and following list-spaces. [10:20] 2: rick_h opened a launchpad and said it makes sense to search for id [10:20] https://bugs.launchpad.net/juju/+bug/1862238 [10:20] Bug #1862238: show-space quotes integer and doesn't work with id as argument [10:43] achilleasa: thanks for the input! yeah its not 100% clear. We may want to wait for rick_h and see whats his input is [10:58] stickupkid nammn_de: I am off today. [10:58] manadart, yeah we know :) [10:58] manadart: ah sure, have a nice day! [10:59] manadart, go away :p [10:59] manadart: have fun with the life outside juju [11:00] stickupkid: I need to fix a test, but if you have time please take a look at https://github.com/juju/juju/pull/11194 [11:00] L8r. [12:06] stickupkid: Im thinking about removing the tests altogether we were talking about yesterday. [12:06] https://github.com/juju/juju/blob/71c2a5a089bc34bbde192c785b96193d1aaa97fa/cmd/juju/status/status_internal_test.go#L6104-L6103 [12:07] stickupkid: as we already have them as bash based test, which run as expected. Having them in this state based test suite is not winning that much IMO. They are not unit test so somehow kind of on a similiar level to the bash one which already exist. What do you think? [12:07] btw. i run it locally with count to see where it fails... and it does not fail where we hoped it would fail :/ [12:08] nammn_de, hmm, thinking... [12:08] alternative solution would be to poll and retry. But that would be even more similiar to the bash based one .. [12:08] nammn_de, does it fail on CI yet? [12:31] achilleasa: nammn_de the main reason to expose the space id is fear that we don't catch translating it everywhere and somewhere the logs would show "id 6" and users would be stuck figuring out wtf that was [12:31] basically an escape hatch [12:32] then when you run `juju spaces` you see this id and lots of folks would think to use an id as a key to get info [12:33] achilleasa: nammn_de but I didn't realize "0" would be a valid space name...ugh [12:34] ...and we can't control that as we get the names from MAAS... [12:34] show both? it's just YAML :) [12:34] rick_h: however, this would make the operators assume that you can safely swap ID/name with all space-related commands (could cause confusion with bind) [12:36] achilleasa: hmmm, fair. [12:40] achilleasa: nammn_de do we know for sure what the names allowances are in MAAS? [12:40] in juju we use the names package which doesn't allow starting with an int or having a single character if I recall so curious what the exact rules are in maas [12:41] rick_h: see my comment in nammn_de's PR. This is the space validation regex: https://github.com/juju/names/blob/v3/space.go#L13 [12:45] rick_h: and this is the maas -> juju space conversion logic: https://github.com/juju/juju/blob/develop/core/network/space.go#L207 [13:03] stickupkid: the "unit" test? yes, sometimes. It failed from around 50 runs, around twice? [13:04] rick_h achilleasa: we can ho about this as well? [13:04] or wait until tomorrow for manadart and then do the ho [13:04] achilleasa: nammn_de sorry, otp atm [13:05] rick_h: sure no worries. Can be done later today or tomorrow then [13:05] achilleasa: yeah afaict, space ints are valid names as well [13:27] nammn_de, but what failed? [13:27] nammn_de, the output? [13:27] ah, sry, yes the output. The check I added before (check whether activeBranch is to bla) was successfull. The check after that failed. [13:28] *stickupkid^ [13:29] ah, so it's not the controller store, this is in the command then [13:33] stickupkid: this fails: https://github.com/juju/juju/blob/71c2a5a089bc34bbde192c785b96193d1aaa97fa/cmd/juju/status/status_internal_test.go#L6118 not the one above [13:33] yeah its somehow the command [13:33] should be noted. [14:02] stickupkid: my "findings" https://trello.com/c/KG4UJj20/2324-find-out-why-cmd-status-branches-is-flaky [14:16] stickupkid: added a discourse post which can be updated for later. https://discourse.jujucharms.com/t/flaky-ci-tests/2621 [14:22] rick_h: pr was updated to only include documentation update https://github.com/juju/juju/pull/11195/files [14:22] nammn_de: cool ty [14:23] nammn_de: +1'd [15:06] hml, PR of backporting error and logging info https://github.com/juju/juju/pull/11205 [15:39] o/ folks - my localhost controller strugging to providion lxd's, I get this in the logs: [15:39] 2020-02-11 15:38:52 WARNING juju.apiserver.provisioner provisioninginfo.go:609 failed to save published image metadata: missing region: metadata for image not valid [15:40] bloodearnest: juju version, local os series version, and lxd version? [15:40] bloodearnest, can you run this cat ~/.local/share/juju/clouds.yaml [15:41] rick_h: juju 2.7.1-bionic-amd64 (from snap) [15:41] host is bionic [15:41] lxd is 3.20 from snap [15:42] stickupkid: no suck file [15:42] such* [15:43] bloodearnest: and this is juju bootstrap localhost? [15:43] rick_h: yeah, I ripped down the controller and redeployed, on 2.7.1 now [15:43] bloodearnest: can you run it with --debug and paste the output please? [15:44] * bloodearnest hangs head in shame [15:45] uh oh [15:45] somehow deployed a service with no units [15:45] bloodearnest: oh...interesting [15:45] misread the waiting as failing to get an lxd provisioned [15:46] bloodearnest: bundle without any units in the definition? [15:46] rick_h: yep, was doing some yaml munging to get a cut down env, and overmunged [15:47] rick_h: stickupkid: thanks for the quick response, sorry for the noise! [15:47] bloodearnest, not a problem, why we're here :) [16:31] achilleasa: ping [16:33] hml: here [16:34] achilleasa: looking for a name for the “error on no value” thing. but that’s a long name for a flag. —show-errors? eh? ideas? [16:34] hmmm [16:36] hml: how about --strict? "Return an error if the requested key does not exist" [16:41] achilleasa: hrm… [16:43] achilleasa: okay [16:43] ty [22:39] Hi folks, does anyone have any tricks for troubleshooting a first deployment of a charm stuck in status "unknown"? [22:39] Seeing this with a local charm as well as mariadb-k8s. [22:40] Nothing in `juju debug-log` for that application. [22:41] evhan: is the machine up? [22:44] I have logs from other applications in there, working fine. [22:46] Hmmm, but `juju run --application ...` doesn't connect. [22:47] evhan: I'd ssh to the machine and see whether the unit agent is running [22:47] (I mean, `juju ssh` to the machine) [22:48] ah, hang on - this is k8s - sorry, I'm not the best person to answer this then :( [22:48] That's OK, I think there's something else going on with the environment, other tools throwing a fit as well. [22:55] If it's k8's I would take a look at the status of the deploy pods [23:16] Yeah, sorry, it was nothing to do with juju. [23:43] evhan: are you sorted? [23:48] Yeah, sorry, it was CoreDNS going wobbly but not application-related.