[00:14] <babbageclunk> review anyone? https://github.com/juju/juju/pull/11343
[01:22] <kelvinliu> babbageclunk: lgtm
[01:23] <babbageclunk> thanks kelvinliu
[01:23] <kelvinliu> np
[05:06] <wallyworld> jam: forgot to ask - the jujuc  PR - you looking to land that? w can then ensure it's incorporated into the release etc
[05:33] <wallyworld> jam: here's a race fix for the query tracker. i am not across the original design consideration for not allowing for concurrent access but i think it's necessary to have the mutex https://github.com/juju/juju/pull/11344
[09:14] <stickupkid> manadart, do us a solid and CR this https://github.com/juju/os/pull/20
[09:18] <manadart> stickupkid: Yep.
[09:20] <flxfoo> hi all,
[09:22] <flxfoo> We are using rackspace, somehow they change an OS image, now whatever deploy I tried an error raised up as "image not found" or so... `juju cached-image` return an empty list... is there a possibility to tell juju to use another image ID?
[09:28] <stickupkid> flxfoo, I'm totally not sure on this and someone will probably confirm that, but you may want to look into https://jaas.ai/docs/cloud-image-metadata
[09:29] <stickupkid> manadart, I'd agree, I guess this is a much better improvement over the older way, let me fix
[09:29] <manadart> stickupkid: Cool.
[09:49] <flxfoo> stickupkid: thanks, will have a look
[10:27] <flxfoo>  stickupkid , yeah I folllowed a bit the tutorial, and kind of generate some yaml files to describe the image to be used, but it seems that I can not really "update" rackspace, except bypassing it and setup a webserver which would serve the image definition to use, which seems very unlikely for me to do so...
[10:27] <flxfoo> anyone had deal with rackspace here before?
[10:43] <manadart> stickupkid: https://github.com/juju/juju/pull/11345
[10:48] <stickupkid> manadart, we have to support trusty right?
[10:48] <flxfoo> a related question would be, which provider are you guys using, which would fully support `juju` ?
[10:49] <stickupkid> flxfoo, aws, gce, lxd, maas, azure
[10:49] <stickupkid> vsphere
[10:50] <stickupkid> manual (which is to say, BYOS)
[10:50] <manadart> stickupkid: ESM, yes.
[10:50] <stickupkid> you tried bootstrapping with trusty ;-)
[10:50] <manadart> stickupkid: Not lately.
[10:51] <stickupkid> you should it's fun
[10:54] <stickupkid> manadart, https://github.com/juju/juju/pull/11346
[10:55] <stickupkid> manadart, I'll make a bug around trusty deployment
[10:55] <manadart> stickupkid: `failed to start mongo`?
[10:55] <stickupkid> yeah
[10:57] <stickupkid> manadart, https://bugs.launchpad.net/juju/+bug/1868545
[10:57] <mup> Bug #1868545: Failed to bootstrap trusty <juju:Triaged> <https://launchpad.net/bugs/1868545>
[10:57] <stickupkid> manadart, I've put it as critical, you can change if required, but seems like we should fix asap
[11:23] <flxfoo> stickupkid: thanks
[11:24] <flxfoo> stickupkid: I mean rackspace is in the list of juju supported platform but obviously there are some holes here and there :p
[11:24] <stickupkid> flxfoo, others might have different mileage, but I do know that's what I'm testing day in day out
[11:26] <flxfoo> stickupkid: ok thanks, for example I have a problem with rackspace not supporting network namespace which makes some charm relation not working between our webservers/perconas...
[12:07] <manadart> stickupkid: https://github.com/juju/juju/pull/11347 No conflicts.
[14:40] <stickupkid> manadart, https://github.com/juju/juju/pull/11348
[14:41] <stickupkid> manual CI tests
[14:42] <manadart> stickupkid: Timely. Swap you https://github.com/CanonicalLtd/juju-qa-jenkins/pull/405
[14:47] <rick_h_> ty for that manadart, was going to try to do that today after the discussions last week
[15:00] <manadart> stickupkid: Keep getting this: https://pastebin.canonical.com/p/QndmtYgsPK/
[15:00] <manadart> Test log says too many auth failures for SSH
[15:08] <achilleasa> hml: left some comments in 11342
[15:08] <stickupkid> manadart, do you wildcard your id_rsa to all hosts in ~/.ssh/config
[15:08] <hml> achilleasa:  rgr
[15:09] <stickupkid> manadart, if you do then it won't work because it doesn't know which ssh id to use. And juju doesn't say (we should pass -K) when doing ssh stuff I believe
=== tasdomas_ is now known as tasdomas
[15:11] <stickupkid> manadart, I'll update to remove the profile, good spot
[15:20] <manadart> stickupkid: Removed my wild-carding. Same.
[15:42] <stickupkid> manadart, you have to restart your agent
[15:42] <stickupkid> manadart, i had the same thing last week, can't remember how I bounced it
[15:59] <manadart> stickupkid: I got it. I have a user systemd service for starting my agent.
[16:00] <stickupkid> yeah, bounce it
[16:03] <stickupkid> manadart, I do wonder how this hasn't be hit before, I'm sure juju could be smarter around ssh
[22:50] <tlm> hey babbageclunk, do you have 5 minutes to help me figure out how something works ?
[22:50] <babbageclunk> tlm: sure sure - in standup?
[22:51] <tlm> ok, give me 2 minutes to login and 2fa
[22:51] <babbageclunk> ok
[23:10] <tlm> mismatch at .CertGetter: non-nil functions; obtained (func() *tls.Certificate)(0x1b17a30); expected (func() *tls.Certificate)(0x1b17a30)
[23:10] <tlm> appears deep equals doesn't do functions very well
[23:34] <babbageclunk> tlm: oh yeah, it doesn't - typically we nil them out before the comparison.
[23:35] <babbageclunk> tlm: if you're feeling especially diligent you can try calling it to check that it's the right one (possibly overkill)
[23:37] <tlm> cheers babbageclunk, just rubber ducked it with hpidcock. I can't nil them because the dependency stuff complains. Checked our chehck lib and it doesn't implement functions for deep equals. Just going to fix the problem there
[23:37] <babbageclunk> no, I mean, nil it out before the DeepEquals in the test
[23:37] <tlm> um
[23:37] <tlm> that might work
[23:37] <tlm> let me check
[23:38] <hpidcock> ahh that was what I meant by nil it before the check
[23:38] <babbageclunk> oh right - yeah, if you want to fix it in the library that would be cool too
[23:38] <babbageclunk> (not sure how difficult that is)
[23:38] <hpidcock> but yeah fix the library and I'll +1 it
[23:38] <tlm> I figure if they are of the same type and the pointers match they are the same thing
[23:39] <hpidcock> "If v's Kind is Func, the returned pointer is an underlying code pointer, but not necessarily enough to identify a single function uniquely. The only guarantee is that the result is zero if and only if v is a nil func Value. "
[23:39] <hpidcock> this may be the problem
[23:41] <hpidcock> tlm: ^
[23:41] <tlm> yeah just reading, got it working with nil but I feel dirty
[23:42] <hpidcock> nah all g
[23:42] <wallyworld_> hpidcock: in api client IssueOperatorCertificate, "{Tag: applicationName}" should be {Tag: names.NewApplicationTag(applicationName).String()}
[23:43] <hpidcock> tlm: does the certgetter function need to be called in this test case?
[23:43] <hpidcock> because what you can do is compare the functions by calling them like babbageclunk said
[23:44] <hpidcock> the function could panic("testing the function") and the test just recover()
[23:45] <hpidcock> then nil it
[23:45] <hpidcock> do the DeepEquals
[23:45] <tlm> nope
[23:45] <tlm> nil it is
[23:46] <tlm> thanks hpidcock and babbageclunk. Doing some reading we could compare pointers of the values but that is not a deep equals
[23:46] <hpidcock> wallyworld_: is that where the Unauthorized is coming from?
[23:46] <wallyworld_> not sure, depends on how the apiserver side unpacks it
[23:46] <wallyworld_> i didn't look
[23:48] <babbageclunk> hpidcock, tlm: yup, or just something that returns a unique value, or sets some closed-over variable when called.
[23:48] <babbageclunk> (I mean, if you control what the function being passed in is)
[23:49] <wallyworld_> hpidcock: server side unpacks the "right" way for what's passed in, but should be a tag. i can do a driveby fix
[23:50] <hpidcock> wallyworld_: all good I'm in the area
[23:50] <hpidcock> I'll fix it with my changes
[23:50] <wallyworld_> ok, i'm working on OperatorProvisioningInfo()