[03:08] thumper: re "This kind of goes against a lot of our coding standards." -- it wasn't intentional :) [03:08] I have fixed it. [03:12] cool [03:12] I sort of noticed that in the next file when I saw william's comment [03:12] and realised what you had done [04:24] wallyworld_: cc'ed you on the email with robie about kvm [04:24] as there is some simplestream stuff there [04:24] ok [04:24] for how the infrastructure syncs the images for kvm [04:25] ok, I'm off for the monday afternoon ice-skating / shopping time [04:25] back later to chat to william === thumper is now known as thumper-afk [05:37] wallyworld_, jam: https://codereview.appspot.com/13532047 [05:37] can't lbox propose at the moment without this [05:39] axw: doesn't that mean there is a Logf function that is being used incorrectly? [05:39] jam: no, there's two types of Logf [05:39] the vet catches one, and errors on the other which is being used correctly [05:40] loggo.Logf takes a first parameter of the log level [05:40] then the log format [05:40] gocheck's C.Logf takes the log format as the first arg [05:40] AFAICT there's no way of telling go vet how to distinguish between the two Logfs [05:45] ax [05:45] axw: how did the original get proposed at all then? [05:46] I'm fine with the change, but I'm curious what happened [05:47] 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] or there was a merge, but I don't think so [05:48] * axw gets tea and investigates [05:53] jam: it was the latter; there were two independent MPs that got merged [05:53] axw: sorry, was doing school pickup, do you still need me to look? [05:53] wallyworld_: s'ok, jam's looking [05:53] ok [06:07] axw: LGTM [06:07] thanks jam === tasdomas_afk is now known as tasdomas [07:49] axw: poke [07:49] 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] 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] I'm fine with 'tmp' vs '.tmp' I don't think it really matters. [07:52] mornin' all [07:52] good morning rogpeppe [07:52] jam: hiya [07:57] heyho all [08:00] jam: sorry, was taking a break before. reading now [08:01] jam: it will be in /tmp only if you don't tell it where to go [08:02] and for the only usage, I will be telling it where to go [08:02] 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] jam: for sshstorage, the default is next to it. I could make it the same for filestorage too [08:03] I didn't do that because it'll pollute the local filesystem for sync/generate-tools metadata [08:03] probably not a big deal [08:03] for sshstorage, the default is the remote storagedir with ".tmp" appended [08:04] 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] 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] axw: why? [08:06] if it is the temporary dir, we don't see content in it until it is finalized and then moved into place [08:06] right? [08:06] right [08:06] so the way I did it before was [08:07] sshstorage wrote to ${storage}/content, with a staging in ${storage}/tmp [08:07] localstorage expects everything to be directly under ${storage} [08:07] so I changed sshstorage back to doing that [08:07] with a tmp dir as a peer of ${storage} [08:08] 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] axw: so from what you've said, localstorage needs to take over what sshstorage uploaded, right? [08:11] jam: correct [08:11] and even if you pointed it at .../content it wouldn't use .../tmp for its temp dir [08:12] yes [08:12] localstorage doesn't do any of this tempdir stuff at the moment [08:12] it probably should, if we're being paranoid [08:16] sorry jam, maybe I confused things. there are three storage implementations things to consider [08:16] sshstorage, filestorage, localstorage [08:17] filestorage was only updated on william's request, and doesn't interact with sshstorage at all [08:17] localstorage is the one that takes over. localstorage does not currently have the write-to-tmp-then-mv behaviour [08:18] and since localstorage is existing, and used by the local provider, I was hesitant to change its layout [08:22] axw: so right now localstorage just writes directly to the final location, and interrupted transfers will see partial data? [08:23] jam: yup [08:23] axw: I think we want to fix that regardless the rest. [08:24] even if it is $TMP or whatever [08:24] fair enough [08:25] 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. === thumper-afk is now known as thumper [08:47] fwereade: ping [08:47] thumper, pong [08:47] hangout? [08:48] 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] thumper, https://plus.google.com/hangouts/_/b68108f32c53bcd9634bd39560203820f2029809?hl=en [08:56] 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] wallyworld_: http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/environs/storage.go#L62 (line 62) [09:02] shouldn't that be "if err == nil" then set dataURL = fullURL ? [09:02] (I think we're missing some tests about the return value of Fetch()) [09:02] seems so :-( [09:03] wallyworld_: well, you have "datasourceSuite.Fetch()" which is asserting it gets the relative path back [09:03] but I think that assertion is actually incorrect. [09:03] could be, i'll look into it [09:03] wallyworld_: k, I was trying to do some assertions that we are properly connecting to an HTTPS location, etc. [09:04] but ran into that. [09:04] sorry :-( will fix [09:04] np [10:46] wallyworld_, rogpeppe , mgz , fwereade, natefinch : standup [10:46] ta [11:25] * TheMue => lunch === tasdomas is now known as tasdomas_afk === tasdomas_afk is now known as tasdomas === gary_poster|away is now known as gary_poster [12:24] mgz: poke [12:59] 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] i tested with juju get nameofservice, and this var has a value [12:59] any idea on what can be failing? [13:23] yolanda: did you look at what the stderr output was? [13:23] mgz, i only saw that exit status 2 [13:25] right, but you're the one deploying the charm [13:25] so, make the charm give you useful output instead of just the exit code [13:30] axw: trivial change to environs/sshstorage: https://codereview.appspot.com/13321046 [13:30] 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] sed [13:31] only slightly joking... [13:31] mgz: that was going to be my next move :/ [13:33] natefinch: gocheck can't know how much to print, because it doesn't know about tests within tests [13:33] natefinch: i agree it's a problem [13:33] rogpeppe: it appears to be printing logging, though... is that our fault for how we're using it? [13:34] natefinch: we deliberately print logging, because otherwise there's no easy way to see what's happening underneath when a test fails [13:34] natefinch: it's easy enough to get rid of the log lines though [13:35] 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] natefinch: it's an interesting possibliity - you could add a flag that LoggingSuite inspects to determine whether to print log messages, perhaps [13:37] 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] natefinch: for example when something fails in the bot === Guest8446 is now known as wedgwood [13:37] natefinch: actually, on balance, i think an environment variable would probably work better [13:37] rogpeppe: the bot could always run with --verbose since in theory it shouldn't see failures [13:38] rogpeppe: as long as I have a toggle, I don't care where it is :) [13:38] natefinch: because then it would be just ignored for any package that doesn't happen to use LoggingSuite [13:38] rogpeppe: fair enough [13:39] natefinch: quick review of the above CL? https://codereview.appspot.com/13321046 [13:39] natefinch: it just fixes the build for me [13:40] reviewed [13:40] 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] natefinch: see testing.LoggingSuite [13:47] 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] natefinch: seems like an good idea [13:48] natefinch: perhaps a way to set the logging level actually [13:48] natefinch: in fact, doesn't loggo accept some kind of config syntax [13:48] ? [13:49] rogpeppe: yeah, there's a SetLogLevel... we could just have that settable via the env variable. Right now it defaults to DEBUG. [13:50] natefinch: i was actually thinking of ConfigureLoggers [13:55] 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] natefinch: well, yeah [13:56] natefinch: it will potentially be useful in a real juju environment - to enable low level logging in some problematic packages only [13:56] natefinch: because some low level logging can be extremely verbose [13:57] natefinch: so a single global log level too big a hammer sometimes [13:57] natefinch: but for tests, i think i agree [13:57] We can always add another env variable later if people need a smaller hammer for their tests [14:01] rogpeppe: thanks for fixing that [14:02] axw: i guess not many people don't use bash :-) [14:02] what'cha running? rc? :) [14:02] axw: yeah [14:03] axw: it's the shell i've used since... jeeze, maybe 1991? [14:03] can't say I've ever used anything apart from bash, really [14:03] zsh briefly [14:03] axw: rc has some definite advantages for scripting in particular [14:04] csh when I had to at my old job [14:04] *shudder* [14:04] axw: the semantics are much much cleaner [14:04] * axw has a look at some docs [14:04] axw: good intro: http://plan9.bell-labs.com/sys/doc/rc.html [14:05] ta [14:05] axw: in particular see section 28 for a good overview of why it works the way it does [14:07] i'd appreciate a review of this if possible: https://codereview.appspot.com/13535045 [14:12] rogpeppe: what will ConfigStorage be used by? [14:12] axw: the command line commands [14:13] axw: the environments.yaml stuff is due to change to allow extra information to be associated with an environment [14:13] axw: created when an environment is bootstrapped [14:14] 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] axw: here's my idea for the eventual form of the ConfigStorage interface: http://paste.ubuntu.com/6115093/ [14:16] axw: it'll probably change as it encounters reality [14:17] thanks rogpeppe, reading now [14:17] axw: thanks [14:25] mgz, i was able to debug error message, it shows: panic: version: cannot read forced version: open FORCE-VERSION: permission denied [14:26] maybe i'm conflicting with some other var? i'm using admin_fullname, maybe is that reserved? [14:27] full log here: http://paste.ubuntu.com/6115131/ === tasdomas is now known as tasdomas_afk [14:37] yolanda: thanks, that's useful [14:37] mgz, what can be causing that? seems a bit unrelated with a simple config-get [14:37] other vars are working ok, so i'm thinking that the name may be conflicting, but not sure [14:38] indeed. seems to be an args parsing thing somehow. [14:38] the logic in version/version.go is: [14:39] get the dir of args[0] as the location of tools, open the FORCE-VERSION file there [14:40] but if other config-get invocations work something funky is going on [14:42] but I don't much like that logic regardless [14:43] mgz, should i file a bug? [14:44] yolanda: yes, and it probably needs more context on what exactly that charm hook is doing [14:44] just trying to change the name of config vars and redeploy now [14:44] changing admin_xxx for another prefix [14:44] it seems more likely that the hook is accidentally changing pwd or something to break stuff [14:46] 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] lunch [14:57] mgz, indeed, i changed the var for something different like "defaultname" but still the same problem [14:58] i can't imagine what's causing config-get to fail there [15:05] yolanda: not sure what to suggest as next debugging step. have you filed that bug yet? [15:06] mgz, no, because i don't know what's the cause [15:07] some bugs are just symptoms :) [15:08] mgz, trying to filter a bit, now i'm deploying without external config file [15:08] just using defaults [15:14] same problem, i'll file the bug [15:19] mgz, https://bugs.launchpad.net/juju-core/+bug/1226088 [15:19] <_mup_> Bug #1226088: config-get fails with "open FORCE-VERSION: permission denied" [15:20] yolanda: thanks. what's the charm? the hook code seems more relevent than the config. [15:20] mgz, it's gerrit charm, it's not still public [15:21] can i send it to somewhere private? [15:22] 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] mgz, we are currently pushing to canonical-ci private team [15:23] we are keeping that private at the moment [15:24] rogpeppe, fwereade outlooks on cutting a 1.14 release today? [15:24] 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

[15:24] which is the last bug for the milestone https://launchpad.net/juju-core/+milestone/1.14.0 [15:24] arosales: i think that's all merged [15:25] rogpeppe, bug is still in progress, could you update the bug status? [15:25] mgz, checking with the team about that [15:25] arosales: and *should* be fixed, though i wasn't able to reproduce the original issue, so i'm not absolutely sure [15:25] fwereade, robbiew well at this point we need to push 1.14 out [15:25] if we need to do a 1.14.1 we can address that there if any bits are missing [15:26] huh...oh... rogpeppe^ [15:26] ;) [15:26] robbiew, sorry [15:26] auto complete [15:26] np [15:27] 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] yolanda: see /query [15:30] hmm davecheney reported the bug initially [15:30] rogpeppe, did you say the branch is in 1.14? [15:30] arosales: yes [15:32] rogpeppe, so if we cut a 1.14 release today it would have 1220027 fix in it, just untested [15:32] arosales: yes. [15:32] arosales: so... worth marking as "fix released", i guess? [15:33] rogpeppe, I think so if the branch is in 1.14, trunk, and 1.15 [15:33] arosales: ok,marked as "fix committed" [15:51] rogpeppe, thanks. if we need to return to is we can issue a 1.14. 1 or in subsequent 1.15 releases [15:54] rogpeppe: btw, it looks like some of the tests rely on logging being enabled during testing [15:54] natefinch: ah, damn, yes, they do [15:54] rogpeppe: that seems like a weakness in the tests, honestly. [15:54] natefinch: they should probably explicitly enable it, or use a different log channel or something [15:55] rogpeppe: yep [16:45] anyone up for a review? nothing earth shaking, just part on-going config cleanup.: https://codereview.appspot.com/13421050 [16:48] looking [16:48] 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] sinzui, thus I would like to start working with you to for the 1.14 and the associated QA. [16:49] sinzui, we can sync with davecheney when he comes on-line later in the day. [16:49] sinzui, but wanted to give you a heads up that we'll need to cut a release today. [16:51] rogpeppe: all makes sense to me [16:51] mgz: thanks [16:52] thank you arosales === Makyo1 is now known as Makyo [17:40] * rogpeppe reaches eod [17:40] g'night all [17:42] rogpeppe: g'night === FunnyLookinHat_ is now known as FunnyLookinHat === _mup__ is now known as _mup_ [20:24] I cannot build juju core 1.14. I can build and run trunk. Make build for 1.14 exists with an error [20:24] # launchpad.net/juju-core/provider/azure [20:24] provider/azure/storage.go:96: multiple-value context.GetAnonymousFileURL() in single-value context [20:36] sinzui: looking.... [20:46] sinzui: I think it's a difference in the supported version of gwacl [20:46] ah [20:48] sinzui: yeah, just update gwacl and that should fix it. Sorta surprised it built in one place and not the other [20:50] natefinch, This is a case of me downgrading. I just pulled the 1.14 branch and switched to it. [20:52] I don't think the build-release-tarball.bash script will be happy with non-trunk and it always pulls gwacl tip === _thumper_ is now known as thumper [20:53] mramm: ping [20:53] sinzui: what's weird is that we cut 1.14 after the change to gwacl [20:54] oh? [20:54] 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] natefinch, trunk clearly has a change to make it compatible: http://pastebin.ubuntu.com/6116619/ [20:55] sinzui: actually... nevermind, that's the latest change on 1.14, not when it was cut [20:55] It is getting selected merged [20:55] merged [20:55] merges [20:57] sinzui: yeah, that definitely needs to be on 1.14. This is actually sort of a problem with Go in general... [20:58] 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] 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] sinzui: yeah, that sounds like the right thing to do [21:01] fwereade_: ping [21:02] * thumper recalls fwereade_'s move and packing [21:10] ah crap [21:11] * thumper makes a mental not to check the logrotate code [21:47] thumper: pong [21:48] mramm: hey, see email about timing clashes :) [21:48] ok [21:51] I am also free later tonight, and might have to go out and help my friend get migraine medication [21:51] so perhaps it will all work out for the best ;) [21:52] mramm: so lets just try to touch base later? [21:52] sure [21:52] ok [22:05] * thumper taking last daughter to the doctor === thumper is now known as thumper-afk === bigjools_ is now known as bigjools [22:26] jam, fwiw filed bug 1226307 re tool upload [22:26] <_mup_> Bug #1226307: juju-core lazily get tools if from public bucket === thumper-afk is now known as thumper [23:08] mramm: I'm around now for a bit if you are free [23:08] I am [23:08] otherwise it'll be after lunch [23:08] got time now? [23:10] mramm: I'm in the one on one hangout [23:39] bigjools: hey [23:39] can you fix permissions in gwacl [23:39] davecheney: helleau [23:39] https://launchpad.net/~gwacl-hackers [23:39] ^ can you add juju-hackers to that [23:39] or trasfer ownership [23:39] please [23:40] who wants to own it? [23:40] juju-hackers [23:40] make the owner mark ramm [23:40] he loves code [23:41] I generally dislike teams being members of other teams [23:41] because it makes email management harder [23:41] bigjools: please, this is a matter of urgency [23:41] I'll add you and make you admin [23:41] ta [23:42] done [23:42] but consider the team mess -it's the reason I quit juju hackers [23:42] email from other teams that it's also part of.... PITA