[01:49] <axw> hml: we can't hear you
[01:49] <axw> hml: still there?
[02:12] <thumper> happy birthday axw :)
[02:12] <axw> thanks thumper :)
[02:13] <axw> thumper jam menn0: speaking of, I'm going out for lunch, so won't be able to make tech board today
[02:13] <thumper> ack
[02:14] <menn0> axw: np
[02:31] <babbageclunk> axw: Oh yeah, happy birthday! Hope the birthday lunch is super delish.
[02:31] <axw> babbageclunk: thanks
[02:42] <thumper> fuck, fuck, fuckity fuck
[02:42] <thumper> does anyone here understand leadership as it was in 1.25?
[02:44] <blahdeblah> thumper: You really know how to brighten my day. :-)
[02:44] <thumper> :)
[02:44] <thumper> blahdeblah: don't suppose you understand it?
[02:44] <blahdeblah> I don't, but axino might. :-)
[02:46] <thumper> looks like there should be an entry in the leases collection for it
[02:46] <thumper> but I don't see entries there for the services I expect
[02:46] <thumper> like...
[02:46] <thumper> there aren't any
[02:46] <thumper> just one for a clokc
[02:46] <thumper> clock
[02:47] <thumper> this is crack
[02:47] <veebers> Happy Birthday axw :-)
[02:47] <axw> thanks veebers
[02:49] <anastasiamac> thumper: dunno about 1.25 but in 2., leases collection has an aaplication-leader "clock" , there is also a "clock" and a "lease" per model in that collection... these r both tagged as "singular-controller"
[03:25]  * thumper sighs
[03:25] <thumper> FFS
[03:25] <thumper> my old DB dump didn't have any leases
[03:25] <thumper> but now they are there
[03:25] <thumper> why?...
[03:25] <thumper> I've got nothing
[04:41] <jam> menn0: btw, I'm no longer sure that deleting documents as you iterate was the cause of the problem vs the bson.M vs bson.D issue.
[04:42] <menn0> jam: could it have happened at any time?
[04:43] <jam> menn0: what I mean is that using the old "Id interface{}" meant that some % of the time documents would fail to be removed
[04:43] <jam> which might have been the actual cause of them not getting removed
[04:43] <jam> rather than deletions causing my iteration to be wrong.
[04:44] <menn0> jam: ok right
[05:15] <jam> menn0: so I've pushed up the changes from your review. IF you could look at it today so I can land this and then iterate on the next steps?
[05:15] <menn0> jam: looking now
[05:24] <menn0> jam: ship it on the first one
[05:26] <menn0> jam: why does the second one mention ericsnowcurrently? :)
[05:27] <menn0> jam: done
[07:13] <jam> menn0: I've seen something like that as well. Things like "this change was updated by ericsnowcurrently"
[07:13] <jam> thanks for the review
=== frankban|afk is now known as frankban
[09:24] <menn0> jam: could be the reviewboard integration as eric set that up?
[09:25] <jam> menn0: yeah, probably
[09:25] <jam> menn0: I wanted to run something by you
[09:25] <jam> menn0: I did find a few things running on a live controller
[09:25] <jam> one interesting thing
[09:25] <jam> is that it is actually reasonably to get down to 0 transactions in txns
[09:25] <jam> which means "pruneFactor" starts to become meaningless
[09:25] <jam> and it just causes pruning to run all the time
[09:26] <jam> menn0: yeah, I bet that's it, because it adds the reviewboard link to the pull request
[09:26] <jam> menn0: I'm thinking to add something that would make the behavior configurable / default to a minimum of 100/1000 transactions
[09:27] <jam> and maybe a maximum ignoring pruneFactor
[09:35] <SimonKLB> will LXC containers always show hardware specs as 0 ?
[09:55] <hoenir> After writing a provider and a api client from scratch it's amazing how well juju is structured in interfaces.
[09:56] <hoenir> And how easy is to embed and compose the functionalities. I really didn't need to look up on some docs or anything like that. I just watched and readed the code... on some places it laks comments but overall a good experience.
[09:56] <hoenir> Good job done guys !
[09:57] <hoenir> Well done..
[09:57] <hoenir> *
[09:57] <hoenir> Did anyone noticed this when writing a provideR?
[12:08] <Dmitrii-Sh> Hi. Question: https://jujucharms.com/docs/2.1/reference-charm-hooks#leader-elected <- this doc says "If the election process is done internally to the service, other code should be used to signal the leader to Juju.". However, I don't see any hook tools to assert leadership http://paste.ubuntu.com/24319908/ So, as far as I understand, there is no manual way
[12:08] <Dmitrii-Sh> to designate a leader and the doc is wrong. Does anyone know if it is supposed to be that way and if this has not been implemented for a reason?
[12:14] <Dmitrii-Sh> "Authors can use this hook to take action if their protocols for leadership, consensus, raft, or quorum require one unit to assert leadership." - this doesn't make much sense as well as if you have a network partition you may actually have multiple leaders in separated clusters. If Juju has access to both clusters, for example, it may get conflicting
[12:14] <Dmitrii-Sh> requests for leadership from that 'other code that signals internal notion of leadership to juju'
=== akhavr1 is now known as akhavr
[15:34] <admcleod> sinzui: fyi, magpie now does MTU
[15:34] <sinzui> admcleod: interesting. I will look soon
[15:38] <cmars> morning folks, could i get a review of https://github.com/juju/juju/pull/7195 please?
=== frankban is now known as frankban|afk
[21:04] <sinzui> babbageclunk: did you see bug 1680046
[21:04] <mup> Bug #1680046: Bootstrap failed on maas 1.9 because invalid character '<' looking for beginning of value <bootstrap> <ci> <maas-provider> <regression> <juju:Triaged by 2-xtian> <https://launchpad.net/bugs/1680046>
[21:11] <babbageclunk> sinzui: no I hadn't - looking now
[21:13] <babbageclunk> sinzui: is the test running against maas 1.9.5?
[21:15]  * sinzui looks
[21:17] <sinzui> babbageclunk: no, 1.9.4+bzr4592-0ubuntu1~trusty1. It is scheduled to be upgraded to 1.9.5+bzr4599-0ubuntu1~14.04.1 this weekend
[21:18] <sinzui> babbageclunk: I can make it upgrade right now
[21:18] <babbageclunk> sinzui: hmm, that might be it then. I ran my smoke test against 1.9.5.
[21:19] <babbageclunk> sinzui: Is breaking juju for 1.9.4  a problem?
[21:19] <babbageclunk> sinzui: (I can see that it might be.)
[21:20] <sinzui> babbageclunk: Awkward answer. the answe no we should not, but we do love the maas team when they say the only fix for a bug is to upgrade to the latest maas
[21:21] <babbageclunk> sinzui: yeah, sure - it would be pretty annoying for a user who has a working 1.9.4 maas
[21:21] <babbageclunk> sinzui: I'll roll back to my 1.9.4 snapshot and try to work out why it's broken against it.
[21:22] <sinzui> babbageclunk: 1.9.5 is only 6 days old. so few will have it. Like us we don't get updated every day. BUT....
[21:22] <sinzui> if you don't fix the issue soon, my maas will go to 1.9.5 anyway
[21:22] <babbageclunk> sinzui: yay easy fix!
[21:22] <babbageclunk> sinzui: j/k
[21:23] <sinzui> babbageclunk: I am half serious myself. I think the issue will fix itself if I don't interviene with the servers update schedule
[21:25] <babbageclunk> sinzui: well, I guess we can discuss more in about 5 mins
[21:25] <anastasiamac> babbageclunk: sinzui: it's on the list \o/
[21:25] <anastasiamac> (minutes)*
[21:55] <cmars> morning folks, can i get a review of https://github.com/juju/description/pull/11 please?
[21:56] <cmars> https://github.com/juju/juju/pull/7202 will soon follow
[22:05] <babbageclunk> sinzui: weirdly, I can bootstrap on 1.9.4, although it requires a lot of retries for the bootstrap to successfully ssh to the deployed controller machine
[23:03] <babbageclunk> sinzui: Could I get access to the maas where this test was failing?
[23:16] <babbageclunk> sinzui: no worries, I worked it out - bootstrapping against it now.
[23:16] <sinzui> babbageclunk: you may already have,. did I send you the snippetsmfrom cloud-city to get into munna?
[23:17] <babbageclunk> sinzui: I eventually remembered to look in there.
[23:17] <sinzui> babbageclunk: are you in?
[23:18] <babbageclunk> sinzui: yup yup
[23:25] <babbageclunk> sinzui: ok, I see why my smoke test didn't find this now.