[00:57] <babbageclunk> veebers: do we need to be able to build on go 1.8 any more? Is it safe for me to use a type alias?
[00:58] <babbageclunk> I don't absolutely need it, would just simplify some tests I'm writing that need to pass around a lot of funcs taking map[corelease.Key]corelease.Info.
[01:09] <anastasiamac> babbageclunk: m not veebers, but I do not think so... should 1.10 be backward compatible anyway? i would have though we only have 1 mayb 2 releases in 1.9 like 2.1 and mayb 2.2 ...
[01:11] <babbageclunk> anastasiamac: well, I'm trying to use syntax that was introduced in 1.10, and I *vaguely* remember someone needing to remove a type alias for some reason... not sure whether it's still needed.
[01:11] <anastasiamac> babbageclunk: ah.. ur memory is better than mine :)
[01:12] <babbageclunk> oh sorry, introduced in 1.9
[01:16] <anastasiamac> babbageclunk: my first feeling is "no, don't worry about prev go vesions" :) we r on 1.10, developing for 1.10 and ci uses 1.10 as well...
[01:18] <veebers> babbageclunk: sorry I'm AFK for the arvo. Um yeah I agree with anastasiamac go with 1.10, especially on develop. I can't think of a reason to need 1.8 compat at this stage
[01:28] <babbageclunk> veebers: oh right, forgot sorry! Thanks both of you - I'll use it then. Worst case, I can remove it if needed later.
=== CyberJacob_ is now known as CyberJacob
=== jacekn_ is now known as jacekn
[08:57] <stickupkid> manadart: when you've got a sec https://github.com/juju/juju/pull/8945
[09:39] <manadart> stickupkid: Commented.
[09:40] <stickupkid> manadart: so rick noted that he wanted to see this, but having done it, I'm with you, I just think it was a safety net that said if you wanted clustering, then we can make sure that we're talking the same thing
[09:42] <manadart> stickupkid: If your server is clustered, then its API supports clustering (> 3.0).
[09:42] <manadart> I'd put it on ice and talk to Rick when he's better.
[09:44] <stickupkid> manadart: i think this is superfluous in the end, and by the very nature the underlying nature will return false for everything < 3.0
[09:44] <manadart> stickupkid: Ja.
[10:05] <stub> cory_fu: I'm not sure if this is the same issue I saw before?  https://pastebin.ubuntu.com/p/XrByccMWyd/ . I think here the relation is gone (it is during teardown), and the endpoint lookup returns None, and it falls over
[10:09] <stub> Actually, the failure is in the install hook so the relation certainly doesn't exist at that point
[10:23] <stub> cory_fu: https://pastebin.ubuntu.com/p/fR8kjtvJQT/ does work, and  is better anyway. But it would be nice if we could handle this better.
[10:26] <stub> Would be ugly though.
[10:29] <stub> some special case rule 'if the handler accepts a single, required parameter and the relation used for RelationBase style handler invokation is None, skip calling the handler'
[10:29] <stub> Or fail better if silently skipping isn't an option.
[10:31] <stub> Maybe better for endpoint_from_state to never to return None if a suitable relation is defined, even if it hasn't been joined yet.
=== wpk_ is now known as wpk
[14:13] <stickupkid> Dmitrii-Sh: your PR failed with ProxyUpdaterSuite.TestSnapProxyConfig
[14:13] <stickupkid> link http://ci.jujucharms.com/job/github-check-merge-juju/2412/consoleFull
[14:19] <Dmitrii-Sh> stickupkid: ok, I will check the test out and modify it
[14:19] <Dmitrii-Sh> stickupkid: should be easy enough
[14:22] <jam> externalreality: manadart: now that we have a hash, you're building the snap into the 2.4 or latest candidate channel?
[14:24] <manadart> jam: I believe it will go to candidate channel in the 2.4 track.
=== ryebot_ is now known as ryebot
[14:55] <domc> Hello, I've installed charm 2.3.0 and charm-tools 2.2.4 and I'm trying to create a simple charm using command "charm create vanilla", is that supposed to still work? I am unable to get it to work, I keep getting "TypeError: a bytes-like object is required, not 'str'" in /snap/charm/158/lib/python3.5/site-packages/charmtools/templates/reactive_python/template.py
[15:41] <Dmitrii-Sh> stickupkid: just modified the PR
[16:17] <stickupkid> Juju cloud instructions for setting up a LXD Cluster can be found here: https://discourse.jujucharms.com/t/setting-up-lxd-cluster-as-a-juju-cloud/73
[17:02] <rick_h_> stickupkid:  woot!
[17:02] <stickupkid> rick_h_: manadart spent some time cleaning it up and verifying it for me - so thanks to him :D
[17:03] <rick_h_> bdx: magicaltrout cory_fu ^
[17:03] <rick_h_> zeestrat: ^
[17:03] <rick_h_> Ty too manadart. Solid team effort
[17:03] <rick_h_> So awesome
[17:04] <cory_fu> Nice
[17:04] <rick_h_> kwmonroe: as well ^
[17:04] <rick_h_> Any chance to.bang on it feedback welcome
[17:13] <Dmitrii-Sh> stickupkid: could you trigger another build? :^)
[17:13] <stickupkid> Dmitrii-Sh: sure
[17:13] <Dmitrii-Sh> thx
[17:46] <Dmitrii-Sh> stickupkid: looks like the test went well, thanks again
[18:06] <bdx> stickupkid, mandart: that is just awesome! thanks!
[20:33] <babbageclunk> hey hml, did you see my answer about the featureflag worker?
[20:33] <hml> babbageclunk: i did…
[20:33] <hml> babbageclunk: have to circle back to see what can be done for a non controller machine agent
[20:34] <babbageclunk> hml: you signed out before I could say, I don't think it would be *too* hard to change it to work via the api
[20:35] <hml> babbageclunk: hmm
[20:36] <babbageclunk> hml: the main difficulty is just the mismatch between the state.NotifyWatcher and watcher.NotifyWatcher (I think)
[20:38] <hml> babbageclunk: would it require a new featuretag manifold type?  or just modifications to the current?
[20:40] <babbageclunk> I think you could paper over the differences in the manifold with only minor changes to the ConfigSource interface. The manifold would need to switch between different input sources - either the APICaller or State, and wrap them differently to be ConfigSources.
[20:44] <babbageclunk> hml: want to have a hangout to chat about it?
[20:45] <hml> babbageclunk: can we do it tomorrow?  my brain is on other topics right now.  :-)
[20:46] <babbageclunk> sure sure
[20:50] <hml> babbageclunk: ty