[00:21] <a123> Has anyone seen this error while running: juju status?  [11:33:27] $ juju status WARNING discarding API open error: connecting with cached addresses: unable to connect to API: websocket.Dial wss://10.0.4.168:17070/model/ce4d207c-a4f0-4381-8961-f8d9decee6c6/api: dial tcp 10.0.4.168:17070: getsockopt: connection refused ERROR connecting with bootstrap config: unable to connect to API: websocket.Dial wss://10.0.4.168:17070/model/ce4d207c
[00:26] <cherylj> a123: is the controller still bootstrapped?
[00:37] <redir> sinzui: http://reviews.vapour.ws/r/4795/
[00:39] <redir> or anyone  else http://reviews.vapour.ws/r/4795/
[00:40]  * redir steps away for a minute
[00:48]  * redir actually leaves now.
[00:49] <menn0> anastasiamac, cherylj, wallyworld: sorry... i'm getting major packet loss... trying to fix
[00:49] <wallyworld> menn0: get a new hamster
[01:04] <a123> yes, I believe so. juju show-controller returns with output, but juju show-model returns the same Warning.
[01:07] <cherylj> a123: show-controller just inspects things in your cache.  It doesn't go to the controller.  Can you ssh into the machine directly?
[01:09] <a123> cherylj: yes. ssh to the machine works.
[01:10] <cherylj> a123: at this point, you'd want to inspect /var/log/juju/machine-0.log to see if there's a problem with the controller
[01:20] <a123> cherylj: I see quite a few errors. Is there some way to restart some service which is listening on 17070?
[01:20] <cherylj> a123: you can restart the jujud process on that machine
[01:20] <a123> cherylj: Here's one ERROR example: 2016-05-09 07:53:34 ERROR juju.rpc server.go:576 error writing response: write tcp 127.0.0.1:17070->127.0.0.1:50818: write: broken pipe
[01:21] <cherylj> (you can just use kill for the jujud process)
[01:22] <a123> cherylj: kill as in: kill -HUP <pid of jujud>?
[01:27] <a123> cherylj: Awesome. Thanks, restarting the service worked.
[02:04] <mup> Bug #1579976 opened: Charms cached for a model are not removed when the model is destroyed <juju-core:Triaged> <https://launchpad.net/bugs/1579976>
[02:13] <mup> Bug #1579976 changed: Charms cached for a model are not removed when the model is destroyed <juju-core:Triaged> <https://launchpad.net/bugs/1579976>
[02:19] <mup> Bug #1579976 opened: Charms cached for a model are not removed when the model is destroyed <juju-core:Triaged> <https://launchpad.net/bugs/1579976>
[02:40] <natefinch> axw, thumper, wallyworld:  if you deploy a multi-series charm without specifying a series, and you have a default series in your model that matches one of the charm's series, shouldn't we default to that?  Right now the code defaults to the charm's preferred series (first listed).
[02:40] <thumper> all models have a default series
[02:40] <thumper> but I think you are right
[02:41] <thumper> that would be a better default IMO
[02:42] <wallyworld> natefinch: the charm author recommends via the charm's preferred series what they wnt the charm on; well that was the thinking
[02:42] <wallyworld> i think that is better too perhaps
[02:42] <natefinch> wallyworld: sure, but we have to choose to listen to the charm author or the model admin... seems like the model admin wins, as long as the charm author says the series is ok
[02:43] <wallyworld> so long as the default-series attr is explicitly set
[02:43] <natefinch> wallyworld: yep, I'm assuming we only take it into consideration if it's explicitly set.
[02:44] <wallyworld> sgtm
[03:05] <natefinch> thumper, wallyworld: there's some code in here about deploying to the latest LTS series.... but I don't really understand when we'd ever actually get to that point.  It seems to be the case only if somehow the charm has no series defined, which I would expect would not be a valid charm.
[03:09] <wallyworld> natefinch: charms are allowed not to define any series
[03:09] <natefinch> wallyworld: wow, really?  ok.
[03:09] <wallyworld> sure, legacy charms
[03:09]  * thumper heads afk for a bit
[03:09] <natefinch> wallyworld: well, those have the series in the url
[03:09] <thumper> taking something to do email
[03:10] <thumper> on
[03:10] <thumper> bbl
[03:10] <wallyworld> natefinch: only if yu access using the url with the series
[03:10] <wallyworld> also local charms
[03:10] <natefinch> wallyworld: I guess if you're deploying an old-style local charm
[03:10] <natefinch> *nod*
[03:10] <natefinch> ok
[03:10] <wallyworld> it's a corner case for sure
[03:11] <natefinch> yep
[03:11] <wallyworld> we can tighten up the rules ar some point
[03:52] <natefinch> wallyworld: so if you deploy a charm with no series specified in it, do we ever need to use --force? i.e. do we accept any series for that charm?
[03:54] <wallyworld> natefinch: i think it defaults to any series, but can't recall 100%
[03:54] <wallyworld> --force is normally just for when we override the series
[03:55] <wallyworld> forcing a trusty charm onto a xenial host for example
[03:55] <natefinch> wallyworld: ok.... I'd look at the code, but I'm trying to fix a bug in that code, so I don't trust it :)
[03:56] <wallyworld> the issue being fixes wasn't accounted for in the first place afair
[03:56] <wallyworld> ie it is behaving as designed, but the design is wrong
[04:01] <natefinch> wallyworld: well, the code is kinda borked as-is.  it'll never deploy to latest LTS, because it checks if the latest LTS exists in the supported series list, except we've already verified at that point that the supported series list is empty.
[04:02] <wallyworld> ok, that check sounds wrong i think
[04:03] <wallyworld> been a while
[04:03] <wallyworld> since i saw that code
[04:03] <natefinch> wallyworld: yeah, it's all a little messed up.  I'm reworking it to be a lot easier to follow logically, as well as fixing the bug.
[04:04] <wallyworld> there should just be one method to change i think , charmSeries()
[04:06] <natefinch> wallyworld: yep.  That's part of the problem, honestly.  It's a lot clearer as more than one method.
[04:07] <wallyworld> not sure i agree off hand - one place to do series resolution makes sense to me
[04:07] <wallyworld> instesd of spreading the logic all over the place
[04:08] <wallyworld> as in - take these inputs, and tell me what series to use according to the buesiness rules
[04:08] <natefinch> wallyworld: sorry... it's still one function call at the point of request... it just splits out some logic into sub functions
[04:08] <natefinch> to reuse a little code and make the logical progression easier to follow.
[04:10] <wallyworld> ok
[05:08] <natefinch> EOD for me.
[08:11] <thumper> jam: hey
[08:11] <thumper> jam: can we get a time to chat about networking?
[09:02] <voidspace> dimitern: standup?
[09:02] <dimitern> voidspace: omw
[09:33] <fwereade> dimitern, http://reviews.vapour.ws/r/4796/diff/
[09:33] <dimitern> fwereade: cheers, will have a look shortly
[10:15] <rick_h_> jam: ping
[13:33] <mup> Bug #1579051 opened: Race in juju/controller/destroy and TestDestroyCommandConfirmation <blocker> <ci> <intermittent-failure> <race-condition> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1579051>
[13:33] <mup> Bug #1580184 opened: Timeout in github.com/juju/juju/apiserver/service on windows <blocker> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1580184>
[13:34] <dimitern> voidspace, dooferlad, babbageclunk: any objections to dropping maas-spaces-multi-nic-containers-with-master branch from juju/juju ?
[14:03] <mup> Bug #1580186 opened: Race in github.com/juju/juju/worker/instancepoller/aggregate_test.go <blocker> <ci> <intermittent-failure> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1580186>
[14:14] <voidspace> dimitern: no
[14:14] <voidspace> dimitern: no objections that is :-)
[14:46] <dimitern> voidspace: cheers
[15:03] <katco> ericsnow: standup time
[15:04] <natefinch> fwereade: if you juju deploy a local charm without series-in-metadata, so we don't know what series it supports... do we always require --force or never?  My preference would be for always, since we don't have any idea if it'll work on any particular series.
[15:06] <fwereade> natefinch, yeah, I think you're right -- that should map well to the developing-the-charm case, I think, in which case adding the series is no hardship and what you're meant to do anyway
[15:06] <fwereade> natefinch, so long as we're clear about why we're not deploying it ofc
[15:07] <natefinch> fwereade: cool, yep, I'll make sure it gives a clear reason why we're refusing to deploy without --force.  It's an edge case, but still want to make it clear for the user.
[15:08] <fwereade> natefinch, +100
[15:33] <mup> Bug #1580221 opened: Failure to connect to API server causes worker.ErrTerminateAgent. <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1580221>
[16:03] <redir_> is the spelling yakkety or yakety?
[16:03] <redir_> for 16.10?
[16:03] <mup> Bug #1580231 opened: Machine agent is uninstalled when it shouldn't be. <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1580231>
[16:04] <perrito666> redir_: I spell it 16.10 :p
[16:04] <mgz> redir_: two ks
[16:04] <redir_> tx
[16:32] <redir_> brb relocating
[16:43] <dimitern> fwereade: whew.. sorry it took so long, but you have a review
[16:43] <dimitern> (too much mail today)
[16:45] <fwereade> dimitern, tyvm
[17:06] <jog> is Juju 2.0 supposed to register containers as a device now?
[17:06] <jog> with MAAS
[18:01] <natefinch> jog: no idea... the maas provider got revamped at the last second to work with maas 2, so anything is possible
[18:02] <natefinch> jog: thumper or jam would know
[18:02] <jog> natefinch, ok
[18:52] <natefinch> katco: are you here?
[18:58] <alexisb> jog, what are you looking for?  I missed the question
[18:59] <jog> alexisb, just wondering if I should see containers registered with MAAS 1.9 and Juju 2.0
[19:01] <alexisb> jog, yes
[19:01] <alexisb> lxd containers
[20:10] <mup> Bug #1580314 opened: MainSuite.TestFirstRun2xFrom1xOnUbuntu Exec function not called on windows <blocker> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1580314>
[20:28] <thumper> jog: yes, containers get registered as devices
[20:29] <thumper> AFAICT
[20:31] <jog> thumper, I've deployed the openstack-base/42 bundle, which uses lxc. I don't see any devices registered with maas 1.9.2 but alexisb said they are only registered when lxd is used?
[20:38] <alexisb> jog beta's do not yet treat lxc like lxd in bundles
[20:54] <fwereade> thumper, hey, is `loggo.Logger{}.Logf("whatever")` meant to work?
[20:55] <thumper> um... Logf isn't a function
[20:55] <thumper> well
[20:55] <thumper> not with that signature
[20:55] <thumper> fwereade: but yes... generally
[20:56] <fwereade> thumper, oops
[20:57] <fwereade> thumper, anyway, it looks like it doesn't, we dereference a nil impl pointer in LogCallf
[20:57] <thumper> hmm... who is doing that?
[20:57] <thumper> not the deref
[20:58] <thumper> but using loggo.Logger{}
[20:58] <fwereade> thumper, I was passing a Logger{} into a worker and thinking the empty one'd work for the tests
[20:59] <thumper> I think it used to
[21:00] <fwereade> thumper, yeah, I had a vague expectation that it would work
[21:00] <fwereade> thumper, anyway nbd
[22:45]  * perrito666 is not loving mongo right now
[22:47] <alexisb> thumper, wallyworld if you guys have 5 minutes I could use some of your time
[22:48] <thumper> alexisb: ack
[22:48] <alexisb> thumper, lets jump onto the juju-core-leads HO
[22:48] <wallyworld> alexisb: otp, give me a minute
[22:48] <alexisb> wallyworld, cna join us when he is ready
[22:49] <alexisb> thumper, wallyworld: https://hangouts.google.com/hangouts/_/canonical.com/core-leads-call
[22:59] <alexisb> that is a long  minute wallyworld ;)
[23:00] <wallyworld> alexisb: brt
[23:15] <wallyworld> anastasiamac: axw: redir: perrito666: in meeting, a minute late
[23:15] <anastasiamac> wallyworld: sure, ping when ready \o/
[23:26] <wallyworld> anastasiamac: there now