[00:40] <davecheney> o_O
[00:40] <davecheney> func (cfg *MachineConfig) addMachineAgentToBoot(c *cloudinit.Config, tag, machineId string) error {
[00:40] <davecheney> is the tag _not_ the machine id !?!?
[00:48] <thumper> davecheney: this is in my area
[00:48] <thumper> I'm tweaking things around there
[00:49] <thumper> let me look
[00:49]  * thumper has a headache
[00:49]  * thumper need more coffee
[00:49] <thumper> does anyone remember the git equivalent of uncommit?
[00:49] <cmars> thumper, git reset
[00:49] <thumper> cmars: will that leave me the changes still?
[00:50] <cmars> thumper, depends on how you use it
[00:50] <thumper> I want the changes
[00:50] <cmars> thumper, i need to look up the flags for that case
[00:51] <mwhudson> if you want your head to hurt, read the docs on what git reset --mixed does
[00:51] <mwhudson> (it's not what's wanted here though)
[00:51] <mwhudson> er
[00:51] <mwhudson> --merge
[00:51]  * thumper steadies himself to read the git man page
[00:51] <mwhudson> thumper: you want --mixed or --soft i think
[00:52] <mwhudson> they differ on whether the changes are left staged or not
[00:53] <thumper> git reset --soft HEAD^
[00:53] <mwhudson> yar
[00:53] <mwhudson> the help on git reset --merge is real http://git-man-page-generator.lokaltog.net/ stuff
[00:55] <thumper> ah actually, it is that followed by another
[00:55] <thumper> git reset
[00:55] <thumper> the latter takes the files from the index back into uncommitted state
[00:57] <thumper> mwhudson, cmars: what is the equivalent of "bzr pull --overwrite" ?
[00:57] <thumper> I want to reset my checkout to be tip of master
[01:12] <thumper> davecheney: actually, the machine config isn't in my area
[01:12]  * thumper steps away
[01:24]  * davecheney has reached the point that tests do not pass, at all, on my machine
[01:24] <davecheney> yet they pass 100% in CI
[01:24] <davecheney> whom am I to believe !?!
[01:30] <thumper> davecheney: huh?
[01:30] <thumper> what is failing?
[01:31]  * thumper ran master again just today with no failures
[01:31] <mwhudson> thumper: git reset --hard origin/master
[01:32] <mwhudson> (making sure you are in your local master branch first, probably)
[01:32] <thumper> mwhudson: ah... thanks, will do that next time
[01:32] <thumper> I ended up with the changes I needed, but not the history I wanted
[01:32] <thumper> but good enough
[01:33] <rick_h__> reset --hard won't save the current changes or uncommit a previous commit
[01:34] <thumper> rick_h__: sure, but I was asking then about an equivalent for "bzr pull --overwrite"
[01:34] <rick_h__> thumper: oh going off the backlog you asked for uncommit that kept the changes
[01:34] <thumper> rick_h__: I have "git reset HEAD^ && git reset" for uncommit
[01:34] <thumper> with a --soft on the first one
[01:34] <rick_h__> right
[01:34] <rick_h__> ok cool then
[01:35] <rick_h__> ah, didn't read far enough down the log my bad
[01:35] <thumper> rick_h__: np
[01:35] <thumper> I'm slowly getting my git legs
[01:35] <rick_h__> woot
[01:40] <davecheney> thumper: https://github.com/juju/juju/pull/309
[01:40] <davecheney> let's see if this one fits throught ci
[01:43] <thumper> davecheney: as a note, agentConfig.Tag() currently could be a machine tag or a unit tag
[01:43] <thumper> davecheney: until we merge the agents at least
[01:44] <davecheney> thumper: yup
[01:44] <davecheney> i've only found one case where agentconfig.Tag() could be a unit
[01:44] <davecheney> once that case is removed, we can tighten up the types and remove the runtime checks
[01:44] <thumper> davecheney: aarrgghhh
[01:44] <thumper> davecheney: why are we testing agents with user tags?
[01:45] <thumper> that's dumb
[01:45] <thumper> I can see it wasn't you
[01:45] <thumper> but geez
[01:45] <davecheney> why are we testing with _invalid_ tags ?
[01:45] <davecheney> that is the bigger headdesk
[01:45] <davecheney> agentConfig{tag: "machine-tag"}
[01:45] <davecheney> ^ not valid
[01:45] <davecheney> no sir
[01:46] <thumper> "omg" not valid either
[01:47] <davecheney> thumper: nope
[01:47] <davecheney> thumper: consider yourself nagged to nag fwreade to make a decision on the errors package
[01:47] <thumper> davecheney: I feel that we will make most progress with that next week when we can nag in person
[01:48] <thumper> davecheney: with sticks
[01:55] <davecheney> thumper: noted, consider yourself nagged
[01:55]  * thumper feels nagged
[02:01]  * davecheney is afraid what happens with I change those tests to not take user tags ...
[02:01] <davecheney> nothing good, i'll bet
[02:08] <davecheney> agent_test.go:410: c.Assert(err, gc.IsNil)
[02:08] <davecheney> ... value *errors.Err = [{/home/dfc/src/github.com/juju/juju/agent/agent.go:274: entity tag must be MachineTag or UnitTag, got names.UserTag}] ("entity tag must be MachineTag or UnitTag, got names.UserTag")
[02:08] <davecheney> argh!!!
[02:08] <davecheney> that's what I get for adding a test
[02:09] <davecheney> thumper: this is correct, right ?
[02:09] <davecheney> users cannot be agents
[02:09] <davecheney> or more specifically you cannot have an agent that represents a user
[02:09] <davecheney> only a machine or a unit, yes ?
[02:09] <thumper> yes
[02:09] <thumper> for what we currently have
[02:09] <thumper> yes
[02:09] <thumper> agents configs are only for machine agents and unit agents
[02:09] <thumper> maybe...
[02:10] <thumper> one day later
[02:10] <thumper> we may have something else
[02:10] <thumper> but more likely that we'll only have machine agents
[02:10] <thumper> and they may do something on behalf of a user
[02:10] <thumper> but the config is only for the machine
[02:10] <davecheney> ok
[02:10] <davecheney> i'll make sure that agent.ConfigParams only accepts tags of that type
[02:11] <davecheney> add tests and fix the other ones that are passing a user tag 'cos they are dumb
[02:11] <thumper> I am like 99% sure of that :-)
[02:11] <davecheney> close enough for government work
[02:11] <thumper> I would fire up a local provider
[02:11] <thumper> and deploy something
[02:11] <thumper> before committing to trunk :)
[02:11] <davecheney> will do
[03:52] <thumper> magic
[03:52] <thumper> juju/api.go:250
[03:52] <thumper> check that the variable isn't null after calling a function on it that needs it to be not null
[03:52]  * thumper will fix...
[03:52] <thumper> ish
[03:52]  * thumper goes to make coffee
[03:53] <thumper> ENEEDSCAFFEINE
[04:57] <davecheney> thumper: shuld I write tests that assert _only_ Units and Machines can host agents ?
[04:57] <davecheney> or is one test, ie, that a User Tag won't work is sufficient ?
[04:57] <thumper> I don't think you need to test all possible tags.
[04:57] <davecheney> thumper: cool
[04:58] <thumper> I'd test that machines and units work, and users don't
[04:58] <davecheney> i've tested that users won't fit through the filter
[04:58] <davecheney> there are shitloads of tests for machines's
[04:58] <davecheney> i'll add one for units and put a bow on it
[05:01] <davecheney> FOR FUCKS SAKE
[05:01] <davecheney> agent/agent_test.go
[05:01] <davecheney> the inspect config logic isn't used
[05:02] <davecheney> you can write anything in there and the test passes !
[05:32] <davecheney> my uniter tests have been unreliable since the actoins stuff landed
[05:32] <davecheney> http://paste.ubuntu.com/7796927/
[05:32] <davecheney> i smell a race
[05:32] <davecheney> or a logical failure there
[05:38] <jam> wallyworld: I'm looking at https://github.com/juju/juju/pull/282/files and I'm trying to see the logic change that fixed the bug. I see a bunch of changes towards error propagating, but not something that changed suppressing an error treating it as 'we don't have any instances'
[05:39] <wallyworld> jam: it's difficult to see (and explain). perhaos easiest to have a quck chat?
[05:39] <jam> wallyworld: ah, the "default" case
[05:39] <wallyworld> yeah
[05:39] <jam> wallyworld: I just couldn't see where the actual logic changed because of all the other error handling changes, but I see it now.
[05:40] <wallyworld> if we get an empty maps back out of that (instead of an error), were fucked donwnstream
[05:40] <wallyworld> jam: yeah, the error handling was a drive by to better log the errors
[05:41] <jam> wallyworld: yeah, I'm fine having it, just made it hard to locate the fix. FWIW, I don't feel like I knew about the critical customer-facing issues, should it have been escalated to canonical-juju@ at least?
[05:41] <wallyworld> jam: that default case is the root cause bt the actual bug is then triggered several api calls distant to that so it's hard to see the causal link
[05:41] <jam> wallyworld: sure, it is a case where we suppressed an error (accidentally, perhaps, though we thought we could continue at that point)
[05:42] <jam> wallyworld: I'm a little concerned that we might get a Unknown error intentionally (because that machine really has been removed) and the provisioner will start failing with errors.
[05:43] <wallyworld> jam: yeah i guess it should have gone to canonical-juju. has that been our policy previously? i  had assumed that folks who cared were across it because of the ubuntu advantage bug raised
[05:43] <jam> because we don't have any sort of knowledge about what error should and shouldn't be propagatetd
[05:43] <jam> wallyworld: *I* haven't been able to keep up with the bug backlog, and if I haven't then likely a good portion of the team hasn't. But I may just be biased.
[05:43] <wallyworld> jam: i'd have to look at the code again, but the unknon error is handled i think
[05:44] <jam> wallyworld: yeah, it was outside the diff
[05:44] <jam> IsCodeNotFoundOrUnauthorized is one of the cases
[05:44] <wallyworld> yeah
[05:44] <jam> wallyworld: k, I'm happy then. I think if we handle the errors we know about, and then puke on the rest, that is reasonable
[05:45] <jam> wallyworld: I feel like for escalated issues, a canonical-juju post is reasonable. Thoughts?
[05:45] <wallyworld> jam: fair point about the bug backlog etc. we've had a maybe 3 customer facing issues with 1.20 (some raised by cts).
[05:45] <davecheney> jam: +1
[05:45] <wallyworld> yeah i think so
[05:45] <jam> wallyworld: I just saw the "as you are aware", and I realized that I wasn't aware at all :)
[05:45] <davecheney> jam: and keep driving people back to the LP issue
[05:46] <davecheney> juju issues are tracked on LP
[05:46] <wallyworld> where was the "as you are aware" ?
[05:46] <davecheney> let's keep that message simple
[05:46] <jam> wallyworld: in Martin's post to canonical-juju
[05:46] <davecheney> and avoid people starting their own hit list of issues in google sheets, et al
[05:46] <jam> davecheney: I'm perfectly happy having it be a link to "here's an escalated bug we need more visilibilty on"
[05:46] <wallyworld> jam: i think that was directed at martin :-) but yeah, point taken
[05:47] <jam> wallyworld: from Martin: I am sending this out to the broader team, based on Robbie's guidance.  As you are aware, we have encountered a serious software defect with juju-core,
[05:47] <davecheney> jam: what is 'it'
[05:47] <jam> davecheney: the email to canonical-juju can certainly just be a link back to the LP bug.
[05:47] <wallyworld> jam: oh, right, i misremembered the content, sent so many emails today
[05:47] <davecheney> jam: +1, yes
[05:47] <davecheney> exactly
[05:48] <jam> wallyworld: I think my point is that trying to raise availability on a bug by raising another bug doesn't really help. :)
[05:48] <jam> raise awareness
[05:48] <jam> (visibility)
[05:48] <wallyworld> you mean the public bug linkd with the privayte one?
[05:49] <davecheney> wallyworld: jam agreed
[05:49] <wallyworld> that was for a separate but related issue
[05:49] <davecheney> juju bugs are tracked on launchpad
[05:49] <davecheney> that should be the constant message here
[05:49] <jam> wallyworld: your comment was "a u-a bug raised got all the involved parties more visibility", I'm not sure that it brought awareness to the greater juju team like a canonical-juju post would.
[05:50] <wallyworld> jam: with that comment, i meant customer facing stkeholders
[05:50] <wallyworld> martin was implying he wasn't across the issues, but he should have been
[05:51] <jam> wallyworld: I guess my point is that this sort of bug is sufficient that at least all team leads should be aware, and canonical-juju seems the easiest way to escalate it.
[05:51] <wallyworld> that's not to say that others in the canonical juju community wouldn't have benefited from a post to canonical-juju
[05:52] <jam> Regardless of what Martin said in his email, this seems serious enough that I would have liked to know about it, and I'm not sure there was a way that isn't "read all your bug mails"
[05:52] <wallyworld> fair enough, sorry
[05:52] <jam> wallyworld: that said I *really* appreciate that you and curtis really are tracking it well enough.
[05:52] <jam> I feel like I should be, but I feel a bit inundated
[05:53] <wallyworld> we're getting there. 1.20 certainly wasnt the best release
[05:53] <wallyworld> jam: it's not on your plate to do it - tanzanite is the release manager this cycle
[05:54] <jam> wallyworld: well, reading bugs can give you a pulse on what's going on with the greater ecosystem, it has the downside that we have a fair amount of bug churn that *doesn't* need to be read.
[05:54] <jam> Makes me wonder about the groupbuzz post recently
[05:54] <wallyworld> jam: these juju/mongo connection issues have always been there (part of the original implementation), just seems that they've gotton worse with 1.20, due perhaps to repliaset stuff turn on
[05:55] <jam> where you can easily opt-in/out of a given message thread
[05:55] <jam> with sane defaults
[05:55] <jam> wallyworld: perhaps, but they ran into this with 1.18, didn't they?
[05:55] <wallyworld> jam: yes they did. just seems subjectively worse with 1.20
[05:56] <wallyworld> there are more places where it bites us
[05:56] <jam> wallyworld: it seems very weird to have this hit 2 places within short succession and not have hit before
[05:56] <jam> with a release that is reasonably old now
[05:57] <wallyworld> jam: some of the 1.20 issues were due to new code added to jujud to deal with repliaset start up
[06:01] <jam> wallyworld: I do think https://github.com/juju/juju/pull/282/files#diff-edccfba67a01587c9faca9185781e5dbR285 should be backported to 1.18
[06:03] <wallyworld> jam: i'm inclined to agree. but i'm not yet +1 on backporting any change to safe mode default value
[06:03] <jam> wallyworld: yeah, I'm a bit confused about bug #1339770
[06:03] <jam> as it seems to be saying safe-mode, but is actually where you did the "don't kill things when we can't list machines"
[06:04] <jam> wallyworld: do you want to change the description of that bug to be clearer why it is fix released in 1.20.2 ?
[06:04] <jam> wallyworld: I think your point about changing safe mode default is perfectly sane. It would only effect new deployments anyway.
[06:04] <jam> (unless we add an upgrade to 1.18.X that toggles the setting)
[06:05] <wallyworld> jam: i already changed the bug description once
[06:05] <wallyworld> it used to be "Make provisioner-safe-mode defaults to True on MAAS provider."
[06:05] <jam> wallyworld: that's the title
[06:05] <wallyworld> i changed it to reflect the actual fix that was done
[06:05] <jam> the description is still "We should change the provisioner-safe-mode config entry to True on MAAS provider, so in any case when the state server goes down, juju will not trigger the MAAS release commands."
[06:05] <wallyworld> ah right, doh
[06:05] <wallyworld> yeah, ok
[07:50] <TheMue> morning
[08:24] <jam> morning TheMue
[08:27] <TheMue> jam: heya
[08:31] <dimitern> morning
[08:31] <TheMue> dimitern: morning
[09:01] <dimitern> TheMue, thx for the review
[09:03] <TheMue> dimitern: yw, liked it
[09:42] <tasdomas> is there any way to deploy juju (on ec2) with a mongodb that is accessible by the mongo client?
[10:09] <TheMue> jam: I’m afk for some time, won’t be back for standup. after finishing the flakey tests I’m now working LXC templates for IPv6.
[10:11] <wallyworld> fwereade: you around?
[10:11] <fwereade> wallyworld, hey dude
[10:11] <wallyworld> hey. do you have time to talk?
[10:11] <fwereade> wallyworld, let's
[10:11] <wwitzel3_> wallyworld, fwereade: I'm here as well
[10:11] <wallyworld> see you in the tanzanite standup hangout
[10:11] <fwereade> wwitzel3_, cool
[10:12] <fwereade> wallyworld, doesn't seem to be on my calendar -- link?
[10:12] <wallyworld> https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand
[10:12] <fwereade> wallyworld, cheers
[11:15] <psivaa> hello, i'm having a situation in local deployments.. where i have 'default-series: precise' in environments.yaml for 'local' but when i run 'juju bootstrap' i see 'uploading tools for series [trusty]'
[11:15] <psivaa> this makes precise based deployments fail to deploy.. the agent-state always states 'pending' for them
[11:16] <psivaa> and the machine-0.log states the following errors: http://paste.ubuntu.com/7797841/
[11:18] <psivaa> to workaround this we've had to bootstrap with '--upload-tools  --series precise,trusty' during bootstrap
[12:15]  * fwereade lunch, might be a bit late back
[12:19] <katco> good morning all
[12:26] <wwitzel3_> morning katco
[12:28] <katco> wwitzel3: thanks for a great sprint. it was great to meet you :)
[12:39] <natefinch> jam1, wallyworld, alexisb: anyone around to talk about the current critical bugs?
[12:39] <wallyworld> natefinch: i'm here but it's late so may not make much sense
[12:40] <wallyworld> natefinch: you talking 1.20 or 1.21?
[12:40] <wallyworld> we have 1.20 covered, apart from the licensing one
[12:42] <wallyworld> katco: try adding a card now, i've updated your permissions
[12:43] <katco> wallyworld: ty sir; trying now
[12:45] <katco> wallyworld: looks like that did it!
[12:46] <wallyworld> katco: great :-)
[12:46] <katco> wallyworld: oh and happy birthday to you son! (and axw)
[12:46] <wallyworld> lol
[12:46] <wallyworld> my son turns 20 on thursday bt we are having dinner etc on wednesday
[12:47] <katco> cool :) what is the legal drinking age there?
[12:47] <wallyworld> 18 :-D
[12:47] <katco> haha so 21 is not a big deal
[12:47]  * rick_h__ starts to refer to wallyworld as 'old man' :P
[12:47] <katco> well, 20 is a nice even number :)
[12:48] <wallyworld> rick_h__: this is a family channel or else i'd tell you to ..... ******
[12:48] <rick_h__> wallyworld: see, you're not thaaaaat tired. You filtered nicely.
[12:49] <katco> wallyworld: oh also should bugs 1319474 and 1319475 be assigned to "next stable release" now?
[12:50] <wallyworld> katco: yeah. too risky trying to get the goamz stuff done this week
[12:50] <katco> wallyworld: i agree.
[12:51] <wallyworld> katco: when we first started looking at those bugs, it seems plausible we could get something done but then it sorta got hard
[12:51] <wallyworld> katco: your family happy to see you again after a week away?
[12:51] <katco> wallyworld: oh god yes. my wife about tackled me.
[12:51] <katco> wallyworld: and then handed me a baby and walked away.
[12:52] <wallyworld> lol, i know how that goes :-)
[12:52] <wallyworld> i used to travel when my kids were young too
[12:52] <katco> it's hard! but i'm glad i went
[12:52] <katco> how was the flight back?
[12:52] <wallyworld> long
[12:53] <katco> =/
[12:53] <wallyworld> but i got home just in time for the 2nd half og the world cup final
[12:53] <katco> lol nice
[12:53] <katco> that was an amazing goal
[12:53] <katco> JITed goal ;)
[12:53] <wallyworld> yes it was. wish i had that skill
[12:53] <wallyworld> you nerd :-P
[12:53] <katco> haha you know it
[12:54] <katco> glad to be on a team of nerds; i love it!
[12:54] <wallyworld> i'm sad at myself i actually loled at that
[12:54] <katco> haha
[12:54] <katco> nerd is a compliment to me. we make the world go round!
[12:55] <wallyworld> katco: so you're ok to pick up those bugs for today, not blocked?
[12:55] <katco> wallyworld: yes, should be good to go
[12:55] <wallyworld> great. we can talk about juju-gui tomorrow or something
[12:56] <katco> okie doke; martin said something about just aliasing the juju bootstrap command or something?
[12:56] <katco> (do not need to answer now actually)
[12:56] <wallyworld> ok :-)
[12:56] <katco> go sleep!
[12:56] <wallyworld> soon :-)
[12:57]  * rick_h__ perks up his ears...gui?
[12:58] <wallyworld> rick_h__: we are going to deploy juju-gui auto magically in a juju environment
[12:58] <rick_h__> wallyworld: ooh shiny
[12:58] <wallyworld> as we discussed on the call last week
[12:58] <rick_h__> wallyworld: right, let me know if you hit any issues/questions
[12:58] <wallyworld> yeah, will be niiiiice to quote borat
[12:58] <wallyworld> will do
[12:58] <allenap> bac: Can we delay our meeting by 1h?
[12:59] <katco> rick_h__: your team made a nice web-app :)
[12:59] <rick_h__> katco: the team rocks and likes shiny things
[12:59] <katco> rick_h__: haha... are you guys looking at polymer at all?
[13:00] <rick_h__> katco: looking, but if we were to do anything we'd layer on top of react
[13:00] <katco> rick_h__: cool; haven't had a chance to play with it myself
[13:00] <rick_h__> but all the tools are only partial answers to our various problems and it's kind of ugh
[13:00] <rick_h__> at the tool/library proliferation
[13:01] <katco> rick_h__: yeah, i have seen that first-hand
[13:01] <bac> allenap: i have another then
[13:01] <bac> allenap: but even later would work
[13:02] <bac> allenap: 1530Z?
[13:02] <rick_h__> katco: then again I'm a cranky old man like wallyworld so I naturally hate all the new shiny stuff without proper build/test/integration solutions in place already
[13:02] <katco> rick_h__: sorry, not sure if that translated; i have seen that 1st hand at another company, not on the juju GUI
[13:02] <bac> wallyworld: is bug 1316174 on your radar? it affects juju-quickstart's ability to provision an environment and it doesn't look like there is a work-around.
[13:02] <_mup_> Bug #1316174: 'precise-updates/cloud-tools' is invalid for APT::Default-Release <juju-core:Triaged> <https://launchpad.net/bugs/1316174>
[13:03] <rick_h__> katco: all good, I think I followed
[13:03] <wallyworld> bac: no, hadn't seen that
[13:03] <bac> wallyworld: well, you triaged it.  :)
[13:04] <wallyworld> bac: ah, sorry, i meant the quickstart flow on effect
[13:04] <allenap> bac: Cool.
[13:04] <bac> wallyworld: if juju-core is not installed, quickstart will install juju-core and juju-local before continuing.  those two are no long sufficient due to this bug
[13:05] <wallyworld> bac: i must admit, without digging a bit more, i'm not 100% sure what the issue is as i did think juju-local was sufficient
[13:07] <bac> wallyworld: just wanted to bring it to your attention. have a good evening
[13:07] <wallyworld> bac: thanks, i'll assign the bug to 1.21-alpha1 so we at least guaratee to look at it before the next release
[13:08] <wallyworld> hopefully "look at it" = "fix it"
[13:08] <bac> ty
[13:47] <katco> seeing some behavior i don't understand with godeps -u... it wasn't pulling down the commit it says it should; i had to do a go get -u. has anyone experienced that? am i doing something wrong?
[13:51] <natefinch> katco: you need to do godeps -f -u to get commits that aren't on your local machine.  -u will fail if you reference a commit that hasn't been pulled down already
[13:51] <natefinch> (why this is not just the default behavior, I don't know)
[13:51] <katco> natefinch: ah shoot that's right
[13:51] <katco> natefinch: thank you
[13:51] <natefinch> katco:  welcome :)
[14:58] <katco> does anyone see any issues with setting the owner of the machine.x.logs to syslog:syslog?
[14:58] <TheMue> natefinch: hmm, don’t find where to see who’s allowed to merge into the juju repo
[15:07] <voidspace> morning all
[15:08] <katco> good morning voidspace
[15:09] <voidspace> katco: morning
[15:09] <voidspace> katco: good to be back with the family?
[15:09] <voidspace> katco: dumb question I know :-)
[15:09] <ericsnow> voidspace: a day too soon, no? :)
[15:09] <katco> voidspace: definitely!
[15:09] <voidspace> ericsnow: I'm doing a couple of hours today as my wife has an ultrasound tomorrow that I'd like to be at
[15:09] <ericsnow> katco: :)
[15:09] <ericsnow> voidspace: nice
[15:09] <voidspace> ericsnow: :-)
[15:09] <katco> this might be a matter of opinion, but after i'm reasonably sure i have a good fix, should i run the test sfor just the sub-module, or the entire juju project?
[15:10] <katco> voidspace: congrats again!
[15:10] <voidspace> katco: thanks
[15:10] <katco> this is great... i know who people are now. :)
[15:11] <voidspace> katco: it makes a big difference doesn't it
[15:12] <katco> voidspace: it really does
[15:12] <katco> eric's now not just a name!
[15:14] <ericsnow> katco: haha
[15:14] <bac> allenap: are you free now?
[15:17] <allenap> rvba: Are you free to talk to bac now?
[15:18] <rvba> allenap: yep
[15:18] <bac> allenap: oh, i didn't know you were bringing backup
[15:19] <allenap> bac: Yes indeed, because my brain is hopelessly sieve-like :)
[15:19] <allenap> bac: Anyway, https://plus.google.com/hangouts/_/canonical.com/azure?v=1404955657
[15:36] <bodie_> https://github.com/juju/juju/pull/311 review would be appreciated!
[15:51] <alexisb> wwitzel3, ping
[15:52] <alexisb> natefinch, ping
[15:56] <TheMue> bodie_: *click*
[15:58] <bodie_> And another -- https://github.com/juju/juju/pull/312
[16:05] <wwitzel3> alexisb: back
[16:05] <alexisb> are you going to be on the tosca call?
[16:05] <alexisb> I have a conflict
[16:06] <wwitzel3> alexisb: yeah, I was just getting logged in now
[16:06] <alexisb> cool
[16:06] <alexisb> I will get a debrief from you then
[16:06] <alexisb> I will try to join when I am done wit this other call
[16:06] <alexisb> thanks wwitzel3 !
[16:09] <natefinch> alexisb: here now
[16:10] <alexisb> natefinch, I was just making sure we had coverage on the tosca call
[16:10] <alexisb> wwitzel3, is on
[16:11] <natefinch> alexisb:  I'll hop on
[16:11] <katco> https://github.com/juju/juju/pull/313
[16:12] <voidspace> natefinch: so, I've tried a different approach to "session copying"
[16:12] <voidspace> natefinch: this time first looking at the watchers rather than the transaction runners
[16:12] <voidspace> natefinch: and again run into the "auth failed" error
[16:13] <natefinch> voidspace: ug
[16:13] <natefinch> voidspace: isn't today a swap day for you?
[16:13] <voidspace> natefinch: didn't you already reply to my email about that :-)
[16:13] <voidspace> natefinch: it is, I'm putting a couple of hours in today
[16:13] <voidspace> natefinch: my main point of attack on this is assuming that the mongo password is being changed after the session is created
[16:13] <voidspace> natefinch: and the session isn't updated
[16:14] <voidspace> natefinch: before I deep dive into that, does that sound likely to you?
[16:14] <voidspace> or does anything else occur to you about it
[16:15] <voidspace> natefinch: anyway, I'm updating my coffee first
[16:16] <voidspace> I also wonder how this work of untangling session use from watchers will intersect with the "persistence layer" refactoring that wwitzel3 and wallyworld are embarking on
[16:18] <natefinch> voidspace: I'm really not sure.  I think you've done a lot more spelunking on it recently than I have.
[16:18] <voidspace> natefinch: ok, cool
[16:19] <voidspace> natefinch: I just didn't want to embark on a path that was "obviously dumb" to someone with more knowledge
[16:19] <voidspace> natefinch: so I'm just running it by you as a sanity check
[16:19] <voidspace> I'll continue the investigation
[16:21] <natefinch> voidspace: doesn't sound dumb to me
[16:22] <voidspace> good, thanks
[16:38] <TheMue> bodie_: 312 is reviewed
[17:14] <bodie_> thanks TheMue !
[17:29] <TheMue> bodie_: yw
[18:03] <katco> what is the use case for this code branch? why would we want to continue bootstrapping if an environment is already found? https://github.com/juju/juju/blob/master/cmd/juju/common.go#L40
[18:05] <katco> also, anyone? https://github.com/juju/juju/pull/313
[18:06] <rick_h__> katco: just as an fyi, not sure if this fits into what you're looking at or not 17:26    balboah| ~balboah@air.joonix.se has joined #juju
[18:06] <rick_h__> bah
[18:06] <rick_h__> katco: https://bugs.launchpad.net/juju-core/+bug/1336843
[18:06] <_mup_> Bug #1336843: bootstrap without a jenv destroys an existing environment  <bootstrap> <juju-core:Triaged> <https://launchpad.net/bugs/1336843>
[18:07] <katco> rick_h__: hm, looks plausibly related
[18:07] <natefinch> katco: it's not just for bootstrap, it's also used by sync-tools
[18:08] <katco> rick_h__: different code-path, but probably very related... maybe i can fix that too if i get time
[18:08] <rick_h__> katco: rgr, just as an fyi as it seemed close
[18:08] <katco> rick_h__: yeah tyvm
[18:09] <katco> natefinch: remind me what sync-tools does again
[18:09] <natefinch> This copies the Juju tools tarball from the official tools store (located
[18:09] <natefinch> at https://streams.canonical.com/juju) into your environment.
[18:09] <natefinch> This is generally done when you want Juju to be able to run without having to
[18:09] <natefinch> access the Internet. Alternatively you can specify a local directory as source.
[18:09] <natefinch> katco: juju help sync-tools :)
[18:12] <katco> natefinch: ahhh! ok, ty. i will have to think on that a bit
[18:21] <marcoceppi> What is "safe-mode" for juju?
[18:28] <voidspace> marcoceppi: I'm not familiar with it, but the implication from the email thread is that juju won't destroy instances for you in safe mode - even if it thinks they're unused
[18:28] <voidspace> marcoceppi: that's what it sounded like anyway
[18:29] <voidspace> I'm EOD
[18:29] <marcoceppi> That's what I gathered as well, I just want to update the documentation
[18:29] <voidspace> g'night all until tomorrrow
[18:29] <katco> voidspace: tc
[18:29] <voidspace> marcoceppi: ah... you'll want a more authoritative answer
[18:29] <voidspace> katco: o/
[18:36] <katco> i could use a review to see if i'm on the right track: https://github.com/katco-/juju/compare/lp-1340893-bootstrap-destroy
[18:36] <katco> this is for https://bugs.launchpad.net/juju-core/+bug/1340893
[18:36] <_mup_> Bug #1340893: juju bootstrap in an existing environment destroys the environment <bootstrap> <canonical-is> <juju-core:In Progress by cox-katherine-e> <https://launchpad.net/bugs/1340893>
[18:39] <tasdomas> I'm trying to debug a txn.Op that works in tests but for some reason fails when I deploy a juju environment running that code on ec2
[20:58] <thumper> morning
[21:10] <alexisb> morning thumper
[21:27] <wallyworld> katco: hi, time for a quick catch up?
[21:35] <alexisb> wallyworld, you should be sleeping
[21:36] <wallyworld> alexisb: it's 7:30am here now :-)
[21:36] <alexisb> o ok
[21:37] <alexisb> wallyworld, fyi, I found out today that the license bug is holding up the server group release
[21:37] <alexisb> I sent mail but that is going to get hot given that customers are looking for the distroy env fix that was put in 1.20.1
[21:37] <wallyworld> alexisb: yeah,  need to talk to you about that. potentialy very non trivial. can we chat after the testingmeeting?
[21:38] <alexisb> wallyworld, sure
[21:39] <alexisb> what ever support you need, we will have to find a way to make it happen
[21:39] <wallyworld> yeah, will be "fun"
[22:07]  * thumper needs moar caffeine
[23:19] <sinzui> thumper, https://bugs.launchpad.net/juju-core/+bug/1342106
[23:19] <_mup_> Bug #1342106: add-machine fails in recent commit <add-machine> <ci> <manual-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1342106>
[23:37] <thumper> sinzui: looking
[23:38] <thumper> sinzui: can we talk through this? hangout?
[23:38] <sinzui> thumper, okay
[23:38] <thumper> sinzui: https://plus.google.com/hangouts/_/canonical.com/manual-fail
[23:55] <wallyworld> sinzui: you already on another hangout?
[23:55] <voidspace> wallyworld: hey, hi
[23:56] <wallyworld> hey
[23:56] <wallyworld> late for you
[23:56] <voidspace> wallyworld: did you see my latest email? I made some progress.
[23:56] <wallyworld> voidspace: not yet, been on other stuff, let me look
[23:56] <voidspace> wallyworld: when I corrected my code to *actually* return the state opened with the changed password those auth failures went away
[23:56] <voidspace> wallyworld: so progress
[23:56] <voidspace> wallyworld: that's pretty much it
[23:57] <voidspace> wallyworld: I have two branches, I'll combine them tomorrow and push and then we can discuss it
[23:57] <wallyworld> voidspace: i fuck, do you know how much i hate := vs =
[23:57] <voidspace> wallyworld: heh
[23:58] <voidspace> me too now...
[23:58] <wallyworld> let's talk tomorrow, we can pick up where you get to
[23:58] <voidspace> yep, 1am here so going to bed
[23:58] <voidspace> g'night
[23:58] <wallyworld> night and thank you