[00:23] <bodie_> would be great if I could get a quick LGTM so I can get this dep update in
[00:23] <bodie_> https://github.com/juju/charm/pull/5
[00:23] <bodie_> nvm, think I'm covered
[00:25] <jcw4> I would appreciate a quick review on https://github.com/juju/names/pull/8 ... it's only documentation and variable name changes to clarify intent
[00:26] <jcw4> diffstat +14 -14
[00:30] <bodie_> just stepping away to eat, I'll get you after if nobody else has
[00:30] <jcw4> bodie_: thanks
[00:35] <rick_h_> thumper: will check back with you.
[00:36] <jcw4> wallyworld: tx
[00:36] <wallyworld> np
[01:08] <waigani> thumper: you about?
[01:12] <jcw4> wallyworld; new pull request https://github.com/juju/juju/pull/116  (diffstat +56/-43)
[01:12] <jcw4> I'm afraid I don't know the irc nick for Horacio?
[01:12] <wallyworld> jcw4: jut finishing another review, will look real soon now
[01:12] <wallyworld> jcw4: it's perrito666 but he's likely asleep now
[01:13] <jcw4> thanks wallyworld
[01:13] <jcw4> perrito666: Sorry didn't know you were he :)
[01:15]  * jcw4 steps away for a while
[01:21] <sinzui> thumper, I want to do that in 2 days. Juju HA/backup-reatore is broken. If I must release, I will take a revision from last week. This what we had to do for 1.19.3 as well
[01:27] <thumper> waigani: ya
[01:28] <thumper> sinzui: ack
[01:28] <thumper> rick_h_: hey, back now
[01:29] <sinzui> perrito666, I not really. I see a few of these cases, but they resolve themselve in a 2nd run http://juju-ci.vapour.ws:8080/job/aws-deploy-precise-amd64/1323/console
[01:30] <waigani> thumper: in the factory tests e.g. TestMakeUserAny, if I add c.Assert(saved, jc.DeepEquals, user), it fails
[01:30] <waigani> thumper: ... mismatch at (*(*).doc.DateCreated.loc).name: unequal; obtained "Local"; expected "UTC"
[01:31] <waigani> thumper: if I call user.DateCreated().Location().String() - it returns "UTC", even when in the doc the loc name is "Local"
[01:31] <wallyworld> sinzui: there's some critical stuff landed this week which we can't ship 1.20 without, so if we do release 1.19.4 with a rev from last week, we'll need to do a 1.19.5 as well
[01:32] <thumper> waigani: push up your latest, and I'll grab it and look here
[01:32] <sinzui> perrito666, Merge pull request #79 from perrito666/translate_backup_to_go is the last good rev for backup-reatore. A lot of branches landed while joyent and ha stalled ci for 21 hours
[01:32] <jcw4> wallyworld: you're a machine... thanks :)  I'll add those comments and split that test
[01:32] <rick_h_> thumper: hey, let me know when you get a sec
[01:32] <wallyworld> awesome, thank you
[01:33] <sinzui> perrito666, commit ba83d11 is the last good commit for backup-restore
[01:33] <thumper> rick_h_: I'm just munching right now, let me finish eating and help waigani
[01:33] <rick_h_> thumper: rgr
[01:33] <sinzui> wallyworld, I think that is a given, juju has not proven itself to be stable for user
[01:34] <wallyworld> sinzui: i've not got to the joyent root cause of suckiness yet. how is hp looking?
[01:34] <sinzui> in a word, *fucked*
[01:34] <waigani> thumper: I don't have anything to push. Just add this test to testing/factory/factory_test.go and you'll see the problem: http://pastebin.ubuntu.com/7661265/
[01:35] <thumper> ok, let me look
[01:35] <wallyworld> sinzui: but we think it's because of cloud resourcing issues rather than juju per se right?
[01:35] <sinzui> wallyworld, I region-b doesn't have writable provider storage. The test failed, This is the error I always see with HP http://juju-ci.vapour.ws:8080/job/hp-upgrade-precise-amd64/1349/console
[01:36] <wallyworld> axw: morning. any chance of you looking at bug 1329477 today?
[01:36] <_mup_> Bug #1329477: Destroying a juju machine with the manual provider, does not completely shutdown any services installed on that machine <destroy-machine> <hs-arm64> <manual-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1329477>
[01:36] <sinzui> wallyworld, since that error is with 1.18.4. I know the problem is Hp
[01:36] <axw> wallyworld: yep, sure. just fixing up ec2 again, will take a look after
[01:36] <wallyworld> axw: ta
[01:36] <wallyworld> sinzui: that may be, still makes it horrible to know if juju is good or not
[01:37] <sinzui> wallyworld, the functional tests that failed do have working stable and devel jujus. The only change I made to the functional tests was to extend the timeout
[01:38] <waigani> thumper: the test name is out of date - I started with testing s.Factory.MakeAnyUser(), but the root, it seems, is in s.State,AddUser which is storing DateCreated with a local location
[01:38] <wallyworld> sinzui: you talking about the "functional-*" jobs?
[01:38] <sinzui> yes
[01:39] <wallyworld> so they're all red right now except for one
[01:39] <wallyworld> i guess that's with the smaller timeout
[01:39] <waigani> thumper: do you want to pair?
[01:40] <thumper> waigani: actually, what is your problem?
[01:40] <thumper> yeah
[01:40] <thumper> hangout
[01:40] <thumper> waigani: start one
[01:41] <davecheney> omg, state has it's own version of names.ParseTag
[01:41] <davecheney>         for _, name := range bad {
[01:41] <davecheney>                 c.Logf(name)
[01:41] <davecheney>                 coll, id, err := state.ParseTag(s.State, name)
[01:41] <davecheney>                 c.Check(coll, gc.Equals, "")
[01:41] <davecheney>                 c.Check(id, gc.Equals, "")
[01:41] <davecheney>                 c.Assert(err, gc.ErrorMatches, `".*" is not a valid( [a-z]+)? tag`)
[01:41] <davecheney>         }
[01:41] <davecheney> which has IDENTICAL FUNCTIONALITY
[01:41] <waigani> thumper: https://plus.google.com/hangouts/_/gwtpvhcmdtc52fcnhi4c2bmglya?hl=en
[01:42] <thumper> davecheney: colour me unsurprised
[01:42]  * davecheney is running out of furnature to throw
[01:42] <davecheney> this will be the next victim once I get this PR proposed
[01:43] <davecheney> coll, id, err := state.ParseTag(s.State, m.Tag().String())
[01:43] <davecheney> this function takes a tag, as a string, and parses it into it's kind and its id
[01:43] <davecheney> m is a machine
[01:44] <davecheney> where does m.Tag() get the string it returns from ?
[01:44] <davecheney> by calling NewMachineTag(m.tag)
[01:44] <davecheney> where m.tag is the string versino of the tag without the prefix
[01:44] <davecheney> so all that nonsense is just to get the value of m.tag
[01:45] <davecheney> and you know what the collection is, because you passed in a machine
[01:45] <davecheney> so clearly it's the machines collection ...
[01:53] <sinzui> wallyworld, http://juju-ci.vapour.ws:8080/job/hp-deploy-precise-amd64/ is a first time pass. My tuning the the env and extra cleanup of HP has had a positive affect.
[01:53] <wallyworld> \o/ well done!
[01:56] <sinzui> ha ha canonistack passes when I serve streams from other clouds
[01:56]  * sinzui needs to file an rt tomorrow
[01:59] <sinzui> I wrote a script last Friday to delete 10 terabytes of disk files left on Azure.
[02:05]  * davecheney shrieks
[02:12] <thumper> rick_h_: around?
[02:12] <rick_h_> thumper: hanging in there
[02:12] <thumper> rick_h_: wanna hang with me?
[02:12] <rick_h_> sounds like a party
[02:12] <rick_h_> your link or mine?
[02:12] <thumper> https://plus.google.com/hangouts/_/gtnotdg6x5r34ae6zuuwuenssia?hl=en
[02:17] <axw> wallyworld: can we have an "investigating" section under Doing in leankit?
[02:17] <wallyworld> sure, sounds reasonable
[02:19] <wallyworld> axw: done
[02:19] <axw> wallyworld: thanks
[02:20] <waigani> thumper: okay got it, you needed to return a pointer reference in order to be able to return a nil
[02:42] <jcw4> davecheney: yep I stumbled across that today... I thought maybe it was a legacy of when the code was organized differently
[02:43] <davecheney> jcw4: it's on my shit list
[02:45] <jcw4> let me know if there's any grunt work you want me to do on that
[02:45] <jcw4> davecheney:
[02:47] <davecheney> jcw4: you can review my branch in an hour or so
[02:47] <jcw4> davecheney: will do
[02:47] <davecheney> basically i'm starting at state and working outwards
[02:47] <jcw4> yes, I have a pending PR that touches some of that too
[02:48] <davecheney> urgh
[02:48] <davecheney> in state
[02:48] <davecheney> or the api we have a thing called params.Entity
[02:48] <davecheney> and an entity has a tag
[02:48] <davecheney> why _isnt_ it a Tag
[02:48] <davecheney> ?!?
[02:48] <jcw4> You mean the Tag() that returns string :)
[02:49] <davecheney> jcw4: that is also on my shit list
[02:49] <jcw4> sweet
[02:57] <bodie_> https://github.com/juju/juju/pull/118
[02:57] <bodie_> Actions as a Hook in uniter
[02:57] <bodie_> pretty simple
[03:29] <jcw4> Addressed comments by wallyworld, PTAL https://github.com/juju/juju/pull/116
[03:30] <wallyworld> jcw4: will do, thanks. i marked the previous version as LGTM as I trusted you to make the changes. i'll take another look though :-)
[03:30] <jcw4> Oh, right... thanks and then I'll $$merge$$ it after you look.
[03:31] <sinzui> I have procs and files left behind from a manual provisioning test. There is no juju or juju-mongodb running, but I cannot provision the machine. What can I delete
[03:31] <sinzui> juju-db.conf
[03:31] <sinzui> 10.245.67.135 is already provisioned ["juju-db.conf\njujud-machine-0.conf"]
[03:35] <wallyworld> axw: ^^^^^^^^^^^^^^^
[03:35] <wallyworld> jcw4: tests look much nicer, thanks for splitting them up
[03:36] <wallyworld> sinzui: axw is working on that bug now
[03:36] <jcw4> wallyworld: my pleasure tx
[03:56] <axw> sinzui: weird, I couldn't repro. do you have steps to?
[03:57] <sinzui> axw Not really. CI seems to be doing for the ppc manual tests
[03:57] <sinzui> http://juju-ci.vapour.ws:8080/job/manual-deploy-trusty-ppc64-devel/
[03:58] <sinzui> axw, I found jujud amd juju-mongod running on that machine and the failure. I deleted /var/lib/juju then killed the procs
[03:59]  * sinzui doesn't know any other way to clean up after a failed provisioning
[03:59] <sinzui> axw, I have had lots of failed provisioning on these machines because of egress access to download the tools and charms. IS fixed the egress access today
[04:00] <sinzui> axw, ssh as jenkins@10.245.67.135
[04:00] <axw> ta
[04:01] <sinzui> axw export JUJU_HOME=~/cloud-city/
[04:01] <sinzui> juju switch kvm-local-trusty
[04:01]  * sinzui thinks
[04:02] <sinzui> oh, axw , I have everything garbled
[04:03] <sinzui> jenkins@10.245.67.134 is bootstrapping 10.245.67.135 with the  manual-trusty env
[04:03] <axw> ok
[04:04] <sinzui> axw, the staging key will get you in to look at the evidence
[04:06] <axw> sinzui: FWIW, the right way to clean up a machine is "sudo killall -SIGABRT jujud"
[04:08]  * sinzui pastes that into notes
[04:18] <davecheney> https://github.com/juju/juju/pull/119
[04:18] <davecheney> wow
[04:18] <davecheney> sorry for the massive changeset
[04:22] <axw> sinzui: also, "destroy-environment --force" will not terminate manually provisioned machine agents
[04:22] <axw> (apart from the bootstrap one)
[04:22] <sinzui> oh, then
[04:22] <sinzui> I will need to add something to cleanup between tests
[04:22] <axw> sinzui: manual should always do destroy-environment without --force to be safe
[04:23] <axw> otherwise killall
[04:23] <axw> yeah, I think that's safest
[04:23] <axw> killall -SIGABRT jujud and then wait until it's gone
[04:25] <jcw4> davecheney: my pull request that just went in may need a little work to get the same refactor applied
[04:26] <jcw4> davecheney: since my pr already landed it may have to be merged in your pr :-/
[04:32] <jam> mgz: ping when you're around
[05:07] <davecheney> jcw4: no worries
[05:07] <davecheney> 'tis but a small matter of typing
[05:08] <jcw4> davecheney: hehe, but you only have so many keystrokes in your lifetime...
[05:09] <davecheney> jcw4: thanks, thanks for that thought
[05:09]  * davecheney prepares his resignation
[05:09] <jcw4> >:-}
[05:42] <davecheney> jcw4: thanks for the review
[05:42] <davecheney> what TZ are you in ?
[05:46] <jcw4> davecheney: US West Coast... UTC -7 right now
[05:46] <davecheney> o/
[05:46] <jcw4> \o
[05:47] <jcw4> Its a fun timezone, I get to hang out with the cool kids down under and in Europe
[05:48] <davecheney> \( ﾟ◡ﾟ)/
[05:48] <davecheney> i'm not child
[05:48] <davecheney> i just act like one online
[05:48] <jcw4> haha
[05:48] <jcw4> me either/too
[05:49] <jcw4> davecheney: you in NZ / AU ?
[05:49] <davecheney> AU
[05:49] <jcw4> cool
[05:59] <davecheney> go, tests, go !
[06:01] <jcw4> if you're really compulsive like me you have the console output of the CI on your screen
[06:04] <davecheney> same
[06:04] <davecheney> the job's not done til finished: SUCCESS
[06:05] <davecheney> now to address some of those TODOs
[06:15] <davecheney> i gotta get a faster machine
[06:15] <davecheney> this branch has taken too long because of how long it takes to run/fix/run/fix/run/fix the tests
[06:17] <davecheney> and before anyone mentions the cloud
[06:17] <davecheney> this 2 year old x220 laptop is _faster_ than anything aws has to offer
[06:18] <davecheney> and I have graphs to prove it
[06:44] <davecheney> https://github.com/juju/juju/pull/120
[06:44] <davecheney> one more before i sign off
[07:08] <bigjools> jam1: your email about git diffs has (probably unintentionally) made me laugh a lot
[07:09] <bigjools> or are you jam2 today...
[07:09] <jam2> bigjools: probably jam2 by accident
[07:09] <jam> there we go
[07:10] <jam> bigjools: I can certainly appreciate the humor.
[07:11] <bigjools> jam1: I know this particular horse has been flogged to death already, but that was just hilarious
[07:39] <voidspace> morning all
[07:39] <voidspace> jam: wallyworld: thanks for the reviews guys
[07:39] <jam> voidspace: happy to help
[07:39] <voidspace> jam: wallyworld: one point I disagree with
[07:39] <jam> hopefully its useful feedabck
[07:39] <voidspace> jam: yep, good stuff
[07:40] <voidspace> especially moving the code out of the ServeHTTP method and restructuring
[07:40] <voidspace> discussion of headers etc
[07:40] <voidspace> jam: wallyworld: on moving the asserts into the "mockBackup" function
[07:40] <voidspace> jam: wallyworld: I actually really dislike that
[07:41] <voidspace> jam: wallyworld: I think it's much cleaner to have that function do the setup work / store the information about how it was called
[07:41] <voidspace> and keep the asserts inside the body of the test method
[07:42] <voidspace> if the issue is storing the parameters on the test suite I can provide another object to store them on and avoid polluting the suite
[07:43] <voidspace> plus, state.Info() seems fine to me as a name (returning a state.Info). state.StateInfo() seems a bit redundant :-)
[07:43] <TheMue> morning
[07:43] <voidspace> I'll add these as comments for further discussion on the PR
[07:44] <TheMue> dimitern: happy birthday
[07:45] <jam> voidspace: StateInfo isn't what I'd use, but IIRC ian was asking for MongoConnectionDetails or something significantly more descriptive.
[07:45] <jam> voidspace: I don't think we want to use suite level attributes as they cross contaminate tests
[07:46] <jam> (the suite object is shared between all testts, which is how SetUpSuite can maintain its state)
[07:46] <voidspace> jam: oh, yuck
[07:46] <jam> voidspace: I'm personally fine with asserts in functions that are defined inside that test
[07:47] <jam> voidspace: arguably the "right" way is to create a struct type, and a channel, call the body, in the body have it push the updated info out the channel, and read in from the channel in the rest of the test
[07:47] <voidspace> jam: I prefer the pattern: call the code under test, then assert about how it behaved.
[07:47] <jam> then it is asynchronous safe as well
[07:48] <voidspace> heh
[07:49] <voidspace> it's not asynchronous safe because of the patched module
[07:49] <voidspace> at least in the sense that we can't parallelise the tests when we use PatchValue
[07:49] <jam> voidspace: well once you've done the patching ,you can then call "go Backup()" and there isn't a race.
[07:49] <jam> but no
[07:49] <jam> we can't parrallelise 75+% of our tests
[07:50] <voidspace> I could push a struct into a channel, it's slightly unnecessary complexity but I like it conceptually
[07:50] <jam> voidspace: it isn't terrible to just have a var struct if you prefer that to the complexity of a channel
[07:50] <jam> so "var data struct {backupName string; mongoPort int; ...}
[07:50] <jam> data.backupName = backupName
[07:51] <voidspace> yep
[07:51] <voidspace> thanks, I'll get on those fixes
[07:52] <jam> voidspace: its certainly better than the "data = []" tricks I did in python because of local vs global vs notlocal scoping
[07:53] <jam> voidspace: IIRC nonlocal fit the use case, but wasn't available in the versions of python we were supporting.
[08:19] <dimitern> TheMue, thanks! :)
[08:25] <voidspace> jam: yeah, nonlocal solves exactly that problem
[08:56] <wallyworld> voidspace: hi, sorry, my car broke down when i was getting my kid from school. had to wait for tow truvk etc, back now. that pattern i suggested is what we use everywhere else. it asserts the values passed into the function are as expected and makes more sense to me
[08:57] <wallyworld> mgz: axw ok for standup now if you guys are free
[08:58] <voidspace> wallyworld: hey, we get to sprint with you guys in Lexington
[08:58] <wallyworld> \o/
[08:58] <voidspace> wallyworld: which is cool
[08:58] <wallyworld> very cool
[08:59] <voidspace> wallyworld: do we have offices there?
[08:59] <wallyworld> yes
[08:59] <wallyworld> i'm told lexington is a hole though
[08:59] <voidspace> right, makes sense
[08:59] <voidspace> heh
[08:59] <axw> wallyworld: heya. can you give me 5-10 please? wasn't expecting you back, need to get my daughter dinner
[08:59] <voidspace> it's not far from Boston though
[08:59] <wallyworld> middle of nowhere, nothing to do
[08:59] <wallyworld> no gun ranges
[08:59] <axw> lol
[08:59] <voidspace> wallyworld: the Boston Python user group (biggest user group in the USA) is on Monday
[08:59] <voidspace> wallyworld: ned batchelder and crew - it would be good if we can make it
[09:00] <wallyworld> axw: sure, i may be eating myself, but we'll sync up i'm sure
[09:00] <TheMue> what’s the current status of the lexington sprint?
[09:00] <wallyworld> voidspace: +1 to that
[09:00] <voidspace> TheMue: it's been approved
[09:01] <voidspace> TheMue: it's natefinch's team and wallyworld's team
[09:01] <TheMue> voidspace: ok
[09:02] <TheMue> voidspace: alexisb also asked who else of the other teams will join
[09:03] <voidspace> TheMue: I didn't see anyone else on the sprint list
[09:04] <TheMue> voidspace: ah, so maybe this plan changed
[09:09] <mgz> wallyworld: no one in the standup?
[09:12] <axw> mgz: wallyworld is having some dinner, he'll ping in a bit
[09:12] <mgz> k
[09:17] <wallyworld> mgz: axw: there now
[09:18] <perrito666> morning
[09:33] <jam> dimitern: thanks for the review. I believe I've responded to all your requests if you want to refresh https://github.com/jameinel/juju/pull/1
[09:34]  * menn0 is back for more...
[09:34] <dimitern> jam, cheers, i've reviewed it again, still LGTM
[09:35] <jam> great. I plan on just merging the last of the series, once we've gone through them all.
[09:35] <jam> thanks for starting on the next one.
[09:35] <jam> menn0: run, run while you still can ! :)
[09:36] <menn0> jam: it's ok... I had a lot of distractions today so am catching up now
[09:37] <dimitern> jam, next one is lgtm as well
[09:38] <jam> menn0:  you don't understand… its not safe for you here… dimiter…. oh my god, dimiter. He's reviewing all the code… he's.. reviewing… *all*… the code…. *sob*
[09:38] <jam> thanks dimitern
[09:38] <menn0> LOL!
[09:54] <dimitern> jam, last one reviewed as well
[09:59] <dimitern> fwereade, are you around?
[10:01] <dimitern> fwereade, when you can spare some time, i'd really like you to review the networking model doc https://docs.google.com/a/canonical.com/document/d/16SYAlZFc19YPXrB7BRwufZVoeLFpqGzBTAdo4EoQIHg/
[10:02] <jam> dimitern: fwereade said earlier that he isn't feeling very well today, so he may be in and out a bit
[10:03] <jam> I still need to finish looking at that doc as well.
[10:03] <jam> dimitern: I responded to the idea about FacadeVersions.
[10:03] <jam> my personal opinion is that a map is not a structure for the API itself.
[10:04] <dimitern> jam, ah, right ok
[10:04] <dimitern> jam, why?
[10:05] <jam> dimitern: it seems odd to me that the textual byte stream requires that results must be parsed into a dict
[10:05] <jam> yes that is what we actually do with it once we've gotten it
[10:05] <jam> but it doesn't seem like the stream of data itself is a map
[10:06] <dimitern> jam, i'm a bit thick today is seems :/ what's the byte stream textual rep has to do with it? :)
[10:07] <jam> dimitern: so the API returns data on the wire, which we then read, right?
[10:07] <dimitern> jam, it is essentially a map name-to-versions, right?
[10:07] <dimitern> jam, yep
[10:07] <jam> It seems odd to me that you would require that to be a JSON object type, rather than a list type.
[10:07] <dimitern> jam, if it's an actual map, we can do fast lookups with the results directly, no need for helper methods
[10:07] <jam> We do use it as a dict type
[10:08] <jam> dimitern: well, the first thing we do is put it into a map for storing, but that is just iterating the result and storing it.
[10:08] <dimitern> jam, it's not a dict per se, it's an object
[10:09] <dimitern> jam, right, but if that's something we need to do all the time on the client it seems sub-optimal
[10:09] <jam> dimitern: well it is being done anyway regardless of whether it is explicit or implicit
[10:09] <dimitern> jam, i.e. if the most common operation on these results will be "what versions has the facade named Foo?"
[10:10] <jam> dimitern: well, I liked that it was a sorted list, fwiw
[10:10] <jam> which you can't easily code into a map structure.
[10:10] <dimitern> jam, wait a sec :)
[10:10] <jam> dimitern: FacadeRegistry.List() returns a sorted list of the versions
[10:11] <dimitern> jam, are we talking about the same things here? I mean the FacadeVersions slice, not the Versions slice inside it - the latter will be sorted still if []FacadeVersions becomes FacadeVersionsMap
[10:12] <dimitern> jam, the only thing we'll lose with a map is the keys can't be sorted
[10:12] <jam> dimitern: it is a sorrted list of names each containing sorted versions.
[10:13] <dimitern> jam, so the names being sorted as well is nice, but doesn't contribute much (except for displaying them perhaps, which can be done with sorting), and makes lookups harder
[10:14] <jam> and putting that *into* a map is a rather trivial loop which is exactly what is done in line 48 of state/apiserver/state.go where you commented about us sorting the version ints.
[10:14] <wallyworld> jam: any chance of a review? https://github.com/juju/charm/pull/6 fixes critical 1.19.4 bug 1330919
[10:14] <_mup_> Bug #1330919: local charm deployment fails with symlinks <charms> <regression> <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1330919>
[10:14] <wallyworld> or fwereade
[10:15] <jam> wallyworld: fwereade is mostly out sick today, I'll give it a look
[10:15] <wallyworld> ok, thanks, whenever you are free
[10:16] <jam> wallyworld: should we be checking that the target is inside the REPOSITORY ?
[10:16] <jam> I'm generally hesitant about just letting symlinks point anywhere
[10:16] <wallyworld> jam: hmmm. i could do
[10:16] <wallyworld> i guess i never figured it mattered
[10:16] <jam> wallyworld: I'm not *positive* about it, since maybe its ok
[10:17] <jam> but I'd like us to *think* about it first
[10:17] <jam> wallyworld: would we want to just use "filepath.EvalSymlinks" ?
[10:17] <jam> http://golang.org/pkg/path/filepath/#EvalSymlinks
[10:18] <wallyworld> probably, i'm not very familaiar with those api calls
[10:18] <wallyworld> i can tweak it
[10:19] <wallyworld> jam: inside the dir.go code, i don't think we even know what REPOSITORY is
[10:19] <wallyworld> so i guess any check would have to be external to that
[10:21] <jam> wallyworld: sure. as for EvalSymlinks, I just mean we can potentially replace the resolveSymlinkRoot entirely with just rootPath, err := filepath.EvalSymlinks(rootPath)
[10:22] <jam> technically it resolves any symlink anywhere along the path, but I don't think that is a problem for us.
[10:22] <jam> and it means less code we have to write/maintaine
[10:22] <wallyworld> jam: yeah, just tried, that, test failed. but i'll make it work
[10:23] <wallyworld> jam: also, we seem to have a plethora of these new juju repos. the new lander just does juju/juju. tarmac doesn't handle them either i don't expect
[10:23] <wallyworld> looking at previous pr's, it seems people landed by hand perhaps
[10:24] <jam> wallyworld: thats my guess
[10:24] <jam> we *should* have them all under the bot,but people who have been pulling stuff out of Juju haven't been diligent about it
[10:24] <jam> at least IMO
[10:24] <wallyworld> yep, +1. that was my thought too, just wanted to check
[10:24] <natefinch> MOrning all
[10:25] <jam> well, maybe in your opinion as well :)
[10:25] <jam> morning natefinch
[10:26] <voidspace> natefinch: morning
[10:31] <dimitern> jam, ok, still LGTM though, I'd rather have this landed, we can refactor it later if need be
[10:32] <jam> dimitern: can you LGTM the juju/juju pr?
[10:32] <jam> https://github.com/juju/juju/pull/100
[10:37] <stub> wallyworld: (as the bug reporter) I think symlinks should be followed in the repository blindly, but symlinks in the charm should be contained within the charm. It is interesting currently that $JUJU_REPO/precise can be a symlink but $JUJU_REPO/precise/foo cannot (fails per bug report)
[10:37] <wallyworld> stub: yeah, that's how i've done the fix
[10:39] <dimitern> jam, done
[10:43] <jam> dimitern: thanks, I'll go look at the networking doc now
[10:50] <dimitern> jam, TheMue, standup?
[10:51] <TheMue> ouch, yes, comming
[11:18] <wallyworld> stub: that bug is fix committed; if you run from source you can try it out. be sure to get the latest juju/charm code as well as juju/juju
[11:18] <stub> ta
[11:21] <mgz> wallyworld: it's just on the bundling up side right, so no faffing with uploading alternative tools to test?
[11:22] <vladk> dimitern: please, take a look https://github.com/juju/juju/pull/121
[11:22] <wallyworld> mgz: yup
[11:22] <wallyworld> mgz: i think so
[11:22] <wallyworld> or hangon
[11:22] <wallyworld> no
[11:23] <wallyworld> i think you may need new tools too, not sure
[11:23] <wallyworld> i did test and seem to recall i needed to redo the tools
[11:23] <wallyworld> could be wrong
[11:58] <jam> yay, it has finally landed !!
[12:28] <jam> vladk: while you are waiting for dimitern's review of your work, it would probably be helpful to have you look over his networking document: https://docs.google.com/a/canonical.com/document/d/16SYAlZFc19YPXrB7BRwufZVoeLFpqGzBTAdo4EoQIHg/edit?disco=AAAAAJrgVD8#heading=h.8afzt9469s6q
[12:30] <dimitern> vladk, you've got a review, ping me if you have questions please
[12:32]  * perrito666 notices travel agency got something wrong and is trying to send him to london
[12:42] <perrito666> jam: you should also look into gitk/gitg which makes git trees navigation a lot less painful
[12:42]  * perrito666 answers mails via irc, brain wires crossed
[12:42] <jam> perrito666: it still doesn't handle my diff problem well, as they do the equivalent of "git show"
[12:42] <jam> I have tried
[12:42] <jam> I've also tried Atlantassian's SourceTree
[12:43] <perrito666> jam: mm, I thought they had more features
[12:43] <jam> which is pretty nice, but doesn't do what I want
[12:43] <jam> perrito666: so you *can* select a range, and eventually get what you want, but it is clumsy
[12:43] <jam> the default of just selecting a rev shows you the equivalent of "git show"
[12:53] <perrito666> ok, syntax highlight in the comments is nice
[12:57] <mfoord> damn internet connection
[12:58] <perrito666> mfoord: again?
[12:58] <mfoord> perrito666: still
[12:58] <mfoord> perrito666: my line has degraded to 1.6mb downstream
[12:58] <mfoord> perrito666: I haven't sorted it yet
[12:58] <mfoord> perrito666: got on the case a bit this morning - but of course tech support from my isp is awful
[12:59] <mfoord> anyway
[12:59]  * mfoord lunches
[13:40] <wwitzel3> natefinch: oops, just looked at the clock
[13:40] <wwitzel3> natefinch: hopefully you forgot too ;)
[13:56] <natefinch> wwitzel3: yeah, was busy helping with the kids, forgot we had a new meeting this morning
[13:57] <natefinch> wwitzel3: we can do it after the standup
[13:58] <ericsnow> natefinch, wwitzel3: standup in an hour, right?
[13:58] <wwitzel3> ericsnow: correct
[13:59] <natefinch> ericsnow: yep
[14:04] <bodie_> morning all
[14:06] <jcw4> morning bodie_
[15:00] <natefinch> wwitzel3, ericsnow, voidspace, perrito666: the TOSCA meeting is running over, so we will need to move the standup back about half an hour
[15:00] <perrito666> natefinch: ok
[15:22] <tasdomas> I'm having a little trouble understanding the relation between state/api, state/apiserver and state/apiserver/client in juju
[15:35] <jcw4> tasdomas: me too; I think the doc/api.txt file may help some but I'm a little fuzzy about that myself
[15:35] <voidspace> yay, internet back
[15:35] <voidspace> for now anyway :-/
[15:35] <voidspace> I *really* need a dongle
[15:35] <voidspace> I also need the time to go and buy one
[15:36] <voidspace> maybe tomorrow during the day as I can work late tomorrow
[15:36] <wwitzel3> if only there was some way you could just order one online and it would arrive at your home
[15:36] <voidspace> wwitzel3: yeah, because telecoms company don't *deliberately* make that shit confusing to buy online
[15:36] <ericsnow> wwitzel3, voidspace: :)
[15:36] <wwitzel3> voidspace: good point :)
[15:36] <voidspace> wwitzel3: plus, if I order it today it will probably arrive just after we've left for France on Saturday morrning
[15:37] <voidspace> wwitzel3: I did look online and the contract details available were either "too short to be useful" or "too long to be humanly possible to read"
[15:39] <wwitzel3> perrito666, natefinch: standup?
[15:39] <wwitzel3> voidspace: I guess you too :P
[15:39] <voidspace> heh, ok
[15:45] <natefinch> yep
[15:49] <voidspace> jam: wallyworld: I've pushed changes to the backup-download PR
[15:49] <voidspace> https://github.com/juju/juju/pull/114/files
[15:55] <voidspace> ah, now I have internet I see I got an LGTM
[15:55] <voidspace> wallyworld: thanks!
[15:55] <jcw4> voidspace: internet is such a sweet thing
[15:55] <voidspace> jcw4: heh, it certainly is :-)
[15:57] <tasdomas> where does state/apiserver/client fit into the go stack described in doc/api.txt ?
[16:00] <jcw4> fwereade: ^^ (or anyone else with state knowledge since I believe fwereade is under the weather today)
[16:09] <mgz> tasdomas: it's the api server side for client-oriented api calls
[16:10] <mgz> doc/api.txt is all future-tense - I don;t think it's ever been updated from when the api actually got implemented, so probably isn't as clear as it could be
[16:10] <tasdomas> mgz, and state/api is the client-side api end-point?
[16:10] <mgz> yup, that's it
[16:17] <tasdomas> mgz, I don't see any tests that call the state/apiserver/client calls directly (they seem to all test that via state/api) - am I missing something?
[16:19] <mgz> tasdomas: the client package there is a little different to all the other apiserver bits, they get tested through the client side only, not at both end
[16:21] <tasdomas> mgz, right - that makes things a bit clearer, thanks
[16:21] <tasdomas> mgz, a testing-related question, if I can bother you with it
[16:22] <tasdomas> mgz, in https://github.com/juju/juju/pull/115 I modify the EnsureAvailability call to make it a bulk API call
[16:23] <perrito666> lunch bbl
[16:23] <tasdomas> mgz, is there a way to patch the EnvironTag value in the state in state/api ?
[16:24] <tasdomas> mgz, I want to add a test that sends an incorrect environment tag, but since it's a private state property, I think it's not patchable
[16:29] <mgz> tasdomas: can you not do it via state/conn_test.go ? that has some ability to do fiddling under the coversd
[16:29] <mgz> dimitern may have better ideas on how you want to check that something is a bulk call, if he's around
[16:30] <tasdomas> mgz, thanks - I'll pick it up with dimitern tomorrow then (EOD)
[16:36] <jam1> tasdomas: api.Open takes an api.Info object which specifies the EnvironTag to pass
[16:37] <jam1> though Open should fail if you pass an invalid one
[16:37] <jam1> you're trying to override it after the fact?
[16:37] <jam1> tasdomas: if its a state/api test, you could put a helper in state/api/export_test that let you explicitly poke at the internals
[17:02]  * natefinch is finally having breakfast
[17:02] <jcw4> natefinch: you on the west coast today?
[17:02] <jcw4> ;)
[17:02] <natefinch> heh nope.  Just busy morning
[17:03] <perrito666> man I wish I understood flight reservation sofware encoding
[17:04] <jcw4> software encoding?
[17:06] <natefinch> The second best thing about having a sprint nearby is not having to do reservations and all that BS
[17:08] <perrito666> jcw4: they use this very old console soft
[17:08] <perrito666> like almost serial printer console old
[17:08] <jcw4> yeah?
[17:08] <perrito666> and each line of information is a fixed width columns set
[17:09] <perrito666> so, you get things like this as a result
[17:09] <perrito666> 1  *LA2422  H  05JUL  COR  LIM   0455  0700   E0/320
[17:09] <perrito666> now, I understand most of it :p
[17:09] <perrito666> but the * in front of LA is amistery
[17:09] <perrito666> the H too
[17:09] <jcw4> I think it means you're on a TSA watchlist
[17:09] <perrito666> and the ocasional numbers in a column that is not there is also a mistery
[17:10] <jcw4> I'm always interested in those codes too... they sometimes give information that isn't published anywhere else
[17:11] <perrito666> jcw4: I am mostly interested because I am trying to decipher if I want or not that flight
[17:11] <perrito666> jcw4: you can make a tourism operator course, they teach you to use that thing
[17:12] <natefinch> can't you just use kayak.com like everyone else? :)
[17:12] <perrito666> everything about tourism is so 80s
[17:12] <jcw4> haha
[17:12] <perrito666> I use despegar.com
[17:12] <perrito666> natefinch: but this is the email sent to me by the tourism guys :) which assume I also did the software course
[17:13] <perrito666> same happens to me when I go to a travel agency for vacations, they print me this monospaced font paper and give it to me :p
[17:14] <jcw4> perrito666: well, good luck with that.
[17:16] <natefinch> perrito666: just look up the flight number online
[17:17] <perrito666> natefinch: yup did that, seems normal :p
[17:25] <voidspace> natefinch: I've found out that they're tinkering with the internet connection for the village
[17:25] <voidspace> natefinch: adding "new boxes", so it will be ropey for at least another week
[17:26] <voidspace> natefinch: and then hopefully better
[17:26] <voidspace> natefinch: but I'm away next week *anyway*
[17:26] <voidspace> natefinch: so hopefully all good when I get back
[17:26] <voidspace> good to have an answer anyway
[17:29] <ericsnow> voidspace: yay
[17:29] <ericsnow> voidspace: it wasn't my fault ;)
[17:30] <voidspace> ericsnow: hah, I'm sure karmically it's still your fault somehow...
[17:30] <ericsnow> voidspace: no doubt :)
[17:33] <natefinch> voidspace: yeah, nice to know why it's happening, and nice to know it'll be done eventually
[17:34] <voidspace> yep
[17:34] <perrito666> voidspace: they are changing the 6eths switch for an 8eths one :p
[17:36] <voidspace> perrito666: I don't know what that means
[17:36] <voidspace> but it sounds good
[17:37] <perrito666> voidspace: I was implying that the internet of your whole village was held by a 6port switch :p
[17:37] <voidspace> perrito666: heh, I doubt we even get six...
[17:38] <perrito666> when I moved to my current city (capital of this state) one of the largest providers of dsl had such bad config that we where on a LAN I could fetch things from the shared MyDocuments folders from every other client on my subnet
[17:56] <perrito666> sinzui: any luck running in another provider?
[17:58] <sinzui> perrito666, I just got more RAM for HP. I will move the functional-ha-backup-restore to HP and hope for a pass
[17:58] <perrito666> sinzui: I am having hell running on ec2
[17:58] <sinzui> perrito666, I think trusty is more brittle than precise on ec2
[17:59] <sinzui> I moved those tests back to precise
[17:59] <perrito666> I get a machine to create the state machine but it blows when trying to create the cs:ubuntu one
[18:01] <voidspace> right, BBQ time!
[18:01] <voidspace> EOD
[18:01] <voidspace> g'night all - see you tomorrow
[18:01] <natefinch> night voidspace
[18:02] <perrito666> nite voidspace
[18:02] <voidspace> o/
[18:06] <sinzui> perrito666, CI isabout 2.5 hour from running the failing test with tip. I started a run against hp with the last commit from a few hours http://juju-ci.vapour.ws:8080/job/functional-ha-backup-restore/168/console
[18:12] <perrito666> Ill go do some biking to cool off my head then see if I can finally crack this issue
[18:13] <natefinch> perrito666: good luck
[19:05] <natefinch> ericsnow: just catching up on email... about the CLI for restore... it sounds like the question is basically whether or not you have to juju bootstrap before you can call juju restore.  Is that a correct summary?
[19:06] <natefinch> ericsnow: or were you thinking something like juju bootstrap, juju upload-backup, juju restore?
[19:07] <ericsnow> natefinch: I'm not sure what the use case is for more than one command
[19:07] <ericsnow> natefinch: I was talking more about the API client side of things
[19:07] <natefinch> ericsnow: ahh
[19:08] <natefinch> ericsnow: it seems like all we really need is an http API called "Restore" that can take a file.  If it can restore, it does.  If it can't it says so.
[19:09] <ericsnow> natefinch: that makes sense to me for the immediate term
[19:09] <ericsnow> natefinch: and it may be all we need long-term too :)
[19:09] <natefinch> ericsnow: YAGNI :)
[19:09] <ericsnow> natefinch: exactly!
[19:10] <sparkiegeek> if I have two units of the same subordinate service "hulk-smashed" onto a single machine, will I get hooks being run concurrently? (e.g. unit/0 hookX and unit/1 hookX being run at the same time)?
[19:10] <sparkiegeek> or does juju guarantee that they'll be serialised
[19:11] <natefinch> sparkiegeek: juju guarantees nothing if you have hulk smashed
[19:11] <sparkiegeek> natefinch: so two agents = operate independently?
[19:12] <natefinch> sparkiegeek: that being said, I'm not sure of the current behavior right now, it's possible they'll be serialized.
[19:12] <ericsnow> natefinch: nice :)
[19:12] <sparkiegeek> natefinch: anecdotal evidence suggests they *are* but I'm trying to hunt down a race condition which might be caused if they're not :)
[19:13] <sparkiegeek> (1.19.3 FWIW)
[19:25] <natefinch> marcoceppi: do you know if two units of the same subordinate service will have their hooks serialized?  or is it possible they'll get run at the same time?  I don't actually know how hooks are serialized?
[19:25] <natefinch> sorry... ^^ if they are hulk smashed on the same machine
[19:26] <marcoceppi> wow, hulk smashing the same subordinate on a machine twice, sounds like someone is asking for it
[19:26] <natefinch> basically what I said
[19:26] <marcoceppi> natefinch: afaik, it's serialized at the unit level, not the service level, so you could probably have two hooks on a unit running simultaneously
[19:27] <marcoceppi> I'd totally chaulk this up to "it's working as designed and you're wrong"
[19:31] <sparkiegeek> marcoceppi: FWIW I was asking what the design/behaviour was, not for a change :P
[19:32] <marcoceppi> well, this is my understanding, I've not confirmed this
[19:32] <marcoceppi> but it should jsut follow normal unit event dispatching, there's no special case for juju and events esp wrt hulksmashing
[19:33] <marcoceppi> I should also mention IANACD
[19:33] <natefinch> haha
[19:33] <sparkiegeek> marcoceppi: noted :)
[19:33] <sparkiegeek> it *seems* like events are serialised
[19:34] <sparkiegeek> I was hoping to shortcut lots of testing by asking you guys :)
[19:35] <marcoceppi> I'm under the impression they are serialized on a single unit basis and not nessiarily per service. I could be completely wrong though
[19:42] <sparkiegeek> marcoceppi: thanks. That was my assumption too but logs suggest that they are serialised. Ho hum
[19:45] <sinzui> natefinch, We have a ppc64el/gccgo regression https://bugs.launchpad.net/juju-core/+bug/1331744
[19:45] <_mup_> Bug #1331744: panic: reflect: Call of unexported method ppc64el/gccgo unit tests <ci> <gccgo> <ppc64el> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1331744>
[19:45] <sinzui> ^ we may need to wait for wallyworld or Dave to wake up
[19:50] <natefinch> sinzui: weird
[19:55] <natefinch> sinzui: that is some unfortunately gnarly code
[19:57] <natefinch> jam1 or jam2 will likely have a better understanding of it, I think.
[20:00] <jam2> natefinch: it is likely soemthing funny with the api versioning stuff, but I'm about to fall asleep. I assigned it to myself, but if wallyworld or someone else wakes up to it first, they are welcome to look at it.
[20:01] <natefinch> jam2: ha, yeah, pretty late there.  OK
[20:03] <perrito666> sinzui: back, the build failed for a reason I dont understand
[20:07] <sinzui> perrito666, It failed because HA wasn't achieved in 15 minutes or was it 20 minutes
[20:09] <perrito666> sinzui:  did you see that it marked 3 machines just when it died?
[20:09] <sinzui> I did
[20:10] <sinzui> perrito666, I was going to let CI just play the test with the current build...
[20:10] <perrito666> something interesting I noticed the other day, I sshd into the machine as it was doing the ha sync and the load was on the skyes
[20:11] <sinzui> perrito666, but there is a gccgo problem with the current build...the arm64 builder took 3 hours.
[20:14] <perrito666> man, there is a huge load of bad karma with this issue
[20:16] <sinzui> I am going to reboot the arm64 machine. I had to do that with the ppc64el machine because all the memory and disk was used up
[20:16]  * perrito666 tries to reproduce the test by hand
[20:17] <sinzui> or not. The machine says it is healthy now
[20:17] <sinzui> perrito666, I will run the test again...I want to extend the time to get to HA
[20:18] <perrito666> give it time, I am curious to know if the test goes trough regardless of the lag of HA, to see if I can finally figure out where is the problem
[20:19] <perrito666> I read the commits around the first failures, there is no indication of anything that goes even near restore
[21:01] <perrito666> sinzui: my local test failed, it restored the machine but status reports the old info
[21:04] <sinzui> :/
[21:04] <perrito666> is, as if the mongo query runs but takes no effect
[21:05] <perrito666> but when I go to the shell and do it by hand it works
[21:05] <perrito666> mm strange
[21:07] <ericsnow> perrito666: perhaps a difference in shell environment?
[21:08] <perrito666> yes, that is my current line of thought, mongo's client man page says that there might be differences between what is available to --eval and in the actual shell
[21:08] <perrito666> perhaps there was a version change in mongo that affected us
[21:08] <perrito666> Ill try something
[21:25] <thumper> morning folks
[21:28] <thumper> omg, so many emails...
[21:28]  * thumper needs to get some tweaking on pull request emails.
[21:51] <lifeless> thumper: heh, I read that as twerking on pull request emails
[21:51] <waigani> morning thumper
[21:51] <thumper> lifeless: ha
[21:53] <thumper> morning waigani
[22:00] <mattyw> thumper, morning
[22:23] <alexisb> mattyw, you must be working the late shift
[22:24] <mattyw> alexisb, I'm hoping to grab thumper to ask a couple of questions, I'm going to make up for it tomorrow morning :)
[22:24] <thumper> mattyw: hey, otp with fwereade
[22:24] <alexisb> :)
[22:24] <mattyw> thumper, no problem, ping when you have 5 minutes
[22:35] <perrito666> large threads that include hazmat and fwereade should arrive to my kindle instead of my mailbox :p
[22:36] <fwereade> perrito666, oh, I can get *much* worse if it comes to it ;p
[22:40] <perrito666> aghh juju robustness is biting me
[22:40] <perrito666> I edit out any possible reference to old apiservers from the machine and it comes back
[22:52] <thumper> mattyw: I have 5 minutes
[22:53] <thumper> perrito666: hahaha
[22:53] <mattyw> thumper, ok cool - I'll just type questions then if that's ok?
[22:53] <thumper> sure
[22:54] <mattyw> thumper, the change-password command, at the moment entering an empty password (or just calling juju change-password) will cause a random one to get generated, should I change this to expect the user to input the password, and have a flag for generating a password?
[22:54] <thumper> mattyw: hmm...
[22:54] <thumper> mattyw: to be honest, not quite sure...
[22:55] <thumper> mattyw: I have been spending a lot of time looking at the whole identity vs. user issue
[22:55] <thumper> mattyw: and all the stuff we have now is likely to change :-)
[22:55] <mattyw> thumper, that's fine, change is good
[22:55] <thumper> mattyw: we have two main reasons for change password
[22:55] <thumper> 1) as a user I'd like to change my password to something meaningful to me (or in my lastpass)
[22:56] <thumper> 2) as an admin, I want to reset another user's password
[22:56] <thumper> the problem is right now, everyone is an admin
[22:56] <thumper> as we don't have the permissions in there yet
[22:57] <thumper> so, for 1) we need to think "why is the user asking?"
[22:57] <thumper> perhaps we should always prompt, but accept empty to mean "please generate one for me"
[22:57] <mattyw> having a prompt means the user's password doesn't appear in the bash history - but then again the password is stored in plain text in the jenv anyway
[22:58] <thumper> sure, for now
[22:58] <thumper> I think prompting is the correct approach
[22:59] <mattyw> But my next question was going to be: At the moment the setpassword call in the apiserver only allows you to change the password for the user you're logged in as
[22:59] <thumper> right...
[22:59] <thumper> which doesn't allow use-case 2
[22:59] <mattyw> and I wonder if that's a good approach or not - I will have to change.... - yeah exactly
[22:59] <mattyw> change-password and access-file feel like very similar commands to me
[23:00] <mattyw> thumper, isn't your standup coming up - shall I join it?
[23:00] <thumper> I think... that we should make change-password a bulk call where is specifies a list of users/passwords
[23:00] <thumper> and worry about permissions later
[23:00] <thumper> mattyw: if you like