[00:08] <mwhudson_> davecheney: so i talked to steve and we're going to go for uploading go1.5rc1 within a week
[00:08] <mwhudson_> davecheney: enabling arm64 and ppc64el (with your patch!)
[00:08] <mwhudson_> davecheney: i wanted to give you a chance to yell and say "don't enable it for ppc64el" or similar
[00:09] <mwhudson_> davecheney: is there anyone else I should talk to about this? (qa team?)
[00:19] <davecheney> mwhudson_: i'm testing ppc64 right now
[00:19] <davecheney> ./all.bash passes
[00:19] <davecheney> and i'm doing juju stress tests today
[00:19] <davecheney> so, yes, please include that patch in rc1
[00:19] <davecheney> there _will_ be a 1.5rc2
[00:20] <davecheney> probably at the end of the week
[00:20] <davecheney> i dunno if my patch will make it in
[00:24] <mup> Bug #1483932 opened: unexpected public-address when lxc container has 2 NICs and IP addresses <juju-core:New> <https://launchpad.net/bugs/1483932>
[00:28] <davecheney> mwhudson_: russ +2'd my patch to disable duffzero
[00:28] <mwhudson_> davecheney: oh ok, maybe we'll upload 1.5rc2 then, depends on timings
[00:28] <davecheney> i'll commit it in a few hours once' i've done some more testing
[00:28] <mwhudson_> davecheney: yay!
[00:29]  * mwhudson_ disappears for a bit
[02:26] <axw> waigani cherylj: I'd really appreciate reviews of http://reviews.vapour.ws/r/2332 before any of my other branches. this needs to land before the freeze next week; preferably this week, since I'm sprinting next week
[02:28] <waigani> axw: I'm half way through 2331, should be done soon. Then I'll get onto that one
[02:28] <axw> waigani: awesome, thanks
[02:39] <menn0> thumper: forgot to say. a number people have been hitting bootstrap problems where it appears mongodb isn't starting
[02:40] <menn0> thumper: it's happening on both upstart and systemd systems
[02:40] <menn0> thumper: https://launchpadlibrarian.net/213796443/juju_debug_output.txt
[02:40] <menn0> thumper: bug 1468579
[02:40] <mup> Bug #1468579: juju bootstrap failed - cannot dial mongo to initiate replicaset: no reachable servers <bootstrap> <mongodb> <oil> <juju-core:Triaged by menno.smits> <juju-core 1.24:Triaged by menno.smits> <https://launchpad.net/bugs/1468579>
[02:40] <menn0> thumper: I need to give that some attention soon as well
[02:44] <thumper> hmm...
[02:44] <thumper> menn0: do you know what the cause is?
[02:45] <menn0> thumper: no idea... I was kinda thinking a systemd integration issue, but james page has just reported the issue on trusty
[02:46] <menn0> thumper: i'm going to ask people to provide /var/log/syslog for when the problem happens. that might tell us if/why mongod isn't starting
[02:46]  * thumper nods
[02:48] <lazyPower> thumper: o/
[02:49] <thumper> lazyPower: 'sup?
[02:49] <lazyPower> Just checking in on ya, i haven't pulse checked django in a while
[02:50] <thumper> hmm...
[02:50] <thumper> I've been a bit lax
[02:50] <thumper> although likely to roll out some personal changes soon
[02:50] <thumper> so no doubt, a few pushes upstream
[02:50] <lazyPower> no stress, the last time we spoke you were working on workers
[02:50] <thumper> lazyPower: what is best practise for dealing with charm tools?
[02:50] <thumper> should we pip install?
[02:50] <lazyPower> fill me in on the context
[02:50] <lazyPower> ah
[02:51] <lazyPower> If you need bleeding edge, thats the way to go
[02:51] <lazyPower> i keep a branch around in a venv for bleeding edge, pypi release, and system defaults to debs
[02:51] <lazyPower> context switching is fairly painless then
[02:51] <thumper> more just don't want it included in the charm tree
[02:52] <lazyPower> i bzrignore .venv and keep all the project deps around in a virtualenv.
[02:52] <thumper> problem becomes the main hook .py file uses it
[02:52] <thumper> so needs it to install  :)
[02:52] <lazyPower> hmm, what are you pulling in from charm tools?
[02:52]  * thumper shrugs
[02:52] <thumper> normal stuff I guess
[02:53] <thumper> not looked in detail
[02:53] <lazyPower> are you talking about charm-helpers then?
[02:53] <thumper> uh... yeah
[02:53] <thumper> that
[02:53] <lazyPower> ah ok :)  Common mistake
[02:53] <lazyPower> yeah, I personally use the pypi delivery mechanism for charm-helpers
[02:53] <thumper> and install?
[02:54] <lazyPower> on the other hand, our openstack team is very much steeped in embedding charm-helpers in the charm with the sync scripts
[02:54] <lazyPower> that way they can independently version/control the version of charm helpers shipping with the charms.
[02:54] <thumper> also, what is the best practice for storing state in a charm?
[02:54] <thumper> does the charm helpers help there?
[02:54] <lazyPower> i use the kv helpers in charmhelpers
[02:54] <lazyPower> indeed
[02:55] <lazyPower> https://pythonhosted.org/charmhelpers/api/charmhelpers.core.unitdata.html
[02:55] <lazyPower> its kv storage for charms backed by sqlite (disclaimer) - i'm using it in the ETCD charm if you'd like to see a usage example in practice
[02:56] <menn0> waigani: i just replied to your review comments
[02:56] <thumper> lazyPower: yeah, should look
[02:56] <lazyPower> thumper: https://github.com/whitmo/etcd-charm/blob/master/hooks/hooks.py#L127 - is a method body thats using it. its pretty straight forward
[02:57] <lazyPower> getters/setters
[02:57] <thumper> cheers
[02:58] <davecheney> mwhudson_: https://go-review.googlesource.com/#/c/13570/2
[02:59] <davecheney> i commented out the wrong duffzero the first time around
[02:59] <davecheney> PTAL
[02:59] <mwhudson_> ah
[02:59] <lazyPower> davecheney: sorry to sideline this topic - are yinz no longer using reviewboard?
[02:59] <davecheney> this one does actually fix the bug in juju
[02:59] <davecheney> lazyPower: this isn't a juju patch
[02:59] <davecheney> it's for go upstream
[02:59] <lazyPower> ooo
[02:59] <davecheney> we're trying to land some last minute fixes for ppc64
[02:59] <lazyPower> ok, i've heard great things about gerrit so thought I'd ask :)
[03:00] <davecheney> i think gerrit is ok
[03:00] <davecheney> but out of the box is blows
[03:00] <lazyPower> duly noted
[03:00] <davecheney> to go one has a full time person tending to it's ministrations
[03:00] <davecheney> custom skin
[03:00] <davecheney> custom email notifcation
[03:00] <davecheney> a host of bots covering it's various failings
[03:00] <lazyPower> needs some juju loving is what you're telling me. get a stellar gerrit out of the box  preconfigured for joyous ruptures of usage goodness
[03:01] <davecheney> that's sort of like saying "want a fantastic career, then get a super duper diploma from the university of new mexico. apply online today!"
[03:02] <lazyPower> Exactly, marketing speak to make it sound greater than it really is
[03:03] <davecheney> caution: results may not represent real life. Please consult a health care professional before deciding if online education is right for your family
[03:03] <thumper> :)
[03:04] <lazyPower> davecheney: its really funny that you mention that ;) Thats exactly the sector of marketing my last jobs clients were from. So i've got a long history of working in that bubble you used as an example :D
[03:04] <davecheney> as we said at the market maker
[03:04] <davecheney> past performance is not a predictor of future profit
[03:11] <lazyPower> davecheney: "at the market maker" i dont follow
[03:15] <davecheney> share trading firms call themselves market makers
[03:15] <lazyPower> oh nice. #TIL
[03:15] <davecheney> for the same reason people that like to break into other peoples shit call themselves security researchers
[03:25] <waigani> menn0: thanks, just replied to yours :)
[04:25] <menn0> waigani: next one: http://reviews.vapour.ws/r/2350/ (much smaller)
[04:26] <waigani> menn0: looking
[04:36] <waigani> menn0: done
[04:37] <menn0> waigani: thank you
[06:34] <mup> Bug #1483987 opened: [LXC caching] deletion of images does not work <juju-core:New> <https://launchpad.net/bugs/1483987>
[06:37] <mup> Bug #1483987 changed: [LXC caching] deletion of images does not work <juju-core:New> <https://launchpad.net/bugs/1483987>
[06:46] <mup> Bug #1483987 opened: [LXC caching] deletion of images does not work <juju-core:New> <https://launchpad.net/bugs/1483987>
[07:30] <voidspace> dimitern: hey, morning
[07:31] <voidspace> dimitern: I saw your review on my AllSpaces branch after I already had a "Ship It" from dooferlad
[07:31] <TheMue> voidspace: good morning and happy birthday
[07:31] <voidspace> dimitern: so I've addressed your comments in a follow-up branch that I'll submit now
[07:31] <voidspace> TheMue: bah, humbug :-)
[07:31] <voidspace> TheMue: morning
[07:31] <dimitern> voidspace, hey, yes I saw you landed it too late
[07:32] <voidspace> dimitern: there were some good suggestions in your comments though
[07:32] <dimitern> voidspace, oh happy birthday indeed! :)
[07:32] <voidspace> dimitern: hah, bah
[07:32] <voidspace> as if I want to be reminded that I'm getting old...
[07:32] <dimitern> voidspace, hehe
[07:33] <dimitern> voidspace, well, if you like them you can do a follow-up ;)
[07:33] <voidspace> dimitern: done
[07:33] <voidspace> dimitern: just needs me to create the pull request
[07:33] <voidspace> dimitern: just completing a final test run before I do that
[07:33] <TheMue> voidspace: you're getting old? I'm just laughing. *lol*
[07:34] <voidspace> TheMue: :-)
[07:34] <dimitern> voidspace, cheers!
[07:34] <dimitern> I had some bad headache yesterday night
[07:35] <voidspace> too much vodka?
[07:35] <dimitern> so I might be taking it slower today
[07:35] <voidspace> ok
[07:35] <voidspace> dimitern: did you see our EuroPython video went live?
[07:35] <dimitern> no, 36 degrees during the day and 28 at night I guess
[07:35] <voidspace> dimitern: I posted a link on twitter and google+
[07:35] <voidspace> dimitern: :-(
[07:35] <dimitern> voidspace, in g+ ?
[07:35] <voidspace> dimitern: yep
[07:35] <dimitern> voidspace, I didn't realize it was the video as well - cool!
[07:40] <voidspace> dimitern: http://reviews.vapour.ws/r/2352/
[07:41] <dimitern> voidspace, looking
[07:43] <voidspace> dimitern: there's a DeferredAnnotatef - which is why I removed the errors.Trace(err)
[07:43] <voidspace> dimitern: before you ask
[07:44] <dimitern> voidspace, ok, as long as we're not ignoring an error
[07:44] <dimitern> voidspace, LGTM
[07:45] <voidspace> dimitern: thanks
[07:45] <voidspace> dimitern: I don't assertSpace on them because there's already a test that does that
[07:46] <voidspace> dimitern: this isn't a test for AddSpace
[07:46] <voidspace> dimitern: it's a test for AllSpaces
[07:46] <voidspace> dimitern: if AddSpace is broken there's another test that will fail
[07:47] <voidspace> dimitern: once a unit of code is tested it's reasonable to assume that unit works for a test of a different unit
[07:47] <voidspace> so long as you have *a test* that will fail if it breaks
[07:47] <voidspace> dimitern: so I'll pick up subnets CLI next
[07:48] <voidspace> dimitern: and work CLI -> api -> apiserver -> state again
[07:49] <dimitern> voidspace, agreed, sounds good
[07:50] <voidspace> dimitern: hmm... weird. We have CLI of subnet list, apiserver of space create and state of subnet add
[07:50] <voidspace> dimitern: still left to do
[07:50] <voidspace> dimitern: still, I can do them in CLI -> apiserver -> state order, they're just all different pieces of functionality...
[07:52] <dimitern> voidspace, for state "add" means both create and add in api/cli terms
[07:52] <dimitern> voidspace, create just first creates the subnet
[07:52] <dimitern> (with the provider api)
[07:54] <voidspace> dimitern: add ought to check with the provider
[07:54] <voidspace> dimitern: right? as it's semantically "add a space that already exists with the provider"
[07:54] <voidspace> dimitern: or subnet
[07:55] <dimitern> voidspace, yes, but not at state level, at apiserver level
[07:56] <dimitern> voidspace, once we get the info from the provider, we still eventually call state add
[07:58] <voidspace> dimitern: yep
[08:56] <voidspace> dimitern: dooferlad: TheMue: I'll be a few minutes late to stdup, sorry
[08:57] <dimitern> np
[08:58] <TheMue> ok
[08:59] <dooferlad> dimitern: it has been pointed out that my CI test has something trying to ping google, but we want to have the test pass on closed networks. Was thinking about pinging the default gateway instead, if it is defined.
[09:00] <dooferlad> of course not having a default gateway when there should be one is a problem, but it isn't related to what Juju does.
[09:01] <dimitern> dooferlad, yeah, sounds good - perhaps instead of google try archive.ubuntu.com
[09:10] <dimitern> voidspace, ;)
[09:13] <voidspace> dimitern: omw
[09:41] <mattyw> axw, ping?
[09:48] <mattyw> morning, afternoon all. Review request 2332 has been issued some kind of award by reviewboard. Can anyone work out the reference? http://reviews.vapour.ws/r/2332/
[10:03] <perrito666> Mattyw no idea but the code for rb is open
[10:58] <axw> mattyw: pong, what's up?
[10:59] <mattyw> axw, review #2332 got some kind of trophy for being 2332
[10:59] <mattyw> axw, but I don't understand the reference, thought you might like to know
[10:59] <axw> mattyw: heh yeah, I looked at the code a while ago, it's for palindromic numbers
[11:00] <axw> mattyw: but why.. I don't know
[11:01] <mattyw> axw, hmm, I'm glad they took the time to do that
[11:01] <axw> mattyw: :)
[11:02] <perrito666> lool
[11:02] <perrito666> they also did it for review 1000 or 1024
[11:05] <mattyw> right
[11:06] <mattyw> so if reviewNum in someListOfNumbersWeLikeForWhateverReason { printTrophy() }
[11:06] <perrito666> yup
[11:07] <mattyw> I'd have probably fixed being able to display files that have moved before tackling that feature
[11:07] <mattyw> but that's just me
[11:10] <perrito666> mattyw: I am pretty sure that if number in list of numbers is a rather easy feature compared to the other thing
[11:11] <perrito666> also it is free software, you can always fix being able to display files that have moved
[11:44] <TheMue> dimitern: pushed the PR again
[11:51] <dimitern> TheMue, ok, will have a look shortly
[11:51] <TheMue> dimitern: thx
[12:31] <dimitern> TheMue, hey
[12:32] <dimitern> TheMue, take a look at this: http://play.golang.org/p/QHyS4l9JvB
[12:32] <TheMue> dimitern: yep
[12:33] <dimitern> TheMue, it shows clearly that returning nil if result.Error == nil is better than returning it (even with Trace) if result.Error != nil
[12:33] <TheMue> dimitern: yep
[12:34] <dimitern> TheMue, that way when a nil error is returned, it will always be an untyped nil and the ErrorIsNil will work
[12:34] <dimitern> TheMue, as I was about to add a comment about a few places with IsNil wanted to see what was the way to fix it
[12:36] <TheMue> dimitern: makes sense, yes. will change the two API functions as well as their tests
[12:37] <TheMue> dimitern: ugly, those nil but not nil errors
[12:47] <mup> Bug #1484105 opened: juju upgrade-charm returns ERROR state changing too quickly; try again soon <juju-core:New> <https://launchpad.net/bugs/1484105>
[12:55] <voidspace> dimitern: ping
[12:59] <TheMue> dimitern: feels good, and tests with ErrorNotNil now pass as wanted
[13:09] <dimitern> voidspace, pong
[13:10] <dimitern> TheMue, indeed; almost ready with your review
[13:12] <voidspace> dimitern: quick check - the card I'm working on says to implement "AddSubnets" to the API (client side API call)
[13:12] <voidspace> dimitern: the apiserver call is bulk, AddSubnets
[13:12] <voidspace> dimitern: but the API call should be AddSubnet (singular), right?
[13:12] <voidspace> dimitern: I'm pretty sure I answered this anyway by looking at cmd/juju/subnets/subnets.go
[13:12] <voidspace> and it calls AddSubnet
[13:13] <voidspace> dimitern: *plus*, I should do Create *and* Add - even though the card only says AddSubnet and AllSubnets
[13:14] <voidspace> dimitern: cmd/juju/subnets/create.go exists alredy
[13:14] <voidspace> *already
[13:26] <dimitern> voidspace, AddSubnet should be the api and state method I think
[13:27] <dimitern> voidspace, and the api should have a CreateSubnet as well
[13:27] <dimitern> (also calling state.AddSubnet eventually at the apiserver side, after the subnet is created)
[13:28] <voidspace> dimitern: yep, that matches my expectation
[13:28] <voidspace> dimitern: thanks
[13:28] <voidspace> dimitern: this card is just the api side stuff, so easy enough
[13:28] <voidspace> no messing around with providers here
[13:29] <dimitern> voidspace, so we'll need a method on environs.Networking I guess - CreateSubnet (eventually, for now it can be a method on an interface like in apiserver/common)
[13:29] <voidspace> dimitern: yep
[13:29] <voidspace> dimitern: and a "FindSubnet" or similar to verify an existing one
[13:30] <perrito666> wwitzel3: hi?
[13:30] <katco> perrito666: he is not in atm
[13:31] <perrito666> oh that is unfair, he has an answering person (which I somehow suspect is a emacs plugin)
[13:31] <perrito666> voidspace: hb
[13:32] <katco> perrito666: (ERROR unknown defun 'oh that is unfair, he has an answering person (which I somehow suspect is a emacs plugin))
[13:33] <perrito666> lol
[13:34] <voidspace> perrito666: hb
[13:34] <voidspace> perrito666: :-)
[13:38] <mup> Bug #1483421 changed: Can not install juju-local on precise Ubuntu <precise> <juju-core:New> <https://launchpad.net/bugs/1483421>
[13:57] <katco> perrito666: wtf are you trying to hack my emacs
[13:57] <perrito666> lol
[13:58] <natefinch> katco: gonna be ~5 min late to meeting
[13:59] <dimitern> TheMue, if the release fails, do you try to remove the address?
[13:59] <katco> natefinch: ok thx for the heads-up
[13:59] <dimitern> TheMue, ah, sorry, that was after release was unbroken
[14:03] <voidspace> dimitern: CreateSubnet doesn't exist on the API server and there's no card for it
[14:03] <voidspace> dimitern: it was probably "implicit" in another card, but not done
[14:03] <voidspace> dimitern: I'll add a card
[14:03] <voidspace> dimitern: it takes slightly different parameters to AddSubnet
[14:04] <voidspace> dimitern: (takes an additional public bool parameter)
[14:07] <voidspace> dimitern: and the current apiserver AddSubnets does nothing with the provider - merely validates and adds to state
[14:07] <voidspace> I think that's wrong (or at least "a bug" that we can fix later)
[14:08] <voidspace> unless I'm mistaken
[14:08] <lazyPower> natefinch: wwitzel3 - is there anything special i need to pass to --upload-tools to build the juju-process-docker bin or have i run into the end of the sidewalk on the branch?
[14:09] <natefinch> lazyPower: sidewalk error
[14:09] <TheMue> dimitern: yep, addresses w/o releasing aren't removed, they will be retried later. that what I've tested by break and unbreak it
[14:09] <natefinch> lazyPower: currently it needs to be bundled in your charm
[14:10] <lazyPower> oh?
[14:16] <natefinch> lazyPower: check out https://github.com/natefinch/whalesay  and https://github.com/natefinch/whalesay/blob/master/hooks/install
[14:17] <lazyPower> natefinch: ok, i can work around that. Any guess as to how long until thats shipping w/ the tools? (i'm assuming feature branch landing in master?)
[14:28] <dimitern> TheMue, reviewed
[14:29] <dimitern> TheMue, I'm fine if you fix just those that look more serious and the rest in a follow-up PR, if you like
[14:30] <TheMue> dimitern: some are already done and pushed
[14:35] <natefinch> lazyPower: it'll land after 1.25... it's going to be integrated into the normal tools, so there won't be a separate binary deployed
[14:35] <lazyPower> ok, thats what i suspected. Thanks natefinch
[14:38] <TheMue> dimitern: using ipAddress instead of ipAddress.Value() returns the string representation of network.Address() instead of the vallue (which is e.g. "public:0.1.2.3")
[14:39] <TheMue> dimitern: for log output that imho is ok
[14:48] <dimitern> TheMue, I see, ok then if you can, use a local var if the same ipAddress.Value() is used in more logs
[14:49] <TheMue> dimitern: ok
[15:27] <voidspace> g'night all
[15:47] <mup> Bug #1484177 opened: Upgrade charm local juju failed <juju-core:New> <https://launchpad.net/bugs/1484177>
[17:46] <natefinch> ericsnow: you around?
[17:47] <ericsnow> natefinch: yep
[17:48] <natefinch> ericsnow: it occurs to me... you're caching all these updates in the context...  I was just going to cache the untrack as a delete.... but what if someone does untrack and then track with the same id? Should the later track removed the cache untrack?  I presume so....
[17:51] <ericsnow> natefinch: that should work given that tracking events are based strictly on the ID
[17:51] <natefinch> ericsnow: yeah, just makes this all a lot more complicated.  It's unfortunate we have to do our own caching layer before flushing out to the real data storage
[17:51] <ericsnow> natefinch: I guess the plugin type must factor in too
[17:53] <natefinch> ericsnow: hmm.... yeah.  Damn, that's annoying.
[17:53] <ericsnow> natefinch: it's definitely an unexpected corner case, but the first tracked proc may have the same ID as the replacement, but a different type
[17:55] <ericsnow> natefinch: that little facet certainly complicates the matter a little
[17:55] <natefinch> ericsnow: yeah.... I wonder if that's actually a problem with all our code... we currently only use the id for identifying the process
[17:57] <ericsnow> natefinch: it's only in the hook context that it's a problem an only in the untrack...track case (without a flush in between)
[17:57] <ericsnow> s/an/and
[17:58] <ericsnow> natefinch: basically it's an artifact of caching operations between flushes
[17:58] <natefinch> ericsnow: api get just takes ids.  If more than one process has the same id (but different type), you'd get back more than one process
[17:59] <ericsnow> natefinch: presently it isn't an issue because basically we flush after every operation (instead of waiting until the conclusion of the hook context)
[18:00] <ericsnow> natefinch: ID is the key (per unit) so there is only one
[18:01] <natefinch> ericsnow: gotta run, but I'll talk to you when I get back.
[18:02] <ericsnow> natefinch: only one hook can run at a time for a unit so we won't collide there...but at the point that we have workers touching state we'll have to introduce some sort of refresh in the hook context component
[18:02] <ericsnow> k
[20:59] <thumper> mramm: ping
[20:59] <mramm> pong
[20:59] <thumper> mramm: can we have a chat in about 30 minutes?
[20:59] <mramm> probably
[21:00] <thumper> master of committment there
[21:01] <mramm> thumper: we can meet in 30-40 min for sure
[21:01] <mramm> just not sure how long this danwest meeting is going to go
[21:02] <thumper> kk
[21:26] <menn0> thumper: regarding that mongod not starting issue... one of the reporters of the bug just attached the syslog output and the problem is the shared-secret file isn't being written out
[21:26] <menn0> https://launchpadlibrarian.net/214260999/syslog.txt
[21:26] <menn0> thumper: should be fixable now at least
[21:26]  * thumper nods
[21:26] <thumper> is it a race?
[21:27] <menn0> thumper: i've only just seen this so haven't checked but that seems likely
[21:27] <menn0> thumper: given that it doesn't happen for most people
[21:27]  * thumper nods
[21:38] <lazyPower> heyo o/ can i tap someone for info about https://bugs.launchpad.net/juju-core/+bug/1456265
[21:38] <mup> Bug #1456265: Openstack provider should work without object-store <openstack-provider> <juju-core:Fix Committed by axwalk> <https://launchpad.net/bugs/1456265>
[21:38] <lazyPower> such as if its currently in the juju-devel ppa for test driving?
[23:54] <mup> Bug #1484303 opened: keyManagerSuite teardown fails  <ci> <intermittent-failure> <test-failure> <juju-core:New> <https://launchpad.net/bugs/1484303>
[23:56] <davechen1y> mwhudson: https://groups.google.com/forum/#!topic/golang-dev/vNboccLL95c