[00:50] <thumper-lunch> wallyworld: can't use UserHomeDir because I don't have an 'ubuntu' user
[00:50]  * thumper forgot to reset nick
[00:51]  * thumper looks at how to mock differently
[00:51] <wallyworld> you create a fake home dir, add the dir for unbuntu
[00:52] <wallyworld> oh ok
[00:52] <wallyworld> UserHomeDir won't work
[00:52] <thumper> right
[00:52] <thumper> nm, I'll think of something
[00:53] <wallyworld> but NormaliseFile or something like that will
[00:53] <wallyworld> i can't recall exactly
[00:53] <thumper> nah
[00:53] <thumper> normalise calls UserHomeDir
[00:54] <thumper> wallyworld: may mock that out with an interface :-)
[00:54] <thumper> the package call
[00:54] <wallyworld> whatever works :-)
[00:55] <wallyworld> thumper: why not replace /home/ubuntu with NormaliseFile("~/ubuntu")
[00:55] <wallyworld> or something like that
[00:55] <thumper> because that still looks for the ubuntu user
[00:56] <wallyworld> no, the ~ will be replaced
[00:56] <thumper> oh, you mean ~/../ubuntu
[00:56] <wallyworld> by the fake home
[00:56] <thumper> because that's awful
[00:56] <wallyworld> why?
[00:56] <thumper> it is also wrong
[00:56] <thumper> we need it to be /home/ubuntu
[00:56] <thumper> ~/ubuntu -> /root/ubuntu
[00:56] <thumper> by the agent
[00:56] <wallyworld> oh agent runs as different user
[00:57] <thumper> yeah
[00:57] <thumper> if it was the ubuntu user
[00:57] <thumper> it would still be /home/ubuntu/ubuntu
[00:57] <thumper> which is also wrong
[00:57] <thumper> I think you mean ~
[00:57] <wallyworld> sorry, i meant ~unbuntu
[00:57] <thumper> but still wrong
[00:57] <thumper> ~ubuntu looks for the ubuntu user
[00:57] <thumper> I'm going to mock out that looking bit
[00:57] <wallyworld> so why hard code /home/ubuntu - have a helper function and override in tests
[00:58] <thumper> well, we have to mock out one of two things
[00:58] <thumper> either the dir to use
[00:58] <wallyworld> extend the ~ idea which we already handle
[00:58] <thumper> of the thing that maps the dir
[00:58] <wallyworld> the dir to use i reckon is better
[00:58] <thumper> I was going to do the latter
[00:59] <thumper> I have no strong preference
[00:59] <wallyworld> cause we already have the concept of FakeHome, seems like a more natural fit to extend that
[00:59] <wallyworld> to allow for a fake /home
[00:59] <thumper> this will have nothing to do with the home
[00:59] <wallyworld> i mean /home
[01:00] <thumper> it'll just be a dir
[01:00] <wallyworld> yes
[01:00] <thumper> nah, that is getting too complicated
[01:00]  * thumper sticks with easy
[01:00] <wallyworld> i just dislike anything that can touch your real /home
[01:00] <wallyworld> i think that's bad test imppementation
[01:01] <wallyworld> what happens if a test is buggy and it deletes stuff
[01:01] <thumper> we can continue this in the hangout :)
[01:01] <wallyworld> think of stubbing out /home as like stubbing out the charm store url
[01:51] <wallyworld> thumper: pull your finger out cause i need the new agent config stuff on context
[01:51]  * wallyworld taps fingers impatiently
[01:52] <thumper> yeah yeah
[03:37] <_thumper_> wallyworld__: test created for the upgrade
[03:38] <wallyworld__> \o/
[03:38] <_thumper_> proposal being updated now
[03:38]  * _thumper_ has to go make dinner
[03:39] <wallyworld__> ok ta
[03:51] <axw> gtg out for a while, seeing my brother off at the airport
[04:02] <bradm> anyone got any suggestions on how to debug why a juju 1.17.2 environment will bootstrap, but not deploy an instance?
[04:03] <bradm> as in, I'm trying to juju deploy a local charm and its just sitting there
[04:03] <bradm> https://pastebin.canonical.com/104754/ <- been sitting there for a good minute or more
[04:04] <thumper> axw: ack
[04:05] <thumper> bradm: it could be downloading the lxc template
[04:05] <bradm> thumper: this is on a juju deployed openstack using maas
[04:06] <thumper> oh..
[04:06] <thumper> maybe not then...
[04:06] <bradm> thumper: as in, on openstack deployed using juju on top of maas
[04:06] <thumper> sorry, not sure
[04:06] <bradm> I just can't see anything going on
[04:07] <bradm> thumper-afk: no worries
[04:44] <bradm> nobody else has any suggestions for debugging why juju deploy is hanging?
[04:49] <bradm> wallyworld__: ^^ ? :)
[04:50] <wallyworld__> um
[04:50] <wallyworld__> bradm: i've not deployed any local charms before, all i can think of is perhaps an issue uploading the charm to cloud storage
[04:51] <bradm> best I can tell it doesn't matter where the charm comes from, it just hangs
[04:52] <wallyworld__> it still has to copy the charm to cloud storage though
[04:53] <bradm> hmm, I guess
[04:53] <wallyworld__> maybe you can ssh into the machine and see if the charm has been unpacked
[04:53] <bradm> it hasn't spawned a 2nd machine yet, I only have the bootstrap node up
[04:54] <wallyworld__> what does juju debug-log say?
[05:01] <bradm> oddly, not a real lot
[05:01] <bradm> let me try all this again
[05:05] <bradm> yeah, this is weird, its like too much network traffic and it drops
[05:06] <bradm> doesn't seem like a juju thing if thats the case
[07:50] <axw> wallyworld__: terse review, squashed my finger in the car door :\
[09:27] <rogpeppe2> wallyworld: you just got a review of https://codereview.appspot.com/61510049/
[10:05] <dimitern> wallyworld, meeting?
[10:05] <dimitern> mgz, ^^
[10:06] <mgz> dimitern: ta
[13:25] <dimitern> mgz, if you can take some time to look, i've updated the networking document to include a preliminary list of needed changes to goose
[13:46] <TheMue> dimitern: one short question. how do configuration values come into the environ config?
[13:47] <dimitern> TheMue, what do you mean?
[13:47] <dimitern> TheMue, from env.yaml ?
[13:47] <dimitern> TheMue, or from CLI juju set/etc. ?
[13:48] <TheMue> dimitern: when a system is bootstraped the environment has a config (EnvironConfig() *config.Config)
[13:48] <TheMue> dimitern: somehow the initial values have to be written into it
[13:49] <dimitern> TheMue, yes, so the env.yaml settings + some other things get validated and created at prepare time, then stored in the .jenv file
[13:49] <TheMue> dimitern: and when does this jenv file gets into the database?
[13:50] <dimitern> TheMue, and the actual *config.Config gets stored in mongo in the settings collection
[13:50] <mgz> dimitern: sure, I'll have a look
[13:50] <dimitern> mgz, ta
[13:51] <TheMue> dimitern: hmm, still have to find the flow where this all happens. reason is that I need to write another value into this config
[13:51] <dimitern> TheMue, take a look what happens in environs.Prepare
[13:52] <dimitern> TheMue, ah, for that you just need to add it in environs/config's schema
[13:54] <TheMue> dimitern: yip, detected that already, only the writing is missing. but the prepare hint is good. thx.
[13:54] <dimitern> TheMue, and add some get methods, etc. look a recent CL of mine that does that: https://codereview.appspot.com/58170045/
[13:55] <TheMue> dimitern: ah, nice, having somebody doing the same is very helpful
[13:57] <dimitern> TheMue, np :)
[14:33] <sinzui> abentley, jcsackett thedac, I am double booked through the morning
[14:33]  * sinzui has announcements for the standup
[14:33] <sinzui> too
[14:33] <abentley> sinzui: I see.  Should we postpone the standup or go on without you?
[14:34] <sinzui> abentley, might as well
[14:45] <abentley> sinzui: what are those announcements?
[14:45] <abentley> sinzui: I guess just email them to us.
[14:46] <sinzui> abentley, yeah, that will be best
[14:46] <rogpeppe2> fwereade, natefinch, wallyworld, dimitern, thumper: updated errgo names as discussed: http://paste.ubuntu.com/6925794/
[14:47] <dimitern> rogpeppe2, looking
[14:47] <rogpeppe2> natefinch: how does that feel to you?
[14:47] <rogpeppe> dimitern: we're going with Cause instead of Diagnosis, and Underlying instead of Cause.
[14:48] <rogpeppe> dimitern: and Mask instead of Wrap
[14:48] <rogpeppe> dimitern: and Notef instead of Wrapf
[14:48] <dimitern> rogpeppe, i'm +1 on all but last two - i liked wrap, what's wrong with it?
[14:49] <rogpeppe> dimitern: i liked it too, but this is the way we decided to paint the shed :-)
[14:50] <dimitern> rogpeppe, and how's mask/note better?
[14:50] <rogpeppe> dimitern: the thought is that it's a good idea to make it clear that we're masking the underlying cause
[14:50] <natefinch> rogpeppe: can you drop location from the public API?  It's not really necessary
[14:51] <rogpeppe> natefinch: you mean, make it a private field in Err?
[14:51] <rogpeppe> dimitern: and everyone seemed to like Note, so we went with that
[14:52] <rogpeppe> dimitern: (better than Annotate anyway, i think)
[14:52] <dimitern> rogpeppe, hmm..
[14:52] <natefinch> rogpeppe: Yeah, so the way I did it was instead of Locationer I had Detailed (Detailer if you must)  and that way you don't dictate a specific set of info from a sub-error, you just call Details() on the sub error and it formats how it wishes
[14:53] <dimitern> well, meh, it's just an api and it just needs getting used to
[14:53] <rogpeppe> dimitern: yeah, that's my thought
[14:53] <rogpeppe> dimitern: as long as the semantics are right, i'll get used to most names
[14:53] <natefinch> rogpeppe: I'm just trying to narrow the public API so there's less to grok.  There's a ton of stuff to ingest in your public API
[14:54] <dimitern> rogpeppe, yep
[14:55] <rogpeppe> natefinch: yeah, the public interface that we'd like people to see most of the time looks like this: http://paste.ubuntu.com/6925836/
[14:58] <rogpeppe> natefinch: it is useful to have each error responsible only for returning data and not for actually formatting things
[14:59] <rogpeppe> natefinch: it means that we can potentially provide different views on the same data
[14:59] <rogpeppe> natefinch: for example, a web interface might implement an alternative version of Details that formats the errors as html with source code links.
[15:00] <natefinch> rogpeppe: that's true
[15:01] <rogpeppe> natefinch: it is arguable, i suppose, whether Locationer, Wrapper and Causer should all be separate interfaces, but i think it could make sense to provide some and not others.
[15:01] <natefinch> rogpeppe: yeah I think that's fine.  small interfaces are nice.
[15:02] <rogpeppe> natefinch: Details should document how the interfaces are used though.
[15:02] <natefinch> rogpeppe: it's honestly the func(error)bool stuff that really complicates the API.... which is unfortunate given that they're likely not to be used except in limited cases
[15:02] <natefinch> rogpeppe: yep
[15:03] <rogpeppe> natefinch: they're used a fair amount actually (about 10% of the time)
[15:03] <natefinch> rogpeppe: what's the use for Any?  Isn't that the same as note?
[15:04] <rogpeppe> natefinch: no, Note masks the cause
[15:04] <rogpeppe> natefinch: Any allows any cause through
[15:04] <natefinch> rogpeppe: cause is now what you used to call diagnosis, right?
[15:05] <rogpeppe> natefinch: yes
[15:05] <rogpeppe> natefinch: Notef is basically equivalent to fmt.Errorf except that it adds source line info
[15:06] <natefinch> rogpeppe: how do you note and let the error type pass through?  Or is that only doable through mask(err, Any)?
[15:07] <rogpeppe> natefinch: you can use NoteMask
[15:07] <rogpeppe> natefinch: (which may well be better named MaskNote; i can't quite decide)
[15:08] <rogpeppe> natefinch: NoteMask is actually the underlying wrap primitive, used by all the other wrapping functions except WithCausef
[15:09] <natefinch> rogpeppe: I wish there was a function that didn't require the function argument that just always let the underlying error become the cause
[15:09] <rogpeppe> natefinch: var mask = errors.MaskFunc(errors.Any)
[15:10] <rogpeppe> natefinch: but, as i keep on asserting, that case is actually pretty rare
[15:10] <natefinch> rogpeppe: yeah, should be
[15:11] <rogpeppe> natefinch: because returned errors are part of *your* contract, and you should be responsible for knowing what they are
[15:11] <natefinch> rogpeppe: right
[15:12] <natefinch> rogpeppe: So mask(err) is effectively the same as just notef(err, "")
[15:13] <rogpeppe> natefinch: yes
[15:13] <rogpeppe> natefinch: those two are identical
[15:21] <abentley> rogpeppe: The current unit test against amd-64-precise got some panics: http://162.213.35.54:8080/job/run-unit-tests-amd64-precise/66/console
[15:22] <rogpeppe> abentley: looking
[15:23] <rogpeppe> abentley: hmm, i haven't seen this before
[15:23] <rogpeppe> ... Panic: unauthorized db:presence ns:presence.presence.beings lock type:0 client:127.0.0.1 (PC=0x414311)
[15:23] <abentley> rogpeppe: Just telling you because you said you were interested in panics.
[15:23] <abentley> rogpeppe: previous run did not panic this way (but also failed)
[15:24] <rogpeppe> abentley: yes, thanks - that's very interesting to see
[15:26] <rogpeppe> looks like the presence watcher panicked at some point, probably because of the permission changes going on the the db underneath
[15:28] <rogpeppe> natefinch: one potential way of simplifying things a little is to accept only a single function argument rather than a slice.
[15:28] <rogpeppe> natefinch: but then you'd always have to pass it, so the most common case becomes harder.
[15:28] <rogpeppe> natefinch: (the most common case being "return mask(err)" of course)
[15:29] <natefinch> rogpeppe: yeah.,.. I don't think that's a big deal, I think it's the fact that Note sounds like it doesn't mask the error, because it's obviously named differently than Mask...
[15:30] <rogpeppe> natefinch: yeah, i quite liked Wrap and Wrapf. but i can accept that and move on, i think.
[15:30] <natefinch> rogpeppe: Mask and Maskf?
[15:31] <rogpeppe> natefinch: people said they particularly liked "Note". so Note we have.
[15:31] <rogpeppe> natefinch: (as agreed)
[15:31] <sinzui> fwereade, I think we can denominate https://bugs.launchpad.net/juju-core/+bug/1255242 . This change in behaviour is a problem, I am not convinced juju is a fault
[15:31] <_mup_> Bug #1255242: HP cloud requires 4G to do what AWS does in 2G mem <ci> <hp-cloud> <intermittent-failure> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1255242>
[15:34] <natefinch> rogpeppe:  I guess if you start from the assumption that everything gets masked, except for things that pass a mask function, or when using WithCausef, that makes it easier to understand,
[15:34] <rogpeppe> natefinch: yeah
[15:36] <fwereade> sinzui, +1, although it would be nice if we can figure out what's at fault... something the image does differently?
[15:36] <natefinch> rogpeppe: ok, enough bikeshedding for me.  I'm sure we'll get used to it, and if not, we can always find and replace the names if we think of something better.
[15:37] <sinzui> fwereade, The image is my own suspicion. One day Hp will use our images
[15:37] <rogpeppe> natefinch: thanks
[15:42] <rogpeppe> ha, 9889 lines of diffs in 5 seconds. gofmt -r FTW! http://paste.ubuntu.com/6926047/
[15:43] <natefinch> rogpeppe: nice
[15:43] <natefinch> rogpeppe: gofmt is pretty awesome
[15:43] <rogpeppe> natefinch: it would be nice to be able to do statements and declarations as well as expressions, but yeah, it's great
[15:44] <natefinch> rogpeppe: yeah, I wish it could do more, too.  But for what it can do it's great
[15:47] <sinzui> fwereade, mgz: are these bugs backportable? Can I tartget them to 1.16.7? https://bugs.launchpad.net/juju-core/+bug/1241674 and https://bugs.launchpad.net/juju/+bug/1188126
[15:47] <_mup_> Bug #1241674: juju-core broken with OpenStack Havana for tenants with multiple networks <cts-cloud-review> <openstack-provider> <juju-core:Fix Released by gz> <https://launchpad.net/bugs/1241674>
[15:47] <_mup_> Bug #1188126: Juju unable to interact consistently with an openstack deployment where tenant has multiple networks configured <canonistack> <cts-cloud-review> <openstack-provider> <serverstack> <pyjuju:Triaged> <juju-core:Triaged by gz> <https://launchpad.net/bugs/1188126>
[15:48] <fwereade> sinzui, mgz is fuguring out if we should be hotfixing them for cts instead
[15:48] <fwereade> sinzui, they involve a config change
[15:48] <fwereade> sinzui, but we could handwave them to be "this config setting doesn't work properly in old 1.16s" I suppose
[15:49] <fwereade> sinzui, so it's just a bugfix ;p
[15:51] <mgz> sinzui: it's ugly, but possible
[15:52] <sinzui> mgz, I am happy to not release 1.16.7
[15:52] <mgz> I would much prefer we get an earlier 1.18
[17:08] <rogpeppe> natefinch: any chance you're going to merge that voyeur branch some time?
[17:19] <natefinch> rogpeppe: oh crap, sorry, yeah
[17:30] <natefinch> rogpeppe: I added the tests you suggested, not sure if there's anything else that needed to be done: https://codereview.appspot.com/57700044
[17:31] <rogpeppe> natefinch: i think it's good as is. one more test though: we never test what happens when NewValue is called with a non-nil arg
[17:31] <rogpeppe> natefinch: with that in, LGTM
[17:32] <natefinch> rogpeppe: cool
[17:32] <natefinch> rogpeppe: will do that right now
[17:32] <rogpeppe> natefinch: when you've submitted it, i'll be adding a patch that makes the zero Value ok to use, which i found useful elsewhere.
[17:33] <natefinch> rogpeppe: nice
[17:37] <natefinch> rogpeppe: actually there is a test for a non-nil arg, TestValueInitial, it's near the top of the file
[17:37] <rogpeppe> natefinch: oh yes, i missed it
[17:37] <rogpeppe> natefinch: LGTM then
[17:38] <natefinch> rogpeppe: oh ok, I missed your new lgtm, thanks
[17:39] <natefinch> rogpeppe: it's merging (in theory)
[17:39] <rogpeppe> natefinch: cool
[18:18] <TheMue> awsome, my new way of debug-log works even with the local provider via api w/o passing infos during the call
[18:19] <natefinch> rogpeppe, mgz, fwereade: anyone know what the minimum version of mongo is that we support?
[18:19] <TheMue> rogpeppe: have to do a bit cleanup, but I think you'll like it
[18:19] <rogpeppe> TheMue: cool
[18:19] <rogpeppe> natefinch: no i don't, sorry
[18:19] <rogpeppe> TheMue: how did you end up doing it?
[18:20] <TheMue> rogpeppe: I extended the environ config. default log location in there is the standard one, but the local provider sets the local one
[18:21] <TheMue> rogpeppe: then I can do logLocation = state.EnvironConfig().LogLocation() (a bit more due to returned error of ErrorConfig)
[18:22] <rogpeppe> TheMue: that seems like a reasonable solution, thanks
[18:22] <TheMue> rogpeppe: the local provider already sets the location as /var/log/juju-<user>-<envname>/all-machines.log. but it forgets the value after creating the dirs
[18:23] <rogpeppe> TheMue: you'll need to make sure that it's not a value that the user can set with set-environment
[18:23] <TheMue> rogpeppe: yeah, it definitely feels better. also the UI needs only to pass lines and filter during the call. how shall the UI installed in a container know about the local user?
[18:24] <rogpeppe> TheMue: yeah, it was definitely wrong to pass the log location as an arg to the API call
[18:24] <TheMue> rogpeppe: full agree now
[18:25] <rogpeppe> TheMue: putting the location in the env config feels a *little* bit like a hack, but i can't currently think of a better idea
[18:25] <TheMue> rogpeppe: the ensuring of not overwriting it is done where?
[18:25] <rogpeppe> TheMue: in EnvironProvider.ValidateConfig i think
[18:26] <rogpeppe> TheMue: just Valid actually
[18:26] <TheMue> rogpeppe: not in config.go immutableAttributes?
[18:26] <rogpeppe> TheMue: ah, perhaps there. let me check.
[18:27] <rogpeppe> TheMue: yes, that'll be the place
[18:28] <TheMue> rogpeppe: fine, then I've got it right
[18:43] <rogpeppe> mgz: ping
[18:43] <rogpeppe> mgz: scratch that, i don't expect you to be around at this time of the evening :-)
[18:44] <rogpeppe> a bzr question for anyone: i've got a load of commits with a merge from trunk in the middle them. what's the best way to undo the merge and pretend i never did it?
[18:45] <rogpeppe> s/them/of them/
[18:53] <natefinch> rogpeppe: make a new branch and cherry pick everything but that branch?  I don't know if there's a better way.  I'm not a bzr expert
[18:53] <natefinch> s/branch/merge/
[18:53] <rogpeppe> natefinch: yeah, i've done that, but it's not ideal
[18:54] <rogpeppe> natefinch: i always feel that whenever i use patch(1) i've failed
[18:58] <natefinch> rogpeppe: wow, I don't think I ever tried bzr help commands before... that is a friggin' huge UI
[18:58] <rogpeppe> natefinch: it's minute compared to git...
[18:58] <rogpeppe> natefinch: vcs's are like OS's before unix came along
[18:59] <natefinch> rogpeppe: yeah, git looks even bigger.  Man.  I sorta miss SVN.
[19:08] <hatch> whaaaaa??
[19:08]  * hatch pinches
[19:09] <hatch> natefinch you can probably rebase the merge out
[19:09] <hatch> ohh bzr.....yeah no idea
[19:09] <hatch> sorry :)
[19:16] <natefinch> hatch: heh, yeah, same here :)
[20:08] <thumper> natefinch: ping
[20:09] <natefinch> thumper: howdy
[20:37]  * thumper reboots