[01:52] <thumper> axw: morning, how well do you know x509?
[01:53] <axw> thumper: morning. not intimately, why?
[01:53] <thumper> axw: we have a bug in the controller package with go 1.9 because upstream fixed a bug in x509 package
[01:53] <thumper> I'm after someone who understands what we are doing a bit more
[01:53] <thumper> possibly our test is a bit (or a lot) wrong
[01:54] <axw> thumper: ah right. where is it?
[01:54] <thumper> controller package
[01:54] <thumper> the fix is outlined here: https://golang.org/doc/go1.9#minor_library_changes
[01:54] <thumper> If any SAN extension, including with no DNS names, is present in the certificate, then the Common Name from Subject is ignored. In previous releases, the code tested only whether DNS-name SANs were present in a certificate.
[01:55] <thumper> and our cert package Verify function
[01:55] <thumper> we specify: opts := x509.VerifyOptions{DNSName: "anyServer", Roots: pool, CurrentTime: when}
[01:56] <thumper> it is the DNSName that dies in the test
[01:56] <thumper> config_test.go:62:
[01:56] <thumper>     c.Assert(err, jc.ErrorIsNil)
[01:56] <thumper> ... value x509.HostnameError = x509.HostnameError{Certificate:(*x509.Certificate)(0xc4201d5900), Host:"anyServer"} ("x509: certificate is not valid for any names, but wanted to match anyServer")
[01:58] <thumper> I don't feel I understand our cert usage enough to work out what to do
[01:58] <thumper> hoping someone else on the team does
[01:58] <axw> thumper: looking
[02:04] <axw> thumper: so it's failing on the second test case, because it has IP SANs specified. our certs are generated with a common name of "*", which was previously matching the "anyServer" we specify in Verify
[02:05] <thumper> ah...
[02:05] <thumper> hmmm
[02:05] <axw> thumper: seems that we can just drop the DNSName from Verify, and not check that... seems pointless anyway
[02:06] <thumper> axw: hmm...
[02:06]  * thumper jumps in yet another call
[04:41] <babbageclunk> axw: Gah, gopkg.in/amz.v3 doesn't expose DeleteTags. Rather than trying to add it to the package, I'm just going to use CreateTags to set juju-controller-uuid to "" - sound reasonable to you?
[04:41] <axw> babbageclunk: ounds fine to me
[04:41] <axw> sounds*
[04:42] <babbageclunk> ool
[04:42] <axw> )
[07:29] <wallyworld> axw: maybe at some point you could look at this PR to change how relation status is modelled - no longer a field on the relation doc but a status entry. i have to do the juju.description change and update dependencies.tsv before landing https://github.com/juju/juju/pull/7831
[07:31] <axw> wallyworld: will try for today, but may have to be tomorrow. just getting into some vsphere stuff
[07:33] <wallyworld> no worries
[07:33] <wallyworld> it can wait
[08:16] <axw> wallyworld: code looks fine, but I'll take another look in the morning with a fresh mind, to relook at the watcher bits
[08:39] <wallyworld> axw: no worries, i'll do the juju/description stuff in the meantime. with the watcher, the existing tests all pass so hopefully things are ok
[21:53] <thumper> wallyworld: https://github.com/juju/juju/pull/7834
[21:53] <wallyworld> looking
[21:54] <wallyworld> thumper: yeah, that should be all that's needed hopefully
[21:54] <thumper> I do recall that there was another problem before where the secondaries were not connecting to localhost...
[21:55] <thumper> but were going to the primary
[21:55] <thumper> but that was a different bug and also fixed
[21:55] <thumper> so perhaps this was just another symptom of that?
[21:55] <thumper> I wish I had the bug reference for that bug
[22:23] <babbageclunk> thumper: I think I've sorted the openstack tag upgrading. ec2 is a lot harder, because the security groups need renaming (which really means recreating with the new name, associating with the instances and deleting the old one).
[22:23] <thumper> babbageclunk: don't worry about ec2
[22:23] <babbageclunk> thumper: So I'm thinking I'll leave that for now, not merge my partial
[22:23] <thumper> right now we only care about maas
[22:23] <babbageclunk> yeah
[22:24] <babbageclunk> maas is fine - doesn't use tagging on maas 1.9
[22:34] <thumper> veebers: probably worthwhile getting the tests run over 2.2 before I forward port the fixes to devel
[22:34] <thumper> just to be sure
[22:34] <thumper> veebers: did you work out how to add artful to the tool gen?
[22:36] <veebers> thumper: artful will happen for any release happening now (1.25.13 got artful) will need to do something extra to get it for previous releases
[22:36] <thumper> veebers: I think we'll be ok as long as we get artful when we get the 2.2.3 release
[22:36] <veebers> thumper: ack re: tests, is there something blocking that? (it will just happen once you land that branch)
[22:37] <veebers> thumper: we will get it for that release
[22:37] <thumper> veebers: both branches have landed for 2.2
[22:37] <thumper> I was just wanting to make sure that the fixes worked before forward porting
[22:37] <thumper> so testing should be underway
[22:38] <veebers> thumper: ack, awesome
[22:38] <veebers> I'll keep an eye out, try minimise infra noise in the results
[22:48] <veebers> *sigh* I need to work out why unit tests are taking an age on this machine: "ok   github.com/juju/juju/agent/agentbootstrap 612.908s"
[22:49] <veebers> that's with GOMAXPROCS=8, this machine has 32 CPUs and 252GB ram :-\ could be IO bottleneck?
[22:50] <thumper> veebers: the tests for any package are run in serial
[22:50] <thumper> veebers: could be i/o with DB access
[22:55] <veebers> thumper: ack, looking into possible io bottlenecks etc.
[23:03] <veebers> thumper: hah yeah, it's IO: "DSK |          sda | busy    101% | ..."
[23:03] <thumper> :)