thumper | axw: morning, how well do you know x509? | 01:52 |
---|---|---|
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:53 |
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:54 |
thumper | and our cert package Verify function | 01:55 |
thumper | we specify: opts := x509.VerifyOptions{DNSName: "anyServer", Roots: pool, CurrentTime: when} | 01:55 |
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:56 |
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 | 01:58 |
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:04 |
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:05 |
thumper | axw: hmm... | 02:06 |
* thumper jumps in yet another call | 02:06 | |
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:41 |
babbageclunk | ool | 04:42 |
axw | ) | 04:42 |
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:29 |
axw | wallyworld: will try for today, but may have to be tomorrow. just getting into some vsphere stuff | 07:31 |
wallyworld | no worries | 07:33 |
wallyworld | it can wait | 07:33 |
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:16 |
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 | 08:39 |
thumper | wallyworld: https://github.com/juju/juju/pull/7834 | 21:53 |
wallyworld | looking | 21:53 |
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:54 |
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 | 21:55 |
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:23 |
babbageclunk | maas is fine - doesn't use tagging on maas 1.9 | 22:24 |
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:34 |
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:36 |
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:37 |
veebers | thumper: ack, awesome | 22:38 |
veebers | I'll keep an eye out, try minimise infra noise in the results | 22:38 |
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:48 |
veebers | that's with GOMAXPROCS=8, this machine has 32 CPUs and 252GB ram :-\ could be IO bottleneck? | 22:49 |
thumper | veebers: the tests for any package are run in serial | 22:50 |
thumper | veebers: could be i/o with DB access | 22:50 |
veebers | thumper: ack, looking into possible io bottlenecks etc. | 22:55 |
veebers | thumper: hah yeah, it's IO: "DSK | sda | busy 101% | ..." | 23:03 |
thumper | :) | 23:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!