=== Guest14971 is now known as wallyworld [00:40] o_O [00:40] func (cfg *MachineConfig) addMachineAgentToBoot(c *cloudinit.Config, tag, machineId string) error { [00:40] is the tag _not_ the machine id !?!? [00:48] davecheney: this is in my area [00:48] I'm tweaking things around there [00:49] let me look [00:49] * thumper has a headache [00:49] * thumper need more coffee [00:49] does anyone remember the git equivalent of uncommit? [00:49] thumper, git reset [00:49] cmars: will that leave me the changes still? [00:50] thumper, depends on how you use it [00:50] I want the changes [00:50] thumper, i need to look up the flags for that case [00:51] if you want your head to hurt, read the docs on what git reset --mixed does [00:51] (it's not what's wanted here though) [00:51] er [00:51] --merge [00:51] * thumper steadies himself to read the git man page [00:51] thumper: you want --mixed or --soft i think [00:52] they differ on whether the changes are left staged or not [00:53] git reset --soft HEAD^ [00:53] yar [00:53] the help on git reset --merge is real http://git-man-page-generator.lokaltog.net/ stuff [00:55] ah actually, it is that followed by another [00:55] git reset [00:55] the latter takes the files from the index back into uncommitted state [00:57] mwhudson, cmars: what is the equivalent of "bzr pull --overwrite" ? [00:57] I want to reset my checkout to be tip of master [01:12] 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] yet they pass 100% in CI [01:24] whom am I to believe !?! [01:30] davecheney: huh? [01:30] what is failing? [01:31] * thumper ran master again just today with no failures [01:31] thumper: git reset --hard origin/master [01:32] (making sure you are in your local master branch first, probably) [01:32] mwhudson: ah... thanks, will do that next time [01:32] I ended up with the changes I needed, but not the history I wanted [01:32] but good enough [01:33] reset --hard won't save the current changes or uncommit a previous commit [01:34] rick_h__: sure, but I was asking then about an equivalent for "bzr pull --overwrite" [01:34] thumper: oh going off the backlog you asked for uncommit that kept the changes [01:34] rick_h__: I have "git reset HEAD^ && git reset" for uncommit [01:34] with a --soft on the first one [01:34] right [01:34] ok cool then [01:35] ah, didn't read far enough down the log my bad [01:35] rick_h__: np [01:35] I'm slowly getting my git legs [01:35] woot [01:40] thumper: https://github.com/juju/juju/pull/309 [01:40] let's see if this one fits throught ci [01:43] davecheney: as a note, agentConfig.Tag() currently could be a machine tag or a unit tag [01:43] davecheney: until we merge the agents at least [01:44] thumper: yup [01:44] i've only found one case where agentconfig.Tag() could be a unit [01:44] once that case is removed, we can tighten up the types and remove the runtime checks [01:44] davecheney: aarrgghhh [01:44] davecheney: why are we testing agents with user tags? [01:45] that's dumb [01:45] I can see it wasn't you [01:45] but geez [01:45] why are we testing with _invalid_ tags ? [01:45] that is the bigger headdesk [01:45] agentConfig{tag: "machine-tag"} [01:45] ^ not valid [01:45] no sir [01:46] "omg" not valid either [01:47] thumper: nope [01:47] thumper: consider yourself nagged to nag fwreade to make a decision on the errors package [01:47] davecheney: I feel that we will make most progress with that next week when we can nag in person [01:48] davecheney: with sticks [01:55] 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] nothing good, i'll bet [02:08] agent_test.go:410: c.Assert(err, gc.IsNil) [02:08] ... 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] argh!!! [02:08] that's what I get for adding a test [02:09] thumper: this is correct, right ? [02:09] users cannot be agents [02:09] or more specifically you cannot have an agent that represents a user [02:09] only a machine or a unit, yes ? [02:09] yes [02:09] for what we currently have [02:09] yes [02:09] agents configs are only for machine agents and unit agents [02:09] maybe... [02:10] one day later [02:10] we may have something else [02:10] but more likely that we'll only have machine agents [02:10] and they may do something on behalf of a user [02:10] but the config is only for the machine [02:10] ok [02:10] i'll make sure that agent.ConfigParams only accepts tags of that type [02:11] add tests and fix the other ones that are passing a user tag 'cos they are dumb [02:11] I am like 99% sure of that :-) [02:11] close enough for government work [02:11] I would fire up a local provider [02:11] and deploy something [02:11] before committing to trunk :) [02:11] will do [03:52] magic [03:52] juju/api.go:250 [03:52] 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] ish [03:52] * thumper goes to make coffee [03:53] ENEEDSCAFFEINE [04:57] thumper: shuld I write tests that assert _only_ Units and Machines can host agents ? [04:57] or is one test, ie, that a User Tag won't work is sufficient ? [04:57] I don't think you need to test all possible tags. [04:57] thumper: cool [04:58] I'd test that machines and units work, and users don't [04:58] i've tested that users won't fit through the filter [04:58] there are shitloads of tests for machines's [04:58] i'll add one for units and put a bow on it [05:01] FOR FUCKS SAKE [05:01] agent/agent_test.go [05:01] the inspect config logic isn't used [05:02] you can write anything in there and the test passes ! [05:32] my uniter tests have been unreliable since the actoins stuff landed [05:32] http://paste.ubuntu.com/7796927/ [05:32] i smell a race [05:32] or a logical failure there [05:38] 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] jam: it's difficult to see (and explain). perhaos easiest to have a quck chat? [05:39] wallyworld: ah, the "default" case [05:39] yeah [05:39] 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] if we get an empty maps back out of that (instead of an error), were fucked donwnstream [05:40] jam: yeah, the error handling was a drive by to better log the errors [05:41] 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] 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] wallyworld: sure, it is a case where we suppressed an error (accidentally, perhaps, though we thought we could continue at that point) [05:42] 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] 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] because we don't have any sort of knowledge about what error should and shouldn't be propagatetd [05:43] 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] jam: i'd have to look at the code again, but the unknon error is handled i think [05:44] wallyworld: yeah, it was outside the diff [05:44] IsCodeNotFoundOrUnauthorized is one of the cases [05:44] yeah [05:44] 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] wallyworld: I feel like for escalated issues, a canonical-juju post is reasonable. Thoughts? [05:45] 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] jam: +1 [05:45] yeah i think so [05:45] wallyworld: I just saw the "as you are aware", and I realized that I wasn't aware at all :) [05:45] jam: and keep driving people back to the LP issue [05:46] juju issues are tracked on LP [05:46] where was the "as you are aware" ? [05:46] let's keep that message simple [05:46] wallyworld: in Martin's post to canonical-juju [05:46] and avoid people starting their own hit list of issues in google sheets, et al [05:46] davecheney: I'm perfectly happy having it be a link to "here's an escalated bug we need more visilibilty on" [05:46] jam: i think that was directed at martin :-) but yeah, point taken [05:47] 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] jam: what is 'it' [05:47] davecheney: the email to canonical-juju can certainly just be a link back to the LP bug. [05:47] jam: oh, right, i misremembered the content, sent so many emails today [05:47] jam: +1, yes [05:47] exactly [05:48] wallyworld: I think my point is that trying to raise availability on a bug by raising another bug doesn't really help. :) [05:48] raise awareness [05:48] (visibility) [05:48] you mean the public bug linkd with the privayte one? [05:49] wallyworld: jam agreed [05:49] that was for a separate but related issue [05:49] juju bugs are tracked on launchpad [05:49] that should be the constant message here [05:49] 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] jam: with that comment, i meant customer facing stkeholders [05:50] martin was implying he wasn't across the issues, but he should have been [05:51] 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] that's not to say that others in the canonical juju community wouldn't have benefited from a post to canonical-juju [05:52] 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] fair enough, sorry [05:52] wallyworld: that said I *really* appreciate that you and curtis really are tracking it well enough. [05:52] I feel like I should be, but I feel a bit inundated [05:53] we're getting there. 1.20 certainly wasnt the best release [05:53] jam: it's not on your plate to do it - tanzanite is the release manager this cycle [05:54] 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] Makes me wonder about the groupbuzz post recently [05:54] 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] where you can easily opt-in/out of a given message thread [05:55] with sane defaults [05:55] wallyworld: perhaps, but they ran into this with 1.18, didn't they? [05:55] jam: yes they did. just seems subjectively worse with 1.20 [05:56] there are more places where it bites us [05:56] wallyworld: it seems very weird to have this hit 2 places within short succession and not have hit before [05:56] with a release that is reasonably old now [05:57] jam: some of the 1.20 issues were due to new code added to jujud to deal with repliaset start up [06:01] wallyworld: I do think https://github.com/juju/juju/pull/282/files#diff-edccfba67a01587c9faca9185781e5dbR285 should be backported to 1.18 [06:03] jam: i'm inclined to agree. but i'm not yet +1 on backporting any change to safe mode default value [06:03] wallyworld: yeah, I'm a bit confused about bug #1339770 [06:03] 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] 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] wallyworld: I think your point about changing safe mode default is perfectly sane. It would only effect new deployments anyway. [06:04] (unless we add an upgrade to 1.18.X that toggles the setting) [06:05] jam: i already changed the bug description once [06:05] it used to be "Make provisioner-safe-mode defaults to True on MAAS provider." [06:05] wallyworld: that's the title [06:05] i changed it to reflect the actual fix that was done [06:05] 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] ah right, doh [06:05] yeah, ok === uru-afk is now known as urulama === vladk|offline is now known as vladk [07:50] morning [08:24] morning TheMue [08:27] jam: heya [08:31] morning [08:31] dimitern: morning [09:01] TheMue, thx for the review [09:03] dimitern: yw, liked it [09:42] is there any way to deploy juju (on ec2) with a mongodb that is accessible by the mongo client? [10:09] 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] fwereade: you around? [10:11] wallyworld, hey dude [10:11] hey. do you have time to talk? [10:11] wallyworld, let's [10:11] wallyworld, fwereade: I'm here as well [10:11] see you in the tanzanite standup hangout [10:11] wwitzel3_, cool [10:12] wallyworld, doesn't seem to be on my calendar -- link? [10:12] https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand [10:12] wallyworld, cheers [11:15] 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] this makes precise based deployments fail to deploy.. the agent-state always states 'pending' for them [11:16] and the machine-0.log states the following errors: http://paste.ubuntu.com/7797841/ [11:18] to workaround this we've had to bootstrap with '--upload-tools --series precise,trusty' during bootstrap === psivaa is now known as psivaa-off [12:15] * fwereade lunch, might be a bit late back [12:19] good morning all [12:26] morning katco === wwitzel3_ is now known as wwitzel3 [12:28] wwitzel3: thanks for a great sprint. it was great to meet you :) [12:39] jam1, wallyworld, alexisb: anyone around to talk about the current critical bugs? [12:39] natefinch: i'm here but it's late so may not make much sense [12:40] natefinch: you talking 1.20 or 1.21? [12:40] we have 1.20 covered, apart from the licensing one [12:42] katco: try adding a card now, i've updated your permissions [12:43] wallyworld: ty sir; trying now [12:45] wallyworld: looks like that did it! [12:46] katco: great :-) [12:46] wallyworld: oh and happy birthday to you son! (and axw) [12:46] lol [12:46] my son turns 20 on thursday bt we are having dinner etc on wednesday [12:47] cool :) what is the legal drinking age there? [12:47] 18 :-D [12:47] haha so 21 is not a big deal [12:47] * rick_h__ starts to refer to wallyworld as 'old man' :P [12:47] well, 20 is a nice even number :) [12:48] rick_h__: this is a family channel or else i'd tell you to ..... ****** [12:48] wallyworld: see, you're not thaaaaat tired. You filtered nicely. [12:49] wallyworld: oh also should bugs 1319474 and 1319475 be assigned to "next stable release" now? [12:50] katco: yeah. too risky trying to get the goamz stuff done this week [12:50] wallyworld: i agree. [12:51] 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] katco: your family happy to see you again after a week away? [12:51] wallyworld: oh god yes. my wife about tackled me. [12:51] wallyworld: and then handed me a baby and walked away. [12:52] lol, i know how that goes :-) [12:52] i used to travel when my kids were young too [12:52] it's hard! but i'm glad i went [12:52] how was the flight back? [12:52] long [12:53] =/ [12:53] but i got home just in time for the 2nd half og the world cup final [12:53] lol nice [12:53] that was an amazing goal [12:53] JITed goal ;) [12:53] yes it was. wish i had that skill [12:53] you nerd :-P [12:53] haha you know it [12:54] glad to be on a team of nerds; i love it! [12:54] i'm sad at myself i actually loled at that [12:54] haha [12:54] nerd is a compliment to me. we make the world go round! [12:55] katco: so you're ok to pick up those bugs for today, not blocked? [12:55] wallyworld: yes, should be good to go [12:55] great. we can talk about juju-gui tomorrow or something [12:56] okie doke; martin said something about just aliasing the juju bootstrap command or something? [12:56] (do not need to answer now actually) [12:56] ok :-) [12:56] go sleep! [12:56] soon :-) [12:57] * rick_h__ perks up his ears...gui? [12:58] rick_h__: we are going to deploy juju-gui auto magically in a juju environment [12:58] wallyworld: ooh shiny [12:58] as we discussed on the call last week [12:58] wallyworld: right, let me know if you hit any issues/questions [12:58] yeah, will be niiiiice to quote borat [12:58] will do [12:58] bac: Can we delay our meeting by 1h? [12:59] rick_h__: your team made a nice web-app :) [12:59] katco: the team rocks and likes shiny things [12:59] rick_h__: haha... are you guys looking at polymer at all? [13:00] katco: looking, but if we were to do anything we'd layer on top of react [13:00] rick_h__: cool; haven't had a chance to play with it myself [13:00] but all the tools are only partial answers to our various problems and it's kind of ugh [13:00] at the tool/library proliferation [13:01] rick_h__: yeah, i have seen that first-hand [13:01] allenap: i have another then [13:01] allenap: but even later would work [13:02] allenap: 1530Z? [13:02] 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] rick_h__: sorry, not sure if that translated; i have seen that 1st hand at another company, not on the juju GUI [13:02] 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 [13:03] katco: all good, I think I followed [13:03] bac: no, hadn't seen that [13:03] wallyworld: well, you triaged it. :) [13:04] bac: ah, sorry, i meant the quickstart flow on effect [13:04] bac: Cool. [13:04] 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] 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] wallyworld: just wanted to bring it to your attention. have a good evening [13:07] 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] hopefully "look at it" = "fix it" [13:08] ty [13:47] 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] 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] (why this is not just the default behavior, I don't know) [13:51] natefinch: ah shoot that's right [13:51] natefinch: thank you [13:51] katco: welcome :) === vladk is now known as vladk|offline [14:58] does anyone see any issues with setting the owner of the machine.x.logs to syslog:syslog? [14:58] natefinch: hmm, don’t find where to see who’s allowed to merge into the juju repo [15:07] morning all [15:08] good morning voidspace [15:09] katco: morning [15:09] katco: good to be back with the family? [15:09] katco: dumb question I know :-) [15:09] voidspace: a day too soon, no? :) [15:09] voidspace: definitely! [15:09] 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] katco: :) [15:09] voidspace: nice [15:09] ericsnow: :-) [15:09] 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] voidspace: congrats again! [15:10] katco: thanks [15:10] this is great... i know who people are now. :) [15:11] katco: it makes a big difference doesn't it [15:12] voidspace: it really does [15:12] eric's now not just a name! [15:14] katco: haha [15:14] allenap: are you free now? [15:17] rvba: Are you free to talk to bac now? [15:18] allenap: yep [15:18] allenap: oh, i didn't know you were bringing backup [15:19] bac: Yes indeed, because my brain is hopelessly sieve-like :) [15:19] bac: Anyway, https://plus.google.com/hangouts/_/canonical.com/azure?v=1404955657 [15:36] https://github.com/juju/juju/pull/311 review would be appreciated! [15:51] wwitzel3, ping [15:52] natefinch, ping [15:56] bodie_: *click* [15:58] And another -- https://github.com/juju/juju/pull/312 [16:05] alexisb: back [16:05] are you going to be on the tosca call? [16:05] I have a conflict [16:06] alexisb: yeah, I was just getting logged in now [16:06] cool [16:06] I will get a debrief from you then [16:06] I will try to join when I am done wit this other call [16:06] thanks wwitzel3 ! [16:09] alexisb: here now [16:10] natefinch, I was just making sure we had coverage on the tosca call [16:10] wwitzel3, is on [16:11] alexisb: I'll hop on [16:11] https://github.com/juju/juju/pull/313 [16:12] natefinch: so, I've tried a different approach to "session copying" [16:12] natefinch: this time first looking at the watchers rather than the transaction runners [16:12] natefinch: and again run into the "auth failed" error [16:13] voidspace: ug [16:13] voidspace: isn't today a swap day for you? [16:13] natefinch: didn't you already reply to my email about that :-) [16:13] natefinch: it is, I'm putting a couple of hours in today [16:13] natefinch: my main point of attack on this is assuming that the mongo password is being changed after the session is created [16:13] natefinch: and the session isn't updated [16:14] natefinch: before I deep dive into that, does that sound likely to you? [16:14] or does anything else occur to you about it [16:15] natefinch: anyway, I'm updating my coffee first [16:16] 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] voidspace: I'm really not sure. I think you've done a lot more spelunking on it recently than I have. [16:18] natefinch: ok, cool [16:19] natefinch: I just didn't want to embark on a path that was "obviously dumb" to someone with more knowledge [16:19] natefinch: so I'm just running it by you as a sanity check [16:19] I'll continue the investigation [16:21] voidspace: doesn't sound dumb to me [16:22] good, thanks [16:38] bodie_: 312 is reviewed [17:14] thanks TheMue ! [17:29] bodie_: yw [18:03] 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] also, anyone? https://github.com/juju/juju/pull/313 === alexisb is now known as alexisb_lunch [18:06] 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] bah [18:06] katco: https://bugs.launchpad.net/juju-core/+bug/1336843 [18:06] <_mup_> Bug #1336843: bootstrap without a jenv destroys an existing environment

[18:07] rick_h__: hm, looks plausibly related [18:07] katco: it's not just for bootstrap, it's also used by sync-tools [18:08] rick_h__: different code-path, but probably very related... maybe i can fix that too if i get time [18:08] katco: rgr, just as an fyi as it seemed close [18:08] rick_h__: yeah tyvm [18:09] natefinch: remind me what sync-tools does again [18:09] This copies the Juju tools tarball from the official tools store (located [18:09] at https://streams.canonical.com/juju) into your environment. [18:09]