[00:23] <davecheney> uh, wut
[00:23] <davecheney> % godeps -u dependencies.tsv
[00:23] <davecheney> godeps: update not yet implemented
[00:40] <thumper> wut?
[00:41] <thumper> davecheney: do you have an old godeps in your path?
[00:41] <thumper> you hit more godeps problems than anyone I know
[00:41] <thumper> perhaps it has "if user == 'dave'"...
[00:42] <rick_h_> I think it's the feature flag "hahadave"
[00:42] <rick_h_> last time I reviewed any code :P
[00:44] <davecheney> thumper: http://paste.ubuntu.com/8909806/
[00:44] <davecheney> i don't think that i'm wrong in my suspicion of this tool
[00:58] <davecheney> thumper: ready when you are
[00:58] <thumper> ok
[01:34] <thumper> davecheney: gah
[01:34] <thumper> davecheney: mis-clicked and closed the hangout
[01:34] <davecheney> thumper: don't push the one on the left, it makes you go slow!
[01:38] <davecheney> thumper: https://codereview.appspot.com/174760043/
[01:38] <davecheney> told ya!
[01:38] <davecheney> they are going to do the c2go transition in a branch
[01:38] <davecheney> then keep merging mainline into that branch, converting it
[02:31] <thumper> davecheney: is godeps working for you now?
[03:08] <wallyworld_> axw: a small one http://reviews.vapour.ws/r/391/
[03:11] <wallyworld_> thumper: look what anastasiamac found http://www.juju.com.au/
[03:11]  * thumper looks
[03:11] <wallyworld_> so much for Juju in Australia :-(
[03:11] <thumper> THE RIGHT JUJU FOR YOU
[03:12] <thumper> hmm
[03:17] <axw> wallyworld_: looking
[03:17] <wallyworld_> ty
[03:20] <anastasiamac> wallyworld_: were u not impressed by 'bad juju'?
[03:20] <wallyworld_> well, i was not the target audience
[03:20] <anastasiamac> wallyworld_: oh? but u were for .com.au?
[03:21] <wallyworld_> oh, i got mixed up
[03:22] <wallyworld_> i do like big guns, and i cannot lie
[03:22] <anastasiamac> wallyworld_: it's k. noone is perfect
[03:27]  * bigjools stares in disbelief at that web site
[03:29] <wallyworld_> bigjools: there's obviously a market for it
[03:30] <anastasiamac> bigjools: it's very hard to name a product...
[03:30] <wallyworld_> axw: thanks for review. dns name will never be non empty, as it's set to public address. for this work, i'd rather leave status alone. the change brings ec2 into line with other providers from what i can see
[03:30] <anastasiamac> bigjools: or invent one..
[03:31] <wallyworld_> i liked Ensemble
[03:31] <axw> wallyworld_: huh? I didn't say dns-name would be empty, I was talking about Public/PrivateDNSName on the instance
[03:31] <menn0> wallyworld_, davecheney: i've made some further tweaks to that upgrade steps branch. http://reviews.vapour.ws/r/355/diff/
[03:32] <menn0> wallyworld_, davecheney: i've completely split up state and API based steps. it makes things clearer and cleans up the package some more.
[03:32] <wallyworld_> axw: oh, i misread your text
[03:32] <wallyworld_> thanks menn0  will look in a sec
[03:33] <menn0> wallyworld_: cheers
[03:34] <wallyworld_> axw: i did think about keeping it and changing the order, but since i understand we want to get rid of dns name, and the stated preference is to just show ip addresses, and fetching the dns name is potentially another remote call, i thought it best just to remove it
[03:35] <axw> wallyworld_: why are we getting rid of dns-name? to make way for "addresses"?
[03:35] <wallyworld_> i can't recall exactly - i've heard william grumble loudly about it
[03:35] <axw> I think the reason is so we can show *all* the addresses, not just one (DNS name)
[03:35] <axw> anyway, like I said, it shouldn't matter in *this* instance
[03:36] <axw> but if the IP can be come stale and the DNS name is the canonical identifier, then I don't think it should be removed
[03:37] <axw> (otherwise the CLI has no way to connect, without being able to list state servers which requires full creds, etc.)
[03:37] <bigjools> wallyworld_: anastasiamac: gives new meaning to two girls one cup
[03:37] <wallyworld_> does the cli seven specifically look for the dns name? i'd have to check
[03:38] <wallyworld_> bigjools: groan :-(
[03:38] <axw> wallyworld_: it tries all the addresses
[03:38] <wallyworld_> yes, of which the dns name would be one, true
[03:39] <wallyworld_> well, i guess i can retain it, but put it after the ip address in the slice
[03:39] <axw> wallyworld_: if you do, I suggest leaving out the conditional and only add it if they're non-empty
[03:39] <axw> no call to refresh()
[03:40] <wallyworld_> could do, but that would make the behaviour inconsistent
[03:40] <axw> wallyworld_: how? even the current way of refreshing isn't guaranteed to get the address AFAIK
[03:41] <axw> all the addresses will eventually be populated into state
[03:41] <axw> hmm actually it must be... it doesn't check after
[03:41] <wallyworld_> the code comments seemed to imply that the dns name should become available after a time
[03:43] <wallyworld_> if i just change the order, that seems to be the smallest change. i just couldn't see a compelling enough reason to retain the dns name in the address list at all
[03:43] <axw> wallyworld_: just drop it
[03:43] <axw> but bear in mind for other providers it might matter
[03:43] <wallyworld_> this code is ec2 specific
[03:43] <axw> right...
[03:44] <axw> for other providers, it might matter to have the DNS name as well as IP
[03:44] <wallyworld_> sure. but i don't think we do that, except for maas where we record the hostname
[03:44] <wallyworld_> openstack i *think* is just ip addresses, need to double check
[03:48] <axw> wallyworld_: I'm talking hypotheticals, I don't recall what each of the providers does.
[03:49] <wallyworld_> ok. i'll land as is and if dns name comes up as a requirement, we can address holistically across all providers
[03:56] <wallyworld_> menn0: looks cleaner with tweaks
[03:57] <menn0> wallyworld_: I'm glad you think so. land it?
[03:57] <wallyworld_> yup
[03:58] <menn0> ok cool. just dealing with conflicts with waigani's recent merge and then I'll retest and merge.
[03:59] <menn0> wallyworld_: thanks for the review(s)
[04:01] <wallyworld_> np
[04:37] <anastasiamac> axw: m having trouble sync n upstream
[04:38] <anastasiamac> axw: my go vet complains about audit/audit.go:30: constant 3 not a string in call to Logf
[04:38] <anastasiamac> axw: suggestions? insights? r sooo welcome
[04:38] <anastasiamac> axw: :-)
[04:39] <anastasiamac> axw: btw, audit.go is not a file I've ever opened let alone changed..
[04:43] <axw> looking
[04:44] <davecheney> anastasiamac: sorry juju doesn't build with go 1.4 atm
[04:44] <davecheney> please use 1.3 or 1.2
[04:45] <anastasiamac> davecheney: thnx for help. m using go version go1.2.1 linux/amd64
[04:46] <davecheney> really ?
[04:46] <davecheney> jcw reported the problem earlier
[04:46] <davecheney> but he was using 1.4
[04:47] <anastasiamac> davecheney: yep just did "go version"
[04:47] <davecheney> ffs, i'm never going to be able to merge my branch
[04:47] <davecheney> http://paste.ubuntu.com/8912736/
[04:48] <davecheney> trunk never passes on my machine
[04:49] <axw> anastasiamac: I have no idea. I didn't think the vet call blocked anything yet anyway...
[04:51] <anastasiamac> axw: I've setup pre-push hook this morning and now cannot sync upstream...
[04:51] <anastasiamac> axw: what I am getting is
[04:51] <anastasiamac> axw: checking: go vet ...
[04:51] <anastasiamac> audit/audit.go:30: constant 3 not a string in call to Logf
[04:51] <anastasiamac> error: failed to push some refs to 'https://github.com/anastasiamac/juju.git'
[04:52] <axw> anastasiamac: certainly looks like vet complaining because the first arg is not a format string... but I have no idea why it's failing on yours, and doesn't on mine.
[04:53] <davecheney> anastasiamac: it's a bug in go vet
[04:53] <davecheney> i'd disable the pre-push hook
[04:53] <anastasiamac> axw: is there anyhting else that could b different btw ur copy and mine? m on go 1.2; no commits - working directory is clean... AL I am trying to do is sync up ;-o
[04:53] <davecheney> it's being dumb and assuming anything that looks like a format f style function, _is_ a format style function
[04:54] <anastasiamac> davecheney: that's my next step. but it works for wallyworld_and axw
[04:54] <davecheney> anastasiamac: i'm almost certain you've got a go vet from effectively trunk
[04:54] <davecheney> but axw and others have a version from debian
[04:54] <anastasiamac> davecheney: well, shouldn't i get it too? how do I do it?
[04:54] <axw> my go is from built from source, probably just haven't updated vet in a while
[04:55] <axw> and now I'm hesitant to do so :)
[04:55] <anastasiamac> axw: i do feel a bit under magnifying glass...
[04:55] <axw> anastasiamac: you can pass "--no-verify" to skip go vet/fmt checks
[04:57] <anastasiamac> axw: ;-) mite as well disable the hook..
[04:57] <davecheney> http://paste.ubuntu.com/8912839/
[04:57] <davecheney> ^ bug in vet
[04:58] <davecheney> anastasiamac: just disabled the hook
[04:58] <davecheney> it obviously doesn't run on the bot
[04:58] <davecheney> so why bother
[04:58]  * davecheney logs bug
[04:59] <axw> davecheney: does not fail for me, clearly depends on the version of vetr
[04:59] <axw> vet*
[04:59] <axw> dunno what's on the bot.. pretty sure that mgz reinstated it tho
[04:59] <anastasiamac> davecheney: axw: I saw it runing on the bot... but m not sure that it gates..
[05:00] <axw> davecheney: I think we should pass "Logf:1" into -printfuncs
[05:00] <anastasiamac> davecheney: thnx for tracing & logging it. could u plz send me bug #
[05:01] <davecheney> https://code.google.com/p/go/issues/detail?id=9080
[05:05] <anastasiamac> davecheney: axw: thnx 4 ur dedicated help :-0 m disabling the hook ;-p
[05:06] <axw> okey dokey
[05:19] <davecheney> anastasiamac: it's no problem
[06:15] <davecheney> http://reviews.vapour.ws/r/393/
[06:15] <davecheney> ^ anyone
[06:15] <davecheney> it's wafer thing
[06:15] <davecheney> it's wafer thin
[06:15] <wallyworld_> looking
[06:16] <wallyworld_> jeez davecheney you do all the hard ones
[06:16] <davecheney> wallyworld_: i only do the ones that don't pass on my machine
[06:16] <wallyworld_> i wonder how many more of those there are in our code
[06:16] <wallyworld_> :-(
[06:32] <davecheney> wallyworld_:
[06:32] <davecheney> ok  	github.com/juju/juju/cmd/envcmd	0.192s
[06:32] <davecheney> # testmain
[06:32] <davecheney> write error: No space left on device
[06:32] <davecheney> # testmain
[06:32] <davecheney> write error: No space left on device
[06:32] <davecheney> # testmain
[06:32] <davecheney> write error: No space left on device
[06:32] <davecheney> # testmain
[06:32] <davecheney> write error: No space left on device
[06:32] <davecheney> # testmain
[06:33] <davecheney> write error: No space left on device
[06:33] <davecheney> well fuck
[06:33] <davecheney> http://juju-ci.vapour.ws:8080/job/github-merge-juju/1248/console
[06:33] <wallyworld_> happens occasionally, just resubmit
[06:33] <davecheney> it's run out of space on /tmp
[06:33] <wallyworld_> i'm not sure of the current status of tht issue
[06:34] <davecheney> ec2 root disk is small, and that 'aint chaingin
[06:40] <wallyworld_> unless we ask for an instance with more storage
[06:40] <davecheney> wallyworld_: i thgouth that just changed the size of /data
[06:41] <davecheney> was always fixed by the size of the AMI
[06:41] <wallyworld_> i thought we could ask for an instance with larger root disk using different instance type, not sure thpugh tbh
[06:42] <davecheney> i thought that that space always ends up on /dta
[06:42] <davecheney> i thought that that space always ends up on /data
[06:49] <davecheney> wallyworld_: can you kill that build
[06:49] <davecheney> it hasn't given up yet
[06:49] <davecheney> ta
[06:49] <wallyworld_> sure
[06:50] <davecheney> file:///mnt/tmp/check-8674665223082153551/5/tools/streams/v1/index2.sjson"
[06:50] <davecheney> oh wow
[06:50] <davecheney> we already set $TMP to be somethine else
[06:50] <davecheney> and it still fills up
[06:50] <davecheney> fantastic
[06:50] <davecheney> thanks Cloud, you're ace
[06:51] <wallyworld_> job nuked
[06:59] <davecheney> wallyworld_: now it's not picking up the build
[06:59] <davecheney> sorry
[06:59] <davecheney> i've $$merge$$ d a bunch of times
[07:00] <wallyworld_> davecheney: the PR needs to have "Build Failed:" test
[07:00] <wallyworld_> text
[07:00] <wallyworld_> normally, aborting a build or failing a build adds this
[07:31] <dimitern> morning jam21, 1:1?
[07:31] <jam21> dimitern: yep
[08:30] <davecheney> yay, each test run leaks 35mb
[08:31] <davecheney> in /tmp
[08:39] <TheMue> morning
[08:42] <davecheney> the state tests require 16 different mongo instances
[08:50] <eagles0513875_> hi dev's I am just wondering is juju still rather distro specific
[09:19] <mattyw> morning everyone
[09:50]  * fwereade is totally not working today, except coincidentally maybe hacking for fun a bit
[09:51]  * fwereade has an LGTM on the first bit but would love a review of http://reviews.vapour.ws/r/385/diff/1-2/
[09:52] <fwereade> hmm, actually, that diff is confusing because it has stuff from the reboot bits mixed in
[09:52] <fwereade> gsamfira, you around?
[10:00] <dimitern> TheMue, standup?
[10:12]  * fwereade just updated http://reviews.vapour.ws/r/385/ with less stupid var names
[10:29] <dimitern> jam21, I've just checked; we *do* run config-changed when the address(es) of a unit change
[10:44] <jam> voidspace: poke for 1:1 ?
[10:53] <voidspace> jam: sorry!
[10:53] <jam> voidspace: we can still talk quickly before my son gets home
[10:53] <voidspace> jam: omw
[10:53] <voidspace> jam: completely forgot about 1:1
[11:31] <wallyworld_> jam: voidspace: you guys are still working on those 1.21 beta2 bugs, right?
[11:34] <jam> wallyworld_: yes
[11:34] <voidspace> wallyworld_: yes, although reproducing 1381619 has so far been difficult
[11:34] <voidspace> wallyworld_: although I seem to have found another bug on the way
[11:34] <wallyworld_> ok, thank you, was curious as hopefully we can get beta2 ready before too long
[11:34] <voidspace> wallyworld_: as we know where the bug is we think we can fix it without having to reproduce though
[11:35] <wallyworld_> might find it easier with an older maas
[11:35] <wallyworld_> i think 1.7+ handles node states differently
[11:39] <voidspace> wallyworld_: right, I might have to do that.
[11:40] <wallyworld_> or, if you are sure of the fix as you say...
[11:40] <voidspace> wallyworld_: really I at least need to see how the error is returned to us - with Maas 1.7 releasing a node twice does not error
[11:40] <voidspace> wallyworld_: well, we know why there's an error
[11:40] <wallyworld_> yeah, would be good to see the error occur
[12:23] <voidspace> dimitern: ping
[12:23] <voidspace> dimitern: where do I tell MaaS to wipe the disk on release?
[12:23] <voidspace> dimitern: I'm sure I've seen this somewhere before, but can't find it now...
[12:23] <voidspace> I've tried editing nodes, cluster, network interface and zone
[12:24] <voidspace> hmmm, I haven't tried preferences yet
[12:24] <voidspace> I bet it's there
[12:24] <voidspace> yep
[12:24] <voidspace> dimitern: unping...
[12:26] <voidspace> dimitern: wallyworld_: jam: if I call "release node" (gomaasapi) on a node that is in "Disk erasing" state then I get a reproducible error
[12:27] <jam> voidspace: not perfect, but sounds better
[12:27] <voidspace> jam: and calling juju destroy-environment on that then gets the error as reported
[12:27] <voidspace> jam: so I think it's fine
[12:27] <voidspace> 409 CONFLICT (Node(s) cannot be released in their current state: node-51abffb8-6699-11e4-923e-525400512a8c ('Disk erasing').)
[12:28] <dimitern> voidspace, sorry, was away for a bit; it's on the maas settings page
[12:28] <voidspace> dimitern: I found it, thanks :-)
[12:28] <voidspace> jam: and that's in StopInstances so it's very isolated code - easy to fix
[12:29] <jam> voidspace: nice
[12:29] <jam> voidspace: I do wish it was a bit more structured for machine consumption (JSON return message, etc), but I think the above is parseable
[12:29] <voidspace> jam: I'm just introspecting the specific error to see if I can avoid string parsing
[12:30] <voidspace> jam: I have a StatusCode: 409
[12:30] <voidspace> (CONFLICT)
[12:30] <voidspace> gomaasapi.ServerError
[12:31] <voidspace> jam: ignore that specific error?
[12:40] <voidspace> of course maas documentation on possible error codes is non-existent
[12:40] <voidspace> time to go to the source
[12:44] <dimitern> anyone willing to review a small patch that fixes bug 1359714 ? http://reviews.vapour.ws/r/395/diff/
[12:44] <mup> Bug #1359714: Add JUJU_MACHINE_ID to the hooks environment <charms> <landscape> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1359714>
[12:49] <dimitern> fwereade, hey, if you can have a look ^^ to confirm my uniter changes are ok it would be great
[12:52] <fwereade> dimitern, any partucular reaosn we're exposing tags to the Context ratherthan the id?
[12:53] <fwereade> dimitern, given that the Context is largely user-facing, id seems more appropriate
[12:53] <fwereade> dimitern, OTOH tags are typed
[12:53] <dimitern> fwereade, well, the request was about JUJU_MACHINE_ID, and exposing a tag there will be a precedent, as we already have JUJU_UNIT_NAME
[12:53] <fwereade> dimitern, yeah, I'm definitely not saying we should show the user a tag
[12:54] <fwereade> dimitern, I'm just quibbling over what type we store in the context
[12:54] <dimitern> fwereade, ah, sorry, I was too quick to respond without reading :)
[12:54] <fwereade> dimitern, ship it :)
[12:54] <dimitern> fwereade, well, that's a good point, should I file a bug to change assignedMachineTag to Id ?
[12:54] <dimitern> fwereade, thanks!
[12:54] <fwereade> dimitern, but let me know when it's landed so I can fix 385 and demand a reciprocal review from you ;p
[12:54] <fwereade> dimitern, don't think so
[12:55] <fwereade> dimitern, the typedness is a good thing
[12:55] <fwereade> dimitern, actually
[12:55] <fwereade> dimitern, wait a mo
[12:55] <dimitern> fwereade, having a typed tag is better, as we can both return a tag or and id, where needed
[12:56] <fwereade> dimitern, move the AssignedMachineTag method into export_test.goplease
[12:56] <fwereade> dimitern, nobody else uses it
[12:56] <fwereade> dimitern, but if we expose it they will start to ;p
[12:56] <fwereade> dimitern, sane?
[12:56] <dimitern> fwereade, sure, sgtm
[12:56] <fwereade> dimitern, cheers
[13:45] <wwitzel3> so after reinstalling last week and a weekend of tweaking, I finally have everything back to normal, sans the resolution on my laptop display. Close enough.
[14:51] <voidspace> Two and a half hours later, MaaS is still "disk erasing"
[14:54] <rick_h_> voidspace: yea that was hanging for me. I ended up unchecking that box
[14:56] <voidspace> rick_h_: it's "the way" I can repro this bug :-)
[14:56] <rick_h_> voidspace: oic, more fun to you :)
[14:56] <voidspace> rick_h_: it's only kvm images - time to blow it away and reprovision
[14:56] <voidspace> rick_h_: indeed :-)
[14:56] <voidspace> rick_h_: hey, it's progress - at least I *can* repro the bug now...
[14:56] <voidspace> I think I just fixed it too, need to try it
[14:57] <rick_h_> cool, if you need a real maas let me know. Can get you access to http://maas.jujugui.org/MAAS for some occassional testing.
[14:57] <voidspace> rick_h_: thanks, helpful
[14:57] <voidspace> rick_h_: I think my local one with kvm is fine for now
[14:57] <rick_h_> cool
[14:58] <voidspace> ah, and I might have worked out why it's hung
[14:58] <voidspace> pxe boot isn't working on my network - and it needs the node restarting to wipe
[14:59] <rick_h_> ah, yea
[15:02] <voidspace> rick_h_: I mean, it may still hang anyway... but at least it has a chance now :-)
[15:04] <natefinch> wwitzel3: standup?  I just fixed the calendar, since I managed to delete the monday standup somehow
[15:05] <voidspace> rick_h_: erasing completed...
[15:06] <voidspace> rick_h_: but it's handy - because I can now *force* erasing to hang - so I can reliably reproduce the error rather than rely on timing
[15:15] <voidspace> dimitern: ignoring error 409 in maasEnviron.StopInstances fixes the bug I'm working on
[15:15] <voidspace> dimitern: there's no documentation on what status codes mean though
[15:16] <voidspace> dimitern: I'm just worried about unintended consequences...
[15:16] <voidspace> dimitern: I'm digging into the maas source (and have filed an issue about documenting errors)
[15:17] <dimitern> voidspace, right; please have a quick chat with the maas team about this (we need confirmation that it's safe to ignore 409 errors from stopinstance)
[15:24] <wwitzel3> rogpeppe: ping
[15:24] <rogpeppe> wwitzel3: pong
[15:25] <wwitzel3> rogpeppe: trying to figure out why the custom relationIdValue being used with gnuflag f.Var isn't consolidating the flags.
[15:25] <rogpeppe> wwitzel3: is it in trunk?
[15:25] <wwitzel3> rogpeppe: yes
[15:26]  * rogpeppe goes to look
[15:26] <wwitzel3> jujuc/realtion-set.go
[15:28] <voidspace> dimitern: I've looked through the code
[15:28] <voidspace> dimitern: I'm pretty sure it is
[15:28] <voidspace> dimitern: https://bugs.launchpad.net/maas/+bug/1381619/comments/15
[15:28] <mup> Bug #1381619: Failed to destroy-environment when node is in commissioning or new state <cloud-installer> <oil> <juju-core:Triaged by mfoord> <MAAS:Incomplete> <https://launchpad.net/bugs/1381619>
[15:29] <rogpeppe> wwitzel3: a search for relationIdValue in core trunk doesn't come up with anything
[15:29] <dimitern> voidspace, ok, that's good, but please add a comment on the bug about this assumption
[15:30] <wwitzel3> rogpeppe: worker/uniter/context/jujuc/context.go
[15:30] <wwitzel3> rogpeppe: 135
[15:31] <rogpeppe> wwitzel3: ha, i wasn't in the juju root dir
[15:31] <voidspace> dimitern: yep
[15:31] <dimitern> voidspace, cheers!
[15:31] <voidspace> dimitern: the bug I filed about documenting api errors has been triaged as high priority - which is promising
[15:33] <dimitern> voidspace, yeah, let's see if it will actually matter :)
[15:36] <wwitzel3> rogpeppe: so what I want is --r and --relation mapped to the same thing, I was looking at the stringValue and StringVar implementations as a guide for what I might need to update in relationIdValue, but can't quite put a pin in it.
[15:37] <rogpeppe> wwitzel3: sorry, busy in another channel - will get back to you
[15:37] <wwitzel3> rogpeppe: with StringVar for example, if I give them the same &var the output on the command line is --f, foo
[15:37] <wwitzel3> rogpeppe: yep, no worries
[15:50] <voidspace> dimitern: any idea, off hand, about how to make the maas TestServer return an error?
[15:50] <voidspace> dimitern: I'm picking my way through it, might work it out myself...
[15:51] <voidspace> dimitern: in provider/maas/environ_whitebox_test.go
[15:53] <voidspace> dimitern: right, TestServer.nodeHandler gets that operation - looks like it needs extending to return an error
[15:53] <dimitern> voidspace, I'm not sure you can actually
[15:53] <voidspace> dimitern: the TestServer is ours
[15:53] <voidspace> we can do *anything* with it
[15:53] <voidspace> dimitern: line 530 handles release
[15:53] <voidspace> dimitern: it just calls delete
[15:54] <dimitern> voidspace, yeah :) but I meant right now gomaasapi's testservice does not allow you to set response codes per url
[15:54] <voidspace> dimitern: you mean that the underlying http server might not be capable of that error
[15:54] <voidspace> dimitern: it looks to me like deleting a node twice will fail
[15:54] <voidspace> dimitern: I can make it fail with a 409 (perhaps)
[15:54] <dimitern> voidspace, that's a bit of a hack, but if it works - hey :)
[15:54] <voidspace> sure... :-)
[16:14] <rogpeppe> wwitzel3: you need to pass exactly the same pointer value; if that's not working, it might be a bug
[16:15] <wwitzel3> rogpeppe: ok, it is the same pointer, I will dig around a bit more
[16:16] <rogpeppe> wwitzel3: have a look in PrintDefaults - that's where the magic happens
[16:17] <wwitzel3> rogpeppe: ty
[16:17] <rogpeppe> wwitzel3: that first VisitAll should gather the different flags under the same value
[16:18] <rogpeppe> s/same value/same map entry/
[16:19] <wwitzel3> rogpeppe: ahh, I see
[16:20] <wwitzel3> rogpeppe: the newRelationIdValue method needs to be returning the same pointer, no assigning to the same one in the Cmd struct
[16:20] <wwitzel3> rogpeppe: well, it needs to be doing both :) thank you, I think I can fix it now
[16:34] <wwitzel3> rogpeppe: thank you, all fixed up :)
[16:59] <voidspace> dimitern: ah, TestServer is in gomaasapi
[17:00] <voidspace> dimitern: who owns that?
[17:00] <dimitern> voidspace, we do - juju hackers
[17:00] <voidspace> dimitern: who knows it best?
[17:01] <dimitern> voidspace, the maas guys created it, and a few core guys (myself included) extended it
[17:01] <voidspace> dimitern: right, cool
[17:02] <dimitern> voidspace, btw - care to review a small patch http://reviews.vapour.ws/r/396/ for bug 1382709
[17:02] <mup> Bug #1382709: Openstack provider, Instance-state doesn't change on instance shutdown <cts-cloud-review> <status> <ubuntu-openstack> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1382709>
[17:02] <voidspace> dimitern: the tricky thing is, I'm teaching maasEnviron to ignore error 409 - so with my patch in place, even if the test server returns error 409 there is no change in behaviour!
[17:02] <voidspace> dimitern: i.e. the test passes both with the old TestServer and with my change
[17:03] <voidspace> dimitern: although a changed TestServer would cause my new test to fail *without* my new fix
[17:03] <voidspace> so it's still good, just tricky to prove...
[17:03] <voidspace> dimitern: looking
[17:03] <dimitern> voidspace, hmm.. it seems to me some mocking should be done to test the HTTP 409 separately then?
[17:03] <voidspace> dimitern: that would be better I think
[17:04] <voidspace> dimitern: hopefully we already have some tests that do that or I have to add some mocking code
[17:04] <voidspace> dimitern: hah, a similar bug to the one I'm working on
[17:04] <dimitern> voidspace, I don't believe we do, unfortunately
[17:04] <dimitern> voidspace, yeah :)
[17:05] <dimitern> voidspace, the solution might be surprising, that's why I tried to explain what's happening in the PR desc
[17:05] <voidspace> cool
[17:06] <voidspace> although the "after 15m" is slightly worrying
[17:06] <voidspace> dimitern: the code changes look very simple
[17:07] <dimitern> voidspace, it should be 15m after the last check I guess
[17:07] <voidspace> dimitern: check explicitly for a "not-nil but empty" IP address and also handle explicitly the Shutoff and Suspended statuses
[17:08] <dimitern> voidspace, the first thing is not mentioned, because it's a slight log spam, which was annoying
[17:08] <voidspace> right
[17:09] <dimitern> voidspace, Addresses() is called quite often, and even during bootstrap; so I don't want to see "X has floating IP Y" all the time :)
[17:09] <voidspace> heh
[17:12] <voidspace> dimitern: it's a long test for a code change that only amounts to half a line
[17:12] <dimitern> updated the desc a bit
[17:13] <dimitern> voidspace, yeah, because patching goose test server (even though better than gomaasapi or ec2) is still a bit obtuse
[17:13] <voidspace> dimitern: LGTM
[17:15] <dimitern> voidspace, thanks!
[17:16] <dimitern> time to go :) g'night all!
[17:18] <voidspace> dimitern: g'night
[17:45] <rogpeppe> wwitzel3: cool
[18:10] <jw4> anyone with MAAS and HA cluster charm knowledge available to help in #juju?
[18:14] <jw4> ^ n/m jose jumped on it
[18:24] <voidspace> wallyworld_: you're not still around are you?
[18:25] <voidspace> tasdomas: ping
[18:25] <voidspace> tasdomas: you're OCR I believe
[18:25] <voidspace> http://reviews.vapour.ws/r/397/
[19:00] <voidspace> g'night all
[19:56] <fwereade> thumper, hey, can I hassle you for a quick review of http://reviews.vapour.ws/r/385/diff/# please? want to land it so I can focus on the thing that's currently melting my brain...
[19:57] <fwereade> thumper, it's mostly been reviewed already, but the last couple of diffs haven't
[19:57] <thumper> kk
[20:07] <mattyw> fwereade, you're supposed to be on holiday
[20:07] <fwereade> mattyw, I've been coding and feeling not one bit guilty about leaving my email unread ;)
[20:07] <mattyw> fwereade, awesome!
[20:08] <thumper> :-)
[20:18] <TheMue> thumper: afaik you're managing the change of the commands into grouped super commands and sub-commands. am I right?
[20:18] <waigani> menn0: sorry, did I cut you off?
[20:19] <thumper> TheMue: I guess
[20:20] <TheMue> thumper: for actions we're currently implementing the commands this, like juju actions do ...
[20:20] <TheMue> thumper: anything special we should take care for?
[20:21] <thumper> TheMue: take a look at the user super command
[20:21] <thumper> TheMue: what I've done is put the related commands into a package
[20:22] <thumper> did normal style testing
[20:22] <thumper> I think it should be 'juju action' not 'juju actions'
[20:22] <menn0> waigani: i was just going to recommend that book to thumper (see onyx channel)
[20:22] <thumper> just like 'juju backup' not 'backups'
[20:22] <TheMue> thumper: ah, great, that's how bodie is already doing it
[20:23] <natefinch> onyx channel?  You guys have your own channel?  Too good to talk with the rest of us, huh?
[20:23] <TheMue> thumper: we today discussed about action vs actions too. so far everywhere the term actions is used
[20:23] <thumper> natefinch: yep
[20:24] <thumper> natefinch: it is for sekrit black ops stuff
[20:24] <natefinch> thumper: heh :)
[20:24] <TheMue> thumper: but the similarity to other commands is a good argument
[20:25] <thumper> TheMue: it is 'juju user' not 'juju users'
[20:26] <thumper> and will be 'juju service', 'juju machine', not services and machines
[20:26] <TheMue> thumper: convinced :D
[20:33] <mattyw> I'm calling it a night, bye all
[20:39] <bodie_> thumper, I was thinking "actions" since it's "actions-related" rather than always working with a specific action
[20:39] <bodie_> hm
[20:39] <bodie_> I see
[20:39] <thumper> bodie_: try typing out some of the commands
[20:39] <bodie_> juju actions defined mysql
[20:39] <bodie_> juju actions queue
[20:40] <bodie_> juju actions status action:12345 (wip on that syntax)
[20:40] <bodie_> juju actions do mysql/0 snapshot
[20:40] <bodie_> juju actions help
[20:41] <natefinch> can we make 'juju actions do'  just "juju do" ?   Just like we don't type 'juju service deploy' ?
[20:41] <bodie_> we were thinking of aliasing a few top-level commands to actions subcommands
[20:41]  * natefinch loves painting sheds for many sized vehicles
[20:41] <bodie_> not certain how to go about that
[20:42] <bodie_> is there a precedent for it?
[20:42] <thumper> bodie_: there will be a precedent, but it isn't done yet
[20:42] <natefinch> pretty much the whole CLI is a precedent for it ;)
[20:42]  * thumper thinks it should still be 'action' not 'actions'
[20:43] <natefinch> I agree
[20:43] <natefinch> let's pick singular or plural and go with it.  singular usually makes more sense (and is usually shorter)
[20:43] <bodie_> mice vs mouse tho
[20:43] <bodie_> ;)
[20:44] <bodie_> I'll defer to whatever :)
[20:44]  * fwereade driveby singular!
[20:44] <natefinch> bodie_: I said usually because I know engineers are annoyingly pedantic :)
[20:44] <bodie_> hehehe
[21:09] <thumper> fwereade: review done
[21:09] <thumper> mramm: call time?
[21:14] <wallyworld_> menn0: folks are saying bug 1386143 is not completely fixed, are you able to take a look and see what might need doing?
[21:14] <mup> Bug #1386143: 1.21 alpha 2 broke watch api, no longer reports all services <api> <regression> <juju-core:Triaged> <juju-gui:Invalid> <juju-quickstart:Invalid> <https://launchpad.net/bugs/1386143>
[21:14] <rick_h_> thumper: he's traveling and missed our call so might not make it today
[21:15] <thumper> rick_h_: thanks
[21:17] <menn0> wallyworld_: I don't see how the extra detail that's been added on has anything to do with the watcher
[21:17] <fwereade> thumper, tyvm
[21:17] <thumper> fwereade: np
[21:17] <wallyworld_> menn0: ok, np, we'll have to look into it
[21:18] <menn0> wallyworld_: unless i'm misunderstanding
[21:18] <menn0> wallyworld_: i'm happy to have a look if the problem isn't fixed though
[21:18] <wallyworld_> i haven't looked into the detail, just saw the bug
[21:18] <wallyworld_> if you had a moment to look, that would be great
[21:19] <wallyworld_> otherwise i can look to pick it up later
[21:20] <menn0> wallyworld_: it looks like someone requested a machine from MAAS with constraints that didn't match any available node
[21:20] <menn0> wallyworld_: agent-state-info: 'cannot run instances: gomaasapi: got error back from server:
[21:20] <menn0>       409 CONFLICT (No available node matches constraints: tags=general zone=default)'
[21:22] <wallyworld_> yes, i can't see how the output added to the bug relates to the original problem
[21:23] <wallyworld_> unless it's meant to show a bunch more machines
[22:19] <menn0> wallyworld_: even if the status output is supposed to show more machines, it doesn't relate to the watcher
[22:20] <wallyworld_> menn0: in a meeting, will think in a minute
[22:21] <menn0> wallyworld_: np. just writing things as I think of them :)
[22:58]  * fwereade observes that jenkins seems to be falling over due to lack of disk space, would someone be so good as to fix it (and maybe re$$merge$$ https://github.com/juju/juju/pull/1084 ?)
[23:01] <wallyworld_> fwereade: will do
[23:01] <wallyworld_> fwereade: can i make our 1:1 a few hours later this week?
[23:01] <fwereade> wallyworld_, surely :)
[23:02] <wallyworld_> fwereade: ty. also, that disk space thing is intermittent (/tmp fills) but has been geeting more and more prevalent :-(
[23:02] <wallyworld_> i think dave found our tests leak 35MB each
[23:04] <katco> holy moly
[23:05]  * fwereade boggles quietly, resolves to worry about his own specific local test failures and then go to bed for now
[23:05] <katco> that is not ideal
[23:08] <wwitzel3> 35mb each .. lol
[23:08] <wwitzel3> cry
[23:08] <katco> disk is cheap! lol
[23:14] <davecheney> wallyworld_: i know why
[23:14] <davecheney> the state tests run three mongo instances
[23:14] <davecheney> there are 16 suites
[23:14] <davecheney> that all use the testing/mgo.go magic to _reuse_ the mongo instance
[23:14] <davecheney> this is good
[23:15] <davecheney> but there is a flaw in the implementation
[23:15] <davecheney> the last mongo doesnt' get shutdown
[23:15] <davecheney> it dies when the parent process dies
[23:15] <davecheney> but that leaks 35mb of /tmp
[23:15] <davecheney> i don't know how to fix the flaw without changes to gocheck
[23:16] <wwitzel3> so I've set my lxc.lxcpath to a btrfs mount point, but now when I bootstrap the configs are put in to that path, but juju seems to still be looking in /var/lib/lxc
[23:17] <wwitzel3> agent-state-info: '(error: open /var/lib/lxc/wwitzel3-local-machine-3/config
[23:26] <wallyworld_> davecheney: hmm, well that kinda sucks. is there a bug?
[23:27] <wallyworld_> wwitzel3: i think /var/lib/lxc is hard coded in juju, will need to check
[23:27] <wwitzel3> wallyworld_: I didn't find it anywhere :) one of the fisrt things I checked
[23:28] <wallyworld_> const DefaultLXCDir = "/var/lib/lxc"
[23:28] <wallyworld_> wwitzel3: in golxc.go
[23:29] <wwitzel3> wallyworld_: we use GetDefaultLXCContainerDir .. which uses the lxc.lxcpath
[23:30] <wallyworld_> ah, just noticed that
[23:30] <wwitzel3> wallyworld_: and I checked on my system, it returns the proper lxc.lxcpath
[23:30] <wallyworld_> seems lie a legitimate bug that needs fixing
[23:31] <wallyworld_> like