[01:39] <tlm[m]> FYI issue is that version of OpenSSL doesn’t support ecdsa keys, the encoding is fine.
[04:27] <thumper> wallyworld: does the caas controller use the machine agent engine?
[04:27] <thumper> I think it does, just want clarification
[04:27] <tlm[m]> I think so
[04:31] <thumper> thanks...
[04:31] <thumper> I realised that my approach isn't working, so I need to back up and try again
[04:31]  * thumper is looking to add dependency engine metrics for worker restart counts
[04:36] <wallyworld> thumper: yeah, it does with a few tweaks
[04:36] <wallyworld> there's a separate caas model set of workers
[04:36] <wallyworld> and separate caas application agent (vs unit agent)
[04:37]  * thumper nods
[04:37] <thumper> ta
[04:37] <thumper> I still need to backup though
[04:37] <thumper> yay metrics
[04:59] <wallyworld> thumper: i don't get why we need remote-application since it can be inferred from the unit name
[04:59] <wallyworld> maybe babbageclunk knows?
[04:59] <thumper> yeah...
[05:00] <thumper> it is there for application relation changes
[05:00] <thumper> I don't think it should be needed for non-application relation changes
[05:00] <thumper> but the validation is there now
[05:00] <thumper> something to be cleaned up maybe?
[05:00] <thumper> but we need to provide people with the way to unblock
[05:00] <wallyworld> upgrading should not even result in any app relation changes, right? since the charms don't have that yet
[05:01] <thumper> right
[05:01] <thumper> but if someone upgrades to 2.7.5, they need a way to unblock themselves
[05:01] <wallyworld> hence it seems wrong to expect that entry when it's not even used in the context of the hook
[05:02] <wallyworld> yes, workaround needed, but also agree we should fix
[05:02] <wallyworld> another 2.7.6 fix i'd say
[05:02] <wallyworld> well *the* 2.7.6 fix
[05:02] <thumper> wallyworld: yeah, I think achilleasa is going to look next week
[05:02]  * thumper EODs
[05:03] <wallyworld> ttyl
[05:13] <wallyworld> hpidcock: i think you fix bug 1849660 right?
[05:13] <mup> Bug #1849660: AWS A1 instances are not available via juju in eu-central-1 <juju:Triaged> <juju 2.8:Triaged> <https://launchpad.net/bugs/1849660>
[05:14] <hpidcock> wallyworld: might need to run the AWS update scripts
[05:15] <wallyworld> i thought we had already? i thought the bug was fixed but just not marked as fix committed
[05:15] <hpidcock> hmmm
[05:16] <hpidcock> oh yeah
[05:16] <hpidcock> should be fixed'
[05:16] <wallyworld> ta, will makrk as such
[05:16] <hpidcock> wallyworld: if you feel like a PR readthrough of the charm upgrade stuff
[05:16] <hpidcock> https://github.com/juju/juju/pull/11395
[05:17] <wallyworld> ok
[05:17] <hpidcock> still working through it, needs some cleanup possibly
[05:17] <hpidcock> but it works
[05:17] <hpidcock> "works"
[05:22] <wallyworld> hpidcock: wanna rebase and resolve conflicts?
[05:38] <hpidcock> wallyworld: one momento, having lunch
[05:39] <wallyworld> all good, i've got plenty to do
[08:12] <achilleasa> wallyworld: I will work on that next week. Should be a simple upgrade step (read unit name, mangle it to an app name and write it back to the state file). I may be able to cobble together a sed script to use as a manual workaround for stuck units until the fix lands
[08:53] <achilleasa> can I get a CR on https://github.com/juju/juju/pull/11390?
[08:54] <achilleasa> whoops... ^ needs rebasing to resolve conflics
[09:20] <stickupkid> I don't get this, I don't know what it gives you? https://github.com/go-goose/goose/blob/v2/http/client.go#L111-L112
[09:20] <stickupkid> if you want to pool http clients, the there are better ways
[10:07] <stickupkid> manadart, https://github.com/go-goose/goose/pull/85
[10:10] <stickupkid> just updated the description
[10:13] <manadart> stickupkid: OK.
[10:19] <achilleasa> I have resolved the conflicts on 11390. Can I get a CR on it? (if you review it make sure you run the QA steps for both actions/hooks)
[10:29] <wallyworld> achilleasa: i don't understand why we even need that yaml attribute since the app name can always be derived from the unit name, and if it is used to signal the hook is firing as a result of an app data change ,that's fine, but it shouldn't be needed otherwise, and in this case, it definitely doesn't seem valid to error because the system is being upgraded from one where there's no app relation data
[10:29] <wallyworld> so perhaps there's a bigger problem to fix
[10:33] <achilleasa> wallyworld: my guess is that it's a sanity check introduced as part of the application databag work
[10:34] <wallyworld> still doesn't seem right ti me
[10:37] <achilleasa> wallyworld: AFAICT from the validation code, for RelationChanged it seems like you are allowed to have an empty unit but the application must always be populated. Maybe it's there to signal something on the application level?
[10:38] <wallyworld> interesting. not being familiar with the code, my thought was that one of app/unit must be optional, it seems unit is the optional one
[10:38] <achilleasa> wallyworld: though for RelationJoined/Departed both are required
[10:39] <wallyworld> that seems weird since if you know the unit, you know the app
[10:39] <wallyworld> might need to ask xtian/john
[10:42] <manadart> stickupkid: Do we need the Options defs in both http/client.go and client/client.go?
[10:43] <stickupkid> manadart, well I'm unsure if people are using http/client directly. If so, we do need to do that to ensure backwards compatibility. Otherwise we have to move to v3 of goose
[10:44] <stickupkid> manadart, if we're sure then I probably just set it in the constructor, but that means a signature change etc
[10:44] <manadart> stickupkid: So can't we use the http/client ones in client/client?
[10:44] <manadart> We already import it...
[10:45] <stickupkid> manadart, it would seem weird that client/client constructor takes http/client ones no?
[10:45] <stickupkid> manadart, what if client/client wants it's own options?
[10:46] <manadart> stickupkid: I can live with it.
[10:46] <stickupkid> manadart, i'm not a fan by the way, I just wanted to be safer
[10:47] <stickupkid> manadart, my prefered method is make a factory
[12:30] <jam> guild, has anyone felt that juju 2.8 takes *much* longer to link than 2.7 ?
[12:31] <hml> jam, not that i’ve noticed.  but add-model seems to take a longer time than i’d expect.
[12:32] <jam> time go test -check.v in cmd/juju/commands takes around 30s before it gets to the 5s test.
[12:32] <jam> which the test itself is stupid slow, but 6x slower to compile it.
[15:51] <hml> achilleasa:  resolved comments in https://github.com/juju/juju/pull/11376 and retested upgrade
[15:52] <stickupkid> jam, I'll keep my eye out, I might use my old computer as my new one is stupid fast
[15:59] <jam> stickupkid, so I also got a new machine this year, dropped my compile times by something like 6x (yay massive cores).
[15:59] <jam> git co 2.7; dep ensure -v -vendor-only; time go install github.com/juju/juju/... 1m1s
[15:59] <jam> back to 2.8, its 57s, so maybe I'm just crazy
[16:08] <jam> stickupkid, so I'm not entirely crazy 'time go install' was the same, but
[16:08] <jam> cd cmd/juju/commands; time go test -check.v -check.f dontrunanytests
[16:09] <jam> is 36s vs 51s
[16:09] <stickupkid> git co 2.7 and install took 30s for me.
[16:09] <jam> anyway, 30s to spin up a test suite takes it way outside the 'productive loop' for me.
[16:10] <stickupkid> 2.8 took 21s
[16:10] <jam> very nice
[16:10] <stickupkid> i'll see what the cmd/juju/commands one is
[16:11] <stickupkid> 9s for 2.8
[16:12] <stickupkid> roughly the same for 2.7
[16:14] <jam> stickupkid, what go version are you running?
[16:15] <stickupkid> 1.13.7
[16:15] <stickupkid> I should move it back to 1.12
[16:15] <jam> I'm on 1.13.9 (whatever from snaps),
[16:15] <stickupkid> not on a snap
[16:16] <stickupkid> it doesn't play well with my editor
[16:19] <jam> stickupkid, have you ever seen 'dep check' say that Gopkg.lock doesn't match?
[16:20] <jam> stickupkid, I hit a weird bug where static_analysis failed on my machine, but if I push the PR updating Gopkg.lock it says it doesn't match on the bot
[16:20] <jam> stickupkid, but I don't know how to clear out whatever cache dep is using that has a bad version in it.
[16:20] <stickupkid> jam, yeah, but not for a long time, me achilleasa ran into it. Note: you can't remake the Gopkg.lock from scratch, you need a seeded version
[16:21] <stickupkid> jam, nuke your vendor folder?
[16:21] <jam> stickupkid, yeah, I'm aware you can't reset Gopkg.lock when I was figuring out dep ensure in the beginning.
[16:21] <jam> I deleted the dir from vendor, but not the whole dir, maybe I'll try that
[16:22] <jam> stickupkid, I noticed static analysis complaining about a bunch of stuff I didn't touch. Was the test added recently?
[16:23] <stickupkid> jam, nope, got a link
[16:24] <jam> stickupkid, https://jenkins.juju.canonical.com/job/github-static-analysis-go-juju/2149/console
[16:26] <stickupkid> jam, it doesn't like this file for some reason https://github.com/juju/juju/pull/11389/files#diff-6e09331bad8b6f463aba28902512a50d
[16:33] <stickupkid> jam, I suspect the github one is using a different version than local, i.e. it's probably because it's 1.12 v 1.13
[16:57] <jam> stickupkid, so client_test I fixed, it was that I had an import in the wrong section
[16:57] <jam> but it was complaining about more than that.
[16:57] <stickupkid> yeah, I need to clean up the grep output, it's because generated files really message that output up
[16:57] <jam> stickupkid, https://pastebin.canonical.com/p/Sb8MzPvn4D/
[16:57] <jam> I can fix client_test.go which I did touch, it was the leadership upgradeseries, mock_statetracker etc
[16:58] <jam> that I didn't touch
[16:58] <jam> that made me confused
[16:58] <stickupkid> jam, yeah, ignore them
[16:58] <jam> stickupkid, also, it doesn't say *what* the issue is, just "there was an issue"
[16:58] <jam> I had to figure out (a) it was go-import and (b) that it was a problem with client_test.go
[16:59] <stickupkid> jam, agreed
[16:59] <jam> stickupkid, also it mentions output.tar.gz but I couldn't find that as part of Jenkins anywhere
[17:01] <stickupkid> jam, I'm thinking that the output would be better served in s3, jenkins just isn't reliable for us around this
[17:01] <bdx> hello
[17:01] <bdx> I wanted to bring up https://bugs.launchpad.net/juju/+bug/1849916
[17:01] <mup> Bug #1849916: [jaas] add-model doesn't respect region <juju:Incomplete> <https://launchpad.net/bugs/1849916>
[17:02] <bdx> this bug is still impacting myself and others, the same way that it was on 2019-10-26
[17:02] <bdx> it's pretty critical for us, because it blocks us from using/creating models on jaas
[17:03] <bdx> I'll be around to help give some info and/or diagnoses on this if need be
[17:04] <bdx> if someone who knows these waters might be kind enough to lend hand at looking into this further it would be greatly appreciated
[17:04] <bdx> thanks!
[17:33] <achilleasa> hml: there is an error in one of the upgrade tests in 11376
[17:34] <hml> achilleasa:  i’ll take a look
[17:35] <achilleasa> other than that I think it's ready to land. Do you want me to approve it now before my EOD so you can land it once the errors are fixed?
[17:36] <hml> achilleasa:  yes please…  if there’s a big change to fix the test, i’ll have someone review that piece from NZ/AU
[17:49] <hatch> bdx I'll send this around to some folks to see if they have any ideas as it's outside of my wheelhouse
[17:53] <hml> achilleasa:  it was an easy fix, had to update the args for a call in the test which changed signature.
[17:53] <hml> achilleasa:  verifying in github jobs, then squash and merge
[17:53] <hml> ty
[17:56] <bdx> hatch: thanks!
[21:02] <wallyworld> thumper[m]: https://github.com/juju/juju/pull/11396
[23:01] <wallyworld> thumper: you gonna look at my pr? it will make you happy
[23:01] <babbageclunk> can someone take a look at my juju-restore pr to fix HA node counting? https://github.com/juju/juju-restore/pull/13
[23:01] <thumper> ok
[23:01] <thumper> wallyworld: which PR?
[23:01] <wallyworld> thumper: it's posted above
[23:01] <wallyworld> https://github.com/juju/juju/pull/11396
[23:02] <thumper> wallyworld: I was probably not here
[23:02] <wallyworld> asked via github to :-)
[23:02] <wallyworld> *too
[23:03] <thumper> wallyworld: yep, will get to it after my call with timClicks
[23:09] <thumper> wallyworld: 71 files? what have I gotten myself into?
[23:10] <wallyworld> thumper: it's mechanical :-) and you will lovethe result
[23:10] <thumper> I'm reviewing now
[23:24] <thumper> wallyworld: approved with one change requested
[23:24] <wallyworld> ty will look after meeting
[23:29] <thumper> babbageclunk: approved with one change requested too
[23:29]  * thumper goes to get lunch now
[23:39] <babbageclunk> thumper: awesome thanks!