[00:21] 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] a123: is the controller still bootstrapped? [00:37] sinzui: http://reviews.vapour.ws/r/4795/ [00:39] 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] anastasiamac, cherylj, wallyworld: sorry... i'm getting major packet loss... trying to fix [00:49] menn0: get a new hamster === rodlogic is now known as Guest97922 [01:04] yes, I believe so. juju show-controller returns with output, but juju show-model returns the same Warning. [01:07] 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] cherylj: yes. ssh to the machine works. [01:10] 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] cherylj: I see quite a few errors. Is there some way to restart some service which is listening on 17070? [01:20] a123: you can restart the jujud process on that machine [01:20] 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] (you can just use kill for the jujud process) [01:22] cherylj: kill as in: kill -HUP ? [01:27] cherylj: Awesome. Thanks, restarting the service worked. === rodlogic is now known as Guest47802 [02:04] Bug #1579976 opened: Charms cached for a model are not removed when the model is destroyed [02:13] Bug #1579976 changed: Charms cached for a model are not removed when the model is destroyed [02:19] Bug #1579976 opened: Charms cached for a model are not removed when the model is destroyed [02:40] 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] all models have a default series [02:40] but I think you are right [02:41] that would be a better default IMO [02:42] natefinch: the charm author recommends via the charm's preferred series what they wnt the charm on; well that was the thinking [02:42] i think that is better too perhaps [02:42] 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] so long as the default-series attr is explicitly set [02:43] wallyworld: yep, I'm assuming we only take it into consideration if it's explicitly set. [02:44] sgtm === rodlogic is now known as Guest50280 [03:05] 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] natefinch: charms are allowed not to define any series [03:09] wallyworld: wow, really? ok. [03:09] sure, legacy charms [03:09] * thumper heads afk for a bit [03:09] wallyworld: well, those have the series in the url [03:09] taking something to do email [03:10] on [03:10] bbl [03:10] natefinch: only if yu access using the url with the series [03:10] also local charms [03:10] wallyworld: I guess if you're deploying an old-style local charm [03:10] *nod* [03:10] ok [03:10] it's a corner case for sure [03:11] yep [03:11] we can tighten up the rules ar some point [03:52] 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] natefinch: i think it defaults to any series, but can't recall 100% [03:54] --force is normally just for when we override the series [03:55] forcing a trusty charm onto a xenial host for example [03:55] 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] the issue being fixes wasn't accounted for in the first place afair [03:56] ie it is behaving as designed, but the design is wrong [04:01] 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] ok, that check sounds wrong i think [04:03] been a while [04:03] since i saw that code [04:03] 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] there should just be one method to change i think , charmSeries() [04:06] wallyworld: yep. That's part of the problem, honestly. It's a lot clearer as more than one method. [04:07] not sure i agree off hand - one place to do series resolution makes sense to me [04:07] instesd of spreading the logic all over the place [04:08] as in - take these inputs, and tell me what series to use according to the buesiness rules [04:08] wallyworld: sorry... it's still one function call at the point of request... it just splits out some logic into sub functions [04:08] to reuse a little code and make the logical progression easier to follow. [04:10] ok === rodlogic is now known as Guest7886 [05:08] EOD for me. === rodlogic is now known as Guest67605 === rodlogic is now known as Guest18647 === thumper is now known as thumper-afk === frankban|afk is now known as frankban === rodlogic is now known as Guest6082 === thumper-afk is now known as thumper [08:11] jam: hey [08:11] jam: can we get a time to chat about networking? === rodlogic is now known as Guest81321 [09:02] dimitern: standup? [09:02] voidspace: omw [09:33] dimitern, http://reviews.vapour.ws/r/4796/diff/ [09:33] fwereade: cheers, will have a look shortly [10:15] jam: ping === rodlogic is now known as Guest87809 === dimitern is now known as dimitern|afk === dimitern|afk is now known as dimitern === rodlogic is now known as Guest48101 === rodlogic is now known as Guest2307 [13:33] Bug #1579051 opened: Race in juju/controller/destroy and TestDestroyCommandConfirmation

[13:33] Bug #1580184 opened: Timeout in github.com/juju/juju/apiserver/service on windows

[13:34] voidspace, dooferlad, babbageclunk: any objections to dropping maas-spaces-multi-nic-containers-with-master branch from juju/juju ? === rodlogic is now known as Guest28754 [14:03] Bug #1580186 opened: Race in github.com/juju/juju/worker/instancepoller/aggregate_test.go

[14:14] dimitern: no [14:14] dimitern: no objections that is :-) === rodlogic is now known as Guest8122 [14:46] voidspace: cheers === Makyo|Vacay is now known as Makyo [15:03] ericsnow: standup time [15:04] 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] 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] natefinch, so long as we're clear about why we're not deploying it ofc [15:07] 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] natefinch, +100 === rodlogic is now known as Guest54704 [15:33] Bug #1580221 opened: Failure to connect to API server causes worker.ErrTerminateAgent.

=== rodlogic is now known as Guest38353 [16:03] is the spelling yakkety or yakety? [16:03] for 16.10? [16:03] Bug #1580231 opened: Machine agent is uninstalled when it shouldn't be.

[16:04] redir_: I spell it 16.10 :p [16:04] redir_: two ks [16:04] tx [16:32] brb relocating [16:43] fwereade: whew.. sorry it took so long, but you have a review [16:43] (too much mail today) [16:45] dimitern, tyvm === rodlogic is now known as Guest8087 [17:06] is Juju 2.0 supposed to register containers as a device now? [17:06] with MAAS === frankban is now known as frankban|afk === rodlogic is now known as Guest99896 [18:01] jog: no idea... the maas provider got revamped at the last second to work with maas 2, so anything is possible [18:02] jog: thumper or jam would know [18:02] natefinch, ok === rodlogic is now known as Guest21410 [18:52] katco: are you here? [18:58] jog, what are you looking for? I missed the question [18:59] alexisb, just wondering if I should see containers registered with MAAS 1.9 and Juju 2.0 [19:01] jog, yes [19:01] lxd containers === rodlogic is now known as Guest29652 [20:10] Bug #1580314 opened: MainSuite.TestFirstRun2xFrom1xOnUbuntu Exec function not called on windows

[20:28] jog: yes, containers get registered as devices [20:29] AFAICT [20:31] 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? === rodlogic is now known as Guest74084 [20:38] jog beta's do not yet treat lxc like lxd in bundles [20:54] thumper, hey, is `loggo.Logger{}.Logf("whatever")` meant to work? [20:55] um... Logf isn't a function [20:55] well [20:55] not with that signature [20:55] fwereade: but yes... generally [20:56] thumper, oops [20:57] thumper, anyway, it looks like it doesn't, we dereference a nil impl pointer in LogCallf [20:57] hmm... who is doing that? [20:57] not the deref [20:58] but using loggo.Logger{} [20:58] thumper, I was passing a Logger{} into a worker and thinking the empty one'd work for the tests [20:59] I think it used to [21:00] thumper, yeah, I had a vague expectation that it would work [21:00] thumper, anyway nbd === natefinch is now known as natefinch-afk === rodlogic is now known as Guest73492 [22:45] * perrito666 is not loving mongo right now [22:47] thumper, wallyworld if you guys have 5 minutes I could use some of your time [22:48] alexisb: ack [22:48] thumper, lets jump onto the juju-core-leads HO [22:48] alexisb: otp, give me a minute [22:48] wallyworld, cna join us when he is ready [22:49] thumper, wallyworld: https://hangouts.google.com/hangouts/_/canonical.com/core-leads-call [22:59] that is a long minute wallyworld ;) [23:00] alexisb: brt [23:15] anastasiamac: axw: redir: perrito666: in meeting, a minute late [23:15] wallyworld: sure, ping when ready \o/ [23:26] anastasiamac: there now