[03:08] <axw> thumper: re "This kind of goes against a lot of our coding standards."  -- it wasn't intentional :)
[03:08] <axw> I have fixed it.
[03:12] <thumper> cool
[03:12] <thumper> I sort of noticed that in the next file when I saw william's comment
[03:12] <thumper> and realised what you had done
[04:24] <thumper> wallyworld_: cc'ed you on the email with robie about kvm
[04:24] <thumper> as there is some simplestream stuff there
[04:24] <wallyworld_> ok
[04:24] <thumper> for how the infrastructure syncs the images for kvm
[04:25] <thumper> ok, I'm off for the monday afternoon ice-skating / shopping time
[04:25] <thumper> back later to chat to william
[05:37] <axw> wallyworld_, jam: https://codereview.appspot.com/13532047
[05:37] <axw> can't lbox propose at the moment without this
[05:39] <jam> axw: doesn't that mean there is a Logf function that is being used incorrectly?
[05:39] <axw> jam: no, there's two types of Logf
[05:39] <axw> the vet catches one, and errors on the other which is being used correctly
[05:40] <axw> loggo.Logf takes a first parameter of the log level
[05:40] <axw> then the log format
[05:40] <axw> gocheck's C.Logf takes the log format  as the first arg
[05:40] <axw> AFAICT there's no way of telling go vet how to distinguish between the two Logfs
[05:45] <jam> ax
[05:45] <jam> axw: how did the original get proposed at all then?
[05:46] <jam> I'm fine with the change, but I'm curious what happened
[05:47] <axw> jam: yeah I'm not too sure. I will investigate; only thing I can think is that it was proposed, then .lbox.check modified, and a bzr push done
[05:48] <axw> or there was a merge, but I don't think so
[05:48]  * axw gets tea and investigates
[05:53] <axw> jam: it was the latter; there were two independent MPs that got merged
[05:53] <wallyworld_> axw: sorry, was doing school pickup, do you still need me to look?
[05:53] <axw> wallyworld_: s'ok, jam's looking
[05:53] <wallyworld_> ok
[06:07] <jam> axw: LGTM
[06:07] <axw> thanks jam
[07:49] <jam> axw: poke
[07:49] <jam> axw: I'm looking at your localstorage and ssh storage stuff, and really *I* think that the temp directory should be in or at least next-to the storage location. Because there is 0 guarantee that /tmp is going to be on the same filesystem. (often /tmp is a tmpfs, etc)
[07:50] <jam> So I'm happy with "ssh storage uses it until the local provider takes it over", but I think the tmp dir should be under storage
[07:50] <jam> I'm fine with 'tmp' vs '.tmp' I don't think it really matters.
[07:52] <rogpeppe> mornin' all
[07:52] <jam> good morning rogpeppe
[07:52] <rogpeppe> jam: hiya
[07:57] <TheMue> heyho all
[08:00] <axw> jam: sorry, was taking a break before. reading now
[08:01] <axw> jam: it will be in /tmp only if you don't tell it where to go
[08:02] <axw> and for the only usage, I will be telling it where to go
[08:02] <jam> axw: but why make that the default rather than next to the storage, since then you are much more sure it will be on the same fs
[08:03] <axw> jam: for sshstorage, the default is next to it. I could make it the same for filestorage too
[08:03] <axw> I didn't do that because it'll pollute the local filesystem for sync/generate-tools metadata
[08:03] <axw> probably not a big deal
[08:03] <axw> for sshstorage, the default is the remote storagedir with ".tmp" appended
[08:04] <jam> axw: I think it makes sense to have them match, and I think putting it inside is nice if it is something we will be managing.
[08:05] <axw> jam: I'll take a look at how feasible it'll be. environs/localstorage may need to change to do something similar. I'm hesitant to change that, because that'll require upgrade checks
[08:05] <jam> axw: why?
[08:06] <jam> if it is the temporary dir, we don't see content in it until it is finalized and then moved into place
[08:06] <jam> right?
[08:06] <axw> right
[08:06] <axw> so the way I did it before was
[08:07] <axw> sshstorage wrote to ${storage}/content, with a staging in ${storage}/tmp
[08:07] <axw> localstorage expects everything to be directly under ${storage}
[08:07] <axw> so I changed sshstorage back to doing that
[08:07] <axw> with a tmp dir as a peer of ${storage}
[08:08] <axw> if I were to not do that, I'd either need to change localstorage to have content/tmp subdirs, or check the feasibility of pointing localstorage at ${storage}/content
[08:11] <jam> axw: so from what you've said, localstorage needs to take over what sshstorage uploaded, right?
[08:11] <axw> jam: correct
[08:11] <jam> and even if you pointed it at .../content it wouldn't use .../tmp for its temp dir
[08:12] <axw> yes
[08:12] <axw> localstorage doesn't do any of this tempdir stuff at the moment
[08:12] <axw> it probably should, if we're being paranoid
[08:16] <axw> sorry jam, maybe I confused things. there are three storage implementations things to consider
[08:16] <axw> sshstorage, filestorage, localstorage
[08:17] <axw> filestorage was only updated on william's request, and doesn't interact with sshstorage at all
[08:17] <axw> localstorage is the one that takes over. localstorage does not currently have the write-to-tmp-then-mv behaviour
[08:18] <axw> and since localstorage  is existing, and used by the local provider, I was hesitant to change its layout
[08:22] <jam> axw: so right now localstorage just writes directly to the final location, and interrupted transfers will see partial data?
[08:23] <axw> jam: yup
[08:23] <jam> axw: I think we want to fix that regardless the rest.
[08:24] <jam> even if it is $TMP or whatever
[08:24] <axw> fair enough
[08:25] <axw> jam: I was thinking of modifying localstorage to become something more generic, exposing another storage via HTTP. I might as well bite the bullet and do that now.
[08:47] <thumper> fwereade: ping
[08:47] <fwereade> thumper, pong
[08:47] <thumper> hangout?
[08:48] <fwereade> thumper, sure, a quick one, just a mo
[08:48]  * thumper waits
[08:49]  * fwereade has found his headphones and is starting one
[08:50] <fwereade> thumper, https://plus.google.com/hangouts/_/b68108f32c53bcd9634bd39560203820f2029809?hl=en
[08:56] <jam> dimitern, fwereade: I will not make it to the standup today, I have to go sign my son up for after school activities
[09:01] <jam> wallyworld_: http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/environs/storage.go#L62 (line 62)
[09:02] <jam> shouldn't that be "if err == nil" then set dataURL = fullURL ?
[09:02] <jam> (I think we're missing some tests about the return value of Fetch())
[09:02] <wallyworld_> seems so :-(
[09:03] <jam> wallyworld_: well, you have "datasourceSuite.Fetch()" which is asserting it gets the relative path back
[09:03] <jam> but I think that assertion is actually incorrect.
[09:03] <wallyworld_> could be, i'll look into it
[09:03] <jam> wallyworld_: k, I was trying to do some assertions that we are properly connecting to an HTTPS location, etc.
[09:04] <jam> but ran into that.
[09:04] <wallyworld_> sorry :-( will fix
[09:04] <jam> np
[10:46] <dimitern> wallyworld_, rogpeppe , mgz , fwereade, natefinch : standup
[10:46] <mgz> ta
[11:25]  * TheMue => lunch
[12:24] <jam> mgz: poke
[12:59] <yolanda> hi, i'm having a problem with juju config vars. Doing a config-get for one of the vars throw: subprocess.CalledProcessError: Command '['config-get', 'admin_pubkey', '--format=json']' returned non-zero exit status 2
[12:59] <yolanda> i tested with juju get nameofservice, and this var has a value
[12:59] <yolanda> any idea on what can be failing?
[13:23] <mgz> yolanda: did you look at what the stderr output was?
[13:23] <yolanda> mgz, i only saw that exit status 2
[13:25] <mgz> right, but you're the one deploying the charm
[13:25] <mgz> so, make the charm give you useful output instead of just the exit code
[13:30] <rogpeppe> axw: trivial change to environs/sshstorage: https://codereview.appspot.com/13321046
[13:30] <natefinch> is there a way to get gocheck to be less spammy?  It prints out like 100 lines per failure, when really all I want is the line of the test that failed
[13:31] <mgz> sed
[13:31] <mgz> only slightly joking...
[13:31] <natefinch> mgz: that was going to be my next move :/
[13:33] <rogpeppe> natefinch: gocheck can't know how much to print, because it doesn't know about tests within tests
[13:33] <rogpeppe> natefinch: i agree it's a problem
[13:33] <natefinch> rogpeppe: it appears to be printing logging, though... is that our fault for how we're using it?
[13:34] <rogpeppe> natefinch: we deliberately print logging, because otherwise there's no easy way to see what's happening underneath when a test fails
[13:34] <rogpeppe> natefinch: it's easy enough to get rid of the log lines though
[13:35] <natefinch> rogpeppe: most of the time I know why something is failing, or can tell when I get there. I'd much rather have logging be an optional flag than on all the time... it obscures the actual failureas
[13:36] <rogpeppe> natefinch: it's an interesting possibliity - you could add a flag that LoggingSuite inspects to determine whether to print log messages, perhaps
[13:37] <rogpeppe> natefinch: i'm not sure whether the default should be on or off though - when i get a random unexpected (and perhaps only occasionally reproducible) error in the tests, i actually want to see as much info as possible
[13:37] <rogpeppe> natefinch: for example when something fails in the bot
[13:37] <rogpeppe> natefinch: actually, on balance, i think an environment variable would probably work better
[13:37] <natefinch> rogpeppe: the bot could always run with --verbose since in theory it shouldn't see failures
[13:38] <natefinch> rogpeppe: as long as I have a toggle, I don't care where it is :)
[13:38] <rogpeppe> natefinch: because then it would be just ignored for any package that doesn't happen to use LoggingSuite
[13:38] <natefinch> rogpeppe: fair enough
[13:39] <rogpeppe> natefinch: quick review of the above CL? https://codereview.appspot.com/13321046
[13:39] <rogpeppe> natefinch: it just fixes the build for me
[13:40] <natefinch> reviewed
[13:40] <natefinch> rogpeppe: where is the logging currently turned on? I can at least go poke at it locally to make my life easier right now
[13:40] <rogpeppe> natefinch: see testing.LoggingSuite
[13:47] <natefinch> rogpeppe: thanks.. that is so much better.  What do you think about me submitting a CL for an environment variable that turns off logging? (default would be same behavior as now)
[13:48] <rogpeppe> natefinch: seems like an good idea
[13:48] <rogpeppe> natefinch: perhaps a way to set the logging level actually
[13:48] <rogpeppe> natefinch: in fact, doesn't loggo accept some kind of config syntax
[13:48] <rogpeppe> ?
[13:49] <natefinch> rogpeppe: yeah, there's a SetLogLevel... we could just have that settable via the env variable. Right now it defaults to DEBUG.
[13:50] <rogpeppe> natefinch: i was actually thinking of ConfigureLoggers
[13:55] <natefinch> rogpeppe: ahh yeah... setting that seems like a lot of work.  I've used similar per-package log levels in other projects... and never have I ever done anything but set the global log level :)
[13:55] <rogpeppe> natefinch: well, yeah
[13:56] <rogpeppe> natefinch: it will potentially be useful in a real juju environment - to enable low level logging in some problematic packages only
[13:56] <rogpeppe> natefinch: because some low level logging can be extremely verbose
[13:57] <rogpeppe> natefinch: so a single global log level too big a hammer sometimes
[13:57] <rogpeppe> natefinch: but for tests, i think i agree
[13:57] <natefinch> We can always add another env variable later if people need a smaller hammer for their tests
[14:01] <axw> rogpeppe: thanks for fixing that
[14:02] <rogpeppe> axw: i guess not many people don't use bash :-)
[14:02] <axw> what'cha running? rc? :)
[14:02] <rogpeppe> axw: yeah
[14:03] <rogpeppe> axw: it's the shell i've used since... jeeze, maybe 1991?
[14:03] <axw> can't say I've ever used anything apart from bash, really
[14:03] <axw> zsh briefly
[14:03] <rogpeppe> axw: rc has some definite advantages for scripting in particular
[14:04] <axw> csh when I had to at my old job
[14:04] <axw> *shudder*
[14:04] <rogpeppe> axw: the semantics are much much cleaner
[14:04]  * axw has a look at some docs
[14:04] <rogpeppe> axw: good intro: http://plan9.bell-labs.com/sys/doc/rc.html
[14:05] <axw> ta
[14:05] <rogpeppe> axw: in particular see section 28 for a good overview of why it works the way it does
[14:07] <rogpeppe> i'd appreciate a review of this if possible: https://codereview.appspot.com/13535045
[14:12] <axw> rogpeppe: what will ConfigStorage be used by?
[14:12] <rogpeppe> axw: the command line commands
[14:13] <rogpeppe> axw: the environments.yaml stuff is due to change to allow extra information to be associated with an environment
[14:13] <rogpeppe> axw: created when an environment is bootstrapped
[14:14] <rogpeppe> axw: and also to cache current endpoint info so that we don't need to talk to the provider to try to find out the API address for an environment
[14:15] <rogpeppe> axw: here's my idea for the eventual form of the ConfigStorage interface: http://paste.ubuntu.com/6115093/
[14:16] <rogpeppe> axw: it'll probably change as it encounters reality
[14:17] <axw> thanks rogpeppe, reading now
[14:17] <rogpeppe> axw: thanks
[14:25] <yolanda> mgz, i was able to debug error message, it shows: panic: version: cannot read forced version: open FORCE-VERSION: permission denied
[14:26] <yolanda> maybe i'm conflicting with some other var? i'm using admin_fullname, maybe is that reserved?
[14:27] <yolanda> full log here: http://paste.ubuntu.com/6115131/
[14:37] <mgz> yolanda: thanks, that's useful
[14:37] <yolanda> mgz, what can be causing that? seems a bit unrelated with a simple config-get
[14:37] <yolanda> other vars are working ok, so i'm thinking that the name may be conflicting, but not sure
[14:38] <mgz> indeed. seems to be an args parsing thing somehow.
[14:38] <mgz> the logic in version/version.go is:
[14:39] <mgz> get the dir of args[0] as the location of tools, open the FORCE-VERSION file there
[14:40] <mgz> but if other config-get invocations work something funky is going on
[14:42] <mgz> but I don't much like that logic regardless
[14:43] <yolanda> mgz, should i file a bug?
[14:44] <mgz> yolanda: yes, and it probably needs more context on what exactly that charm hook is doing
[14:44] <yolanda> just trying to change the name of config vars and redeploy now
[14:44] <yolanda> changing admin_xxx for another prefix
[14:44] <mgz> it seems more likely that the hook is accidentally changing pwd or something to break stuff
[14:46] <yolanda> mgz, the hook just happens after a db joined, and tries to render some content with these vars, it's first config-get called in the hook
[14:48] <rogpeppe> lunch
[14:57] <yolanda> mgz, indeed, i changed the var for something different like "defaultname" but still the same problem
[14:58] <yolanda> i can't imagine what's causing config-get to fail there
[15:05] <mgz> yolanda: not sure what to suggest as next debugging step. have you filed that bug yet?
[15:06] <yolanda> mgz, no, because i don't know what's the cause
[15:07] <mgz> some bugs are just symptoms :)
[15:08] <yolanda> mgz, trying to filter a bit, now i'm deploying without external config file
[15:08] <yolanda> just using defaults
[15:14] <yolanda> same problem, i'll file the bug
[15:19] <yolanda> mgz, https://bugs.launchpad.net/juju-core/+bug/1226088
[15:19] <_mup_> Bug #1226088: config-get fails with "open FORCE-VERSION: permission denied" <juju-core:New> <https://launchpad.net/bugs/1226088>
[15:20] <mgz> yolanda: thanks. what's the charm? the hook code seems more relevent than the config.
[15:20] <yolanda> mgz, it's gerrit charm, it's not still public
[15:21] <yolanda> can i send it to somewhere private?
[15:22] <mgz> is it actually pviate, or just not ready? can either push to ~yolanda.robla namespace or I guess just one of the canonical datacenter machines if it's really not to be revealed
[15:23] <yolanda> mgz, we are currently pushing to canonical-ci private team
[15:23] <yolanda> we are keeping that private at the moment
[15:24] <arosales> rogpeppe, fwereade outlooks on cutting a 1.14 release today?
[15:24] <arosales> I see rogpeppe has  a branch out for  https://bugs.launchpad.net/juju-core/+bug/1220027
[15:24] <_mup_> Bug #1220027: worker/provisioner: cannot restart cleanly due to hard dependency on api server <papercut> <juju-core:In Progress by rogpeppe> <juju-core 1.14:In Progress by rogpeppe> <juju-core trunk:In Progress by rogpeppe> <https://launchpad.net/bugs/1220027>
[15:24] <arosales> which is the last bug for the milestone  https://launchpad.net/juju-core/+milestone/1.14.0
[15:24] <rogpeppe> arosales: i think that's all merged
[15:25] <arosales> rogpeppe, bug is still in progress, could you update the bug status?
[15:25] <yolanda> mgz, checking with the team about that
[15:25] <rogpeppe> arosales: and *should* be fixed, though i wasn't able to reproduce the original issue, so i'm not absolutely sure
[15:25] <arosales> fwereade, robbiew well at this point we need to push 1.14 out
[15:25] <arosales> if we need to do a 1.14.1 we can address that there if any bits are missing
[15:26] <robbiew> huh...oh... rogpeppe^
[15:26] <robbiew> ;)
[15:26] <arosales> robbiew, sorry
[15:26] <arosales> auto complete
[15:26] <robbiew> np
[15:27] <rogpeppe> arosales: i didn't mark the bug as fixed, because although i sincerely believe that it is, i need someone who can verify that
[15:29] <mgz> yolanda: see /query
[15:30] <arosales> hmm davecheney reported the bug initially
[15:30] <arosales> rogpeppe, did you say the branch is in 1.14?
[15:30] <rogpeppe> arosales: yes
[15:32] <arosales> rogpeppe, so if we cut a 1.14 release today it would have 1220027 fix in it, just untested
[15:32] <rogpeppe> arosales: yes.
[15:32] <rogpeppe> arosales: so... worth marking as "fix released", i guess?
[15:33] <arosales> rogpeppe, I think so if the branch is in 1.14, trunk, and 1.15
[15:33] <rogpeppe> arosales: ok,marked as "fix committed"
[15:51] <arosales> rogpeppe, thanks. if we need to return to is we can issue a 1.14. 1 or in subsequent 1.15 releases
[15:54] <natefinch> rogpeppe: btw, it looks like some of the tests rely on logging being enabled during testing
[15:54] <rogpeppe> natefinch: ah, damn, yes, they do
[15:54] <natefinch> rogpeppe: that seems like a weakness in the tests, honestly.
[15:54] <rogpeppe> natefinch: they should probably explicitly enable it, or use a different log channel or something
[15:55] <natefinch> rogpeppe: yep
[16:45] <rogpeppe> anyone up for a review? nothing earth shaking, just part on-going config cleanup.: https://codereview.appspot.com/13421050
[16:48] <mgz> looking
[16:48] <arosales> sinzui, it looks like the bugs needed for the 1.14 are in fix committed https://launchpad.net/juju-core/+milestone/1.14.0
[16:49] <arosales> sinzui, thus I would like to start working with you to for the 1.14 and the associated QA.
[16:49] <arosales> sinzui, we can sync with davecheney when he comes on-line later in the day.
[16:49] <arosales> sinzui, but wanted to give you a heads up that we'll need to cut a release today.
[16:51] <mgz> rogpeppe: all makes sense to me
[16:51] <rogpeppe> mgz: thanks
[16:52] <sinzui> thank you arosales
[17:40]  * rogpeppe reaches eod
[17:40] <rogpeppe> g'night all
[17:42] <natefinch> rogpeppe: g'night
[20:24] <sinzui> I cannot build juju core 1.14. I can build and run trunk. Make build for 1.14 exists with an error
[20:24] <sinzui> # launchpad.net/juju-core/provider/azure
[20:24] <sinzui> provider/azure/storage.go:96: multiple-value context.GetAnonymousFileURL() in single-value context
[20:36] <natefinch> sinzui: looking....
[20:46] <natefinch> sinzui: I think it's a difference in the supported version of gwacl
[20:46] <sinzui> ah
[20:48] <natefinch> sinzui: yeah, just update gwacl and that should fix it.  Sorta surprised it built in one place and not the other
[20:50] <sinzui> natefinch, This is a case of me downgrading. I just pulled the 1.14 branch and switched to it.
[20:52] <sinzui> I don't think the build-release-tarball.bash script will be happy with non-trunk and it always pulls gwacl tip
[20:53] <thumper> mramm: ping
[20:53] <natefinch> sinzui: what's weird is that we cut 1.14 after the change to gwacl
[20:54] <sinzui> oh?
[20:54] <natefinch> sinzui: at least, according to the timestamps on each.  the gwacl change was on 9/11 and 1.14 was cut on 9/13
[20:55] <sinzui> natefinch, trunk clearly has a change to make it compatible: http://pastebin.ubuntu.com/6116619/
[20:55] <natefinch> sinzui: actually... nevermind, that's the latest change on 1.14, not when it was cut
[20:55] <sinzui> It is getting selected merged
[20:55] <sinzui> merged
[20:55] <sinzui> merges
[20:57] <natefinch> sinzui: yeah, that definitely needs to be on 1.14.  This is actually sort of a problem with Go in general...
[20:58] <natefinch> sinzui: I'll ping the juju list and it'll get fixed ASAP... it's EOD for me, or I'd look more into it
[20:58] <sinzui> I think the immediate solution is to update the release script to acknowledge and use dependencies.tsv. Pulling tip for each is zany
[20:59] <natefinch> sinzui: yeah, that sounds like the right thing to do
[21:01] <thumper> fwereade_: ping
[21:02]  * thumper recalls fwereade_'s move and packing
[21:10] <thumper> ah crap
[21:11]  * thumper makes a mental not to check the logrotate code
[21:47] <mramm> thumper: pong
[21:48] <thumper> mramm: hey, see email about timing clashes :)
[21:48] <mramm> ok
[21:51] <mramm> I am also free later tonight, and might have to go out and help my friend get migraine medication
[21:51] <mramm> so perhaps it will all work out for the best ;)
[21:52] <thumper> mramm: so lets just try to touch base later?
[21:52] <mramm> sure
[21:52] <thumper> ok
[22:05]  * thumper taking last daughter to the doctor
[22:26] <hazmat> jam, fwiw filed bug 1226307  re tool upload
[22:26] <_mup_> Bug #1226307: juju-core lazily get tools if from public bucket <juju-core:New> <https://launchpad.net/bugs/1226307>
[23:08] <thumper> mramm: I'm around now for a bit if you are free
[23:08] <mramm> I am
[23:08] <thumper> otherwise it'll be after lunch
[23:08] <thumper> got time now?
[23:10] <thumper> mramm: I'm in the one on one hangout
[23:39] <davecheney> bigjools: hey
[23:39] <davecheney> can you fix permissions in gwacl
[23:39] <bigjools> davecheney: helleau
[23:39] <davecheney> https://launchpad.net/~gwacl-hackers
[23:39] <davecheney> ^ can you add juju-hackers to that
[23:39] <davecheney> or trasfer ownership
[23:39] <davecheney> please
[23:40] <bigjools> who wants to own it?
[23:40] <davecheney> juju-hackers
[23:40] <davecheney> make the owner mark ramm
[23:40] <davecheney> he loves code
[23:41] <bigjools> I generally dislike teams being members of other teams
[23:41] <bigjools> because it makes email management harder
[23:41] <davecheney> bigjools: please, this is a matter of urgency
[23:41] <bigjools> I'll add you and make you admin
[23:41] <davecheney> ta
[23:42] <bigjools> done
[23:42] <bigjools> but consider the team mess -it's the reason I quit juju hackers
[23:42] <bigjools> email from other teams that it's also part of.... PITA