| davecheney | thumper: menn0 waigani https://github.com/juju/names/pull/4 | 00:11 |
|---|---|---|
| menn0 | davecheney: I'm done | 00:35 |
| davecheney | menn0: ta | 00:37 |
| davecheney | just responding now | 00:37 |
| davecheney | won't take long | 00:37 |
| davecheney | changes to juju/juju are surprisingly minimal | 00:37 |
| davecheney | https://github.com/juju/juju | 00:38 |
| davecheney | gah | 00:38 |
| davecheney | https://github.com/juju/juju/pull/88/files | 00:38 |
| davecheney | if you have time to review those i can get stuck into the final change | 00:38 |
| axw | wallyworld_: need to restart, back for 1:1 on a minute | 00:59 |
| wallyworld_ | ok | 01:00 |
| axw | wallyworld_: mind if we defer for 10 mins or so? | 01:05 |
| wallyworld_ | sure | 01:05 |
| axw | wallyworld_: ready when you are | 01:12 |
| davecheney | axw: http://juju-ci.vapour.ws:8080/job/github-merge-juju/118/console | 01:18 |
| davecheney | ^ this test failed, but the bot marked it as a success | 01:18 |
| axw | wallyworld_: sorry did I cut you off? | 01:37 |
| axw | sounded like you were saying something when I closed the window | 01:37 |
| wallyworld_ | not all all :-) | 01:37 |
| axw | cool | 01:37 |
| wallyworld_ | nah, i have to learn to shut up more | 01:37 |
| wallyworld_ | i talk too much | 01:38 |
| thumper | wallyworld_: what? no. | 01:38 |
| wallyworld_ | go away | 01:38 |
| * axw grrs at his graphics stack | 01:39 | |
| axw | when I change res, sometimes the screen craps itself and flickers | 01:39 |
| axw | gotta restart... | 01:39 |
| davecheney | ERROR: Failed to merge: {u'documentation_url': u'https://developer.github.com/v3/pulls/#merge-a-pull-request-merge-button', u'message': u'Pull Request is not mergeable'} | 01:42 |
| davecheney | + /home/ubuntu/jenkins-github-lander/bin/lander-merge-result --ini /home/ubuntu/jenkins-github-lander/development.ini '--failure=Merging failed' --pr=88 --job-name=github-merge-juju --build-number=119 | 01:42 |
| davecheney | https://api.github.com/repos/juju/juju/issues/comments/45967167 | 01:42 |
| davecheney | ++ date | 01:42 |
| davecheney | + echo Finished: Fri Jun 13 01:27:54 UTC 2014 | 01:42 |
| davecheney | Finished: Fri Jun 13 01:27:54 UTC 2014 | 01:42 |
| davecheney | + exit 0 | 01:42 |
| davecheney | Description set: davecheney 105-introduce-tags-type-iii | 01:43 |
| davecheney | Finished: SUCCESS | 01:43 |
| davecheney | failed: SUCCESS | 01:43 |
| davecheney | + bash scripts/pre-push.bash | 01:43 |
| davecheney | mongo/prealloc.go:141: missing argument for Debugf verb %q: need 1, have 0 | 01:43 |
| davecheney | + bzr whoami 'Jenkins bot' | 01:43 |
| davecheney | how come this didn't fail the build | 01:43 |
| davecheney | https://bugs.launchpad.net/juju-core/+bug/1329578 | 01:44 |
| _mup_ | Bug #1329578: build: pre-build.bash failures do not fail the build <juju-core:New> <https://launchpad.net/bugs/1329578> | 01:44 |
| axw | davecheney: sorry missed your message before. it failed once, then passed | 01:45 |
| axw | huh | 01:45 |
| axw | didn't see that | 01:45 |
| axw | how come my pre-push script didn't pick it up ... | 01:46 |
| axw | eh, because apparently I never set it. oops | 01:47 |
| axw | davecheney: apparently "go tool vet" returns rc 0 even if it finds that | 01:49 |
| davecheney | :( | 01:50 |
| axw | perhaps we should check for empty output? | 01:51 |
| davecheney | how are you involing it | 01:52 |
| davecheney | go vet $PKG | 01:52 |
| davecheney | gives the right rc | 01:52 |
| davecheney | but we have to use go tool vet to tweak the flags | 01:53 |
| axw | davecheney: it's just a copy of the old .lbox.check, it calls "go tool vet" directly because it wants to set the print funcs | 01:53 |
| davecheney | that is bizarre | 01:53 |
| davecheney | how does go vet know that go tool vet failed | 01:53 |
| axw | nfi | 01:53 |
| axw | oh what | 01:56 |
| axw | davecheney: if you do "go tool vet ." it does something different to "go tool vet *.go" | 01:56 |
| davecheney | :crying: | 01:56 |
| thumper | axw: haha | 02:03 |
| davecheney | ok github.com/juju/juju/environs/sync143.376s | 02:20 |
| davecheney | ^ why does this test take so long to run ? | 02:20 |
| wwitzel3 | just a mere 143 seconds | 02:20 |
| davecheney | it must be one of the only tests that _doesn't_ spin up several mongodb's | 02:20 |
| wwitzel3 | oh I see what you did there | 02:20 |
| wwitzel3 | just to be clear, I have nothing helpful to add .. just peanut gallery | 02:21 |
| davecheney | http://juju-ci.vapour.ws:8080/job/github-merge-juju/121/console | 02:22 |
| davecheney | yay, i crashed mongo | 02:22 |
| davecheney | replica sets, adding instability since 2012 | 02:22 |
| axw | actually looks related to SSL from here | 02:23 |
| axw | maybe both | 02:23 |
| waigani | thumper: sweet! thanks | 02:36 |
| waigani | thumper: I also thought about the DateCreated AND LastConnection being mockable via the user factory | 02:36 |
| davecheney | axw: the results of go test -p 1 ./... | 02:42 |
| davecheney | appear to be ignored by the bot ? | 02:42 |
| davecheney | is that correct ? | 02:42 |
| axw | davecheney: erm, I don't think so? lemme see... | 02:44 |
| axw | davecheney: the script just does "go test ./... || go test -p 2 ./..." | 02:44 |
| davecheney | so if the build fails | 02:45 |
| davecheney | try again faster ? | 02:45 |
| axw | no, try again slower | 02:46 |
| axw | "go test ./..." uses #CPU, which is 4 | 02:46 |
| davecheney | oh, indeed | 02:46 |
| davecheney | ok | 02:46 |
| davecheney | axw: where is the script for the build | 02:56 |
| davecheney | i want to turn off all the -v styel output | 02:56 |
| davecheney | ie, we don't need to spend 2,000 lines on tar xvfz | 02:56 |
| axw | davecheney: embedded in jenkins | 02:57 |
| davecheney | i don't understand why your build failed | 02:57 |
| davecheney | the branch applied and the build worked | 02:57 |
| davecheney | but then when the same merge is done for real | 02:57 |
| davecheney | it fails ? | 02:57 |
| axw | GitHub flaking | 02:57 |
| axw | sometimes the merge just mysteriously fails, then you retry and it works | 02:58 |
| axw | despite the fact that the lander managed to merge the branches fine | 02:58 |
| axw | locally I mean | 02:58 |
| davecheney | exactly | 02:58 |
| davecheney | o_O! | 02:58 |
| davecheney | its happened twice this morning | 02:59 |
| davecheney | i don't accept that git hub is that flakey | 02:59 |
| axw | davecheney: I've taken out the -v from tar extraction | 02:59 |
| davecheney | i think it's a procedural error | 02:59 |
| davecheney | axw: thank you | 02:59 |
| axw | entirely possible, I'm not really familiar with the code that does the merge.. .will take a look and see if it looks suss | 03:00 |
| * axw shrugs | 03:01 | |
| axw | it's just doing a PUT to the merge URL | 03:01 |
| davecheney | so, there must be something different about the way we make the local branch and apply the PR | 03:02 |
| davecheney | and the way that github is trying to merge the PR back onto master | 03:03 |
| axw | mgz and I briefly discussed just doing pushing the merge directly | 03:04 |
| axw | mgz pointed out that we could then "go fmt" the code before landing | 03:04 |
| axw | we could also add coverage data to the repo in that way | 03:05 |
| davecheney | +1 tasty | 03:05 |
| axw | github and/or jenkins must hate me | 03:29 |
| * thumper EOWs | 04:33 | |
| === vladk|offline is now known as vladk | ||
| fwereade | wallyworld_, couple more comments on the PR -- still not convinced by those refreshes | 05:56 |
| wallyworld_ | fwereade: do you agree that they were called previously? | 05:56 |
| fwereade | wallyworld_, no | 05:56 |
| fwereade | wallyworld_, I think they were only called on ErrAborted | 05:56 |
| fwereade | wallyworld_, the usual pattern is if err := runtxn(); err != ErrAborted { return err } | 05:57 |
| wallyworld_ | fwereade: oh, hang on, maybe i'm being totally stupid | 05:57 |
| wallyworld_ | sigh, i think i am | 05:58 |
| wallyworld_ | ffs | 05:58 |
| fwereade | wallyworld_, no worries, those constructs are a bit tangled | 05:58 |
| wallyworld_ | sorry | 05:58 |
| * wallyworld_ goes to kick the dog | 05:59 | |
| fwereade | wallyworld_, it just means the code can get a bit simpler | 05:59 |
| * fwereade feels like an accessory to animal cruelty | 05:59 | |
| wallyworld_ | yeah, still doesn't absolve my stupidity | 05:59 |
| fwereade | wallyworld_, oh bollocks | 05:59 |
| fwereade | wallyworld_, the benefit of factoring that package out absolves far worse | 05:59 |
| wallyworld_ | i am looking forward to being able to use it | 06:00 |
| wallyworld_ | fwereade: was the bollocks for a bad reason? | 06:01 |
| fwereade | wallyworld_, I was expostulating violently at you beating yourself up for imo inadequate reasons | 06:02 |
| wallyworld_ | well, fsvo inadequate :-) | 06:02 |
| wallyworld_ | thanks for the review though, was a bigun | 06:03 |
| fwereade | wallyworld_, quickly searching through I think we're actually behaving noticeably better now because all the refreshes seem to be in `if attempt != 0` branches now | 06:04 |
| fwereade | wallyworld_, (once the others are droped anyway) | 06:05 |
| wallyworld_ | yup | 06:05 |
| fwereade | wallyworld_, one quick thought (don't do it now) | 06:05 |
| fwereade | wallyworld_, we're not really using attempt, just attempt != 0 | 06:05 |
| wallyworld_ | um, i think there's a place where we are | 06:06 |
| fwereade | wallyworld_, gut feel on (firstAttempt bool) vs (attempt int)? | 06:06 |
| fwereade | wallyworld_, ah ok then | 06:06 |
| wallyworld_ | attempt ==1 is somewhere | 06:06 |
| wallyworld_ | only one place | 06:06 |
| fwereade | wallyworld_, must have missed it | 06:06 |
| fwereade | wallyworld_, disregard :) | 06:06 |
| wallyworld_ | ok :-) | 06:06 |
| wallyworld_ | fwereade: i'm currently fixing a nasty goose json bug which fucks up our floating ip usage for hp cloud. so i'll land soon | 06:06 |
| fwereade | wallyworld_, sweet | 06:07 |
| wallyworld_ | and i got a meeting soonish as well | 06:07 |
| fwereade | wallyworld_, no rush | 06:08 |
| wallyworld_ | yeah, i'm the only one who needs it right now :-) | 06:08 |
| fwereade | wallyworld_, I'm just happily imagining all the nice stuff we'll be able to do more easily in future | 06:08 |
| wallyworld_ | yep | 06:08 |
| fwereade | wallyworld_, backoff from failed txns | 06:08 |
| wallyworld_ | like internal storag | 06:08 |
| wallyworld_ | yep, that too | 06:09 |
| fwereade | wallyworld_, even a txn type so we can detect and reject ops for the same doc -- or at least combine them all | 06:09 |
| wallyworld_ | would be nice | 06:09 |
| fwereade | wallyworld_, not to mention cleanly adding metrics like txn spread, time to execute, number of retries | 06:10 |
| wallyworld_ | indeed | 06:10 |
| fwereade | axw, ping | 06:10 |
| axw | fwereade: pong | 06:13 |
| fwereade | axw, maas 1.5 supports zones, we should do that too -- did I miss it? | 06:16 |
| axw | fwereade: just haven't gotten to it yet | 06:17 |
| axw | wasn't sure if it was ranked as important yet | 06:17 |
| fwereade | axw, cool | 06:17 |
| fwereade | axw, I think it is | 06:17 |
| axw | okey dokey, I shall add a card | 06:17 |
| fwereade | axw, maas is pretty much the flagship provider for a whole bunch of use cases | 06:18 |
| axw | I'm sure it'll be important to people building OpenStack clouds | 06:18 |
| fwereade | axw, yeah | 06:18 |
| axw | (on top of MAAS) | 06:18 |
| fwereade | axw, another thing, btw -- and this is probably a bit big to charge to the azs work, but we need to think about it | 06:20 |
| fwereade | axw, azs, instance types, and networks all affect constraint validity | 06:21 |
| fwereade | axw, it would be really good if we could expose an api that lists the choices for those things | 06:21 |
| axw | fwereade: heh :) was talking about this with wallyworld before | 06:22 |
| fwereade | axw, so that the gui can have dropdowns/checkboxes/whatever | 06:22 |
| axw | there's a card for instance types already | 06:22 |
| wallyworld_ | fwereade: there's a plan for it | 06:22 |
| axw | I figured we'd want it for placement directives like AZs too | 06:22 |
| fwereade | axw, wallyworld_: you rock :) | 06:22 |
| wallyworld_ | fwereade: i've discussed with gui guys | 06:22 |
| axw | fwereade: not sure how AZs affect constraints though? | 06:22 |
| wallyworld_ | fwereade: there will be a new client API call returning a struct containing inst types, availability zones, and possibly env constraints etc | 06:23 |
| fwereade | axw, ha, not constraints for azs, you're right | 06:23 |
| axw | regardless, it'll be nice to be able to list them | 06:23 |
| fwereade | axw, although... hmm... why *shouldn't* we do az constraints? | 06:23 |
| axw | I thought you didn't want to :) | 06:24 |
| fwereade | axw, I know this is feature creep, I'm not necessarily asking for us to do it now | 06:24 |
| axw | fwereade: hazmat wants them though | 06:24 |
| fwereade | axw, just trying to figure out if it's a good idea and we should pre-emptively add a lets-do-it-one-day bug for it | 06:24 |
| fwereade | axw, ha, ok, that's generally good enough for me | 06:24 |
| fwereade | axw, am I right in thinking that joyent doesn't support azs? | 06:25 |
| axw | fwereade: IIRC, CloudFoundry has some components that want to be partitioned across AZs | 06:25 |
| axw | I have no idea, haven't looked | 06:25 |
| * axw looks | 06:25 | |
| fwereade | axw, I just poked around quickly, couldn't see anything | 06:25 |
| axw | okey dokey | 06:25 |
| fwereade | axw, re cloudfoundry -- so we're ideally looking for something like 2 services, 4 azs, non-overlapping spread? | 06:33 |
| fwereade | axw, ha, now I remember why I don't want zone constraints | 06:33 |
| fwereade | axw, I want near/far, not explicit zones | 06:33 |
| axw | fwereade: I don't know the specifics. I was under the impression that services were tied to a single AZ | 06:33 |
| fwereade | axw, oh ok, that's interesting | 06:33 |
| * fwereade probably needs to know more about cloudfoundry :/ | 06:34 | |
| axw | i.e. all units of one service in one AZ, all units of another service in another | 06:34 |
| axw | need to chat with hazmat more about it | 06:34 |
| davecheney | urgh | 06:35 |
| davecheney | FAIL: run_test.go:269: RunSuite.TestAllMachines | 06:35 |
| davecheney | run_test.go:293: c.Check(testing.Stdout(context), gc.Equals, string(jsonFormatted)+"\n") | 06:35 |
| davecheney | ... obtained string = "[{\"Error\":\"command timed out\",\"MachineId\":\"1\",\"Stdout\":\"\"},{\"MachineId\":\"0\",\"Stdout\":\"megatron\\n\"}]\n" | 06:35 |
| davecheney | ... expected string = "[{\"MachineId\":\"0\",\"Stdout\":\"megatron\\n\"},{\"Error\":\"command timed out\",\"MachineId\":\"1\",\"Stdout\":\"\"}]\n" | 06:35 |
| davecheney | OOPS: 233 passed, 1 FAILED | 06:35 |
| davecheney | --- FAIL: TestPackage (155.82 seconds) | 06:35 |
| davecheney | FAIL | 06:35 |
| davecheney | FAIL github.com/juju/juju/cmd/juju 155.991s | 06:35 |
| wallyworld_ | axw: can i bother you for a review to fix one of the 1.19.4 bugs? i'll update and land the dependencies fix after goose is sorted https://codereview.appspot.com/105180043 | 06:44 |
| axw | no worries | 06:44 |
| axw | wallyworld_: reviewed | 06:49 |
| wallyworld_ | thanks | 06:49 |
| wallyworld_ | axw: is there a branch for the azure card? | 06:50 |
| axw | wallyworld_: which one? | 06:51 |
| wallyworld_ | bug 1324910 | 06:51 |
| _mup_ | Bug #1324910: azure destroy-environment does not complete <azure-provider> <destroy-environment> <juju-core:Triaged> <https://launchpad.net/bugs/1324910> | 06:51 |
| axw | wallyworld_: no branch, I only just started looking | 06:51 |
| wallyworld_ | ah ok, it was iin the review lane | 06:51 |
| axw | oops | 06:51 |
| wallyworld_ | :-) | 06:51 |
| axw | thanks | 06:51 |
| voidspace | morning all | 07:13 |
| axw | morning | 07:14 |
| voidspace | o/ | 07:17 |
| mattyw | morning all | 07:19 |
| TheMue | morning all o/ | 07:35 |
| === psivaa-afk is now known as psivaa | ||
| wallyworld_ | axw: trivial https://github.com/juju/juju/pull/90 | 08:20 |
| axw | looking | 08:20 |
| TheMue | hehe, really trivial | 08:20 |
| axw | wallyworld_: done | 08:21 |
| wallyworld_ | thanks :-) | 08:21 |
| wallyworld_ | axw: i have no soccer tonight so if mgz is around we can do a standup in 40 mins if you are free | 08:21 |
| axw | wallyworld_: sure, I think I will be | 08:22 |
| wallyworld_ | ok | 08:22 |
| * fwereade off in a minute for a swim and a think, does anyone need me for anything? | 08:25 | |
| wallyworld_ | nah | 08:27 |
| TheMue | enjoy swimming | 08:27 |
| wallyworld_ | axw: looking at the bot, there's a fucktonne of blue dots :-) | 08:28 |
| axw | :) | 08:28 |
| axw | wallyworld_: I'm getting a fucktonne of spurious "cannot merge" errors though :( | 08:28 |
| wallyworld_ | oh :-( | 08:28 |
| wallyworld_ | let's talk to mgz at standup | 08:29 |
| voidspace | bloodearnest: morning | 09:20 |
| bloodearnest | bloodearnest: heya | 09:20 |
| bloodearnest | voidspace: heya, even :) | 09:21 |
| mattyw | axw, ping? | 09:21 |
| axw | mattyw: yo | 09:21 |
| voidspace | bloodearnest: :-) | 09:21 |
| mattyw | axw, I've added the charm link https://github.com/juju/juju/pull/80. Shall we land it or think of a better summary? | 09:22 |
| axw | mattyw: land it, hopefully someone will think of something better after seeing it ;) | 09:23 |
| mattyw | axw, I seem to remember there was a thread on one of the mailng lists 18 months ago that tried to come up with a decent summary, but I couldn't find it | 09:25 |
| axw | *shrug* I wasn't here 18 months ago :) | 09:26 |
| dimitern | mattyw, hey | 09:39 |
| dimitern | mattyw, do we still need to discuss port ranges tasks? | 09:40 |
| mattyw | dimitern, sorry totally forgot | 09:41 |
| mattyw | dimitern, yeah lets do it | 09:41 |
| dimitern | mattyw, ok, i'm joining | 09:41 |
| mattyw | fwereade, https://github.com/juju/juju/pull/64 is this what you had in mind? | 10:32 |
| TheMue | dimitern: standup | 10:48 |
| perrito666 | morning | 10:49 |
| dimitern | TheMue, brt, sorry | 10:50 |
| perrito666 | rogpeppe1: tx again :) | 11:15 |
| voidspace | perrito666: morning | 11:16 |
| rogpeppe1 | perrito666: np - it's looking loads better | 11:16 |
| rogpeppe1 | perrito666: BTW i introduced some folks to backgammon at the pub last night... | 11:16 |
| perrito666 | axw: btw, I noticed the 2013/2014 issue, I let 2013 because lots of new code seems to have 2013 perhaps this is something we should address too? | 11:17 |
| perrito666 | rogpeppe1: and backgammon is not an euphemism for your fist being drunk right? :p | 11:17 |
| perrito666 | rogpeppe1: you are a bg evangelist | 11:17 |
| rogpeppe1 | perrito666: i kind of am, but i actually haven't played in months. i just saw that the pub had a set. | 11:18 |
| axw | perrito666: if it's code that started in 2013 then that's fine, but this is all new isn't it? | 11:18 |
| perrito666 | axw: it is | 11:18 |
| voidspace | actually enjoying writing tests | 11:19 |
| voidspace | it turns out this particular piece of code I'm working on is testable | 11:19 |
| perrito666 | voidspace: lol | 11:19 |
| voidspace | :-) | 11:19 |
| voidspace | and I'm getting to use the os / ioutil / path libraries | 11:19 |
| voidspace | always a good part of a language's standard library to be familar with | 11:19 |
| perrito666 | rogpeppe1: the strip parameter is to emulate -C in gnutar it is stripped from the h.Name | 11:20 |
| rogpeppe1 | perrito666: but you don't use it, right? | 11:20 |
| perrito666 | I do, if I dont I screwed the merge | 11:20 |
| * perrito666 checks | 11:20 | |
| perrito666 | line 59 | 11:21 |
| rogpeppe1 | perrito666: that's just passing the strip parameter through, though AFAICS | 11:21 |
| rogpeppe1 | perrito666: but it's always empty | 11:21 |
| * perrito666 finds a bit odd that there is path.Join and filepath.Join | 11:21 | |
| rogpeppe1 | perrito666: path is forward-slash-separated paths | 11:22 |
| perrito666 | rogpeppe1: nope, when building the tar.gz it strips the tempdir path | 11:22 |
| rogpeppe1 | perrito666: filepath is OS-dependant | 11:22 |
| perrito666 | mm, that is a useful piece of advice | 11:22 |
| * perrito666 tries the hard task of finding a movie theater that broadcasts x-men in English | 11:24 | |
| rogpeppe1 | perrito666: ah, got it. in which case, why not get rid of line 78? | 11:24 |
| rogpeppe1 | perrito666: and pass "/" in where currently you pass "" | 11:25 |
| perrito666 | rogpeppe1: yup, makes a lot of sense | 11:25 |
| rogpeppe1 | perrito666: one other thing - you should probably use filepath.ToSlash for the file name you store in the tar | 11:26 |
| rogpeppe1 | perrito666: so that even if we're generating a tar file on windows, the files will look normal | 11:26 |
| perrito666 | rogpeppe1: will that work when untaring on windows? | 11:26 |
| rogpeppe1 | perrito666: if it didn't, you'd never be able to untar any tar file on windows :-) | 11:27 |
| rogpeppe1 | perrito666: so, yes, i think so | 11:27 |
| perrito666 | rogpeppe1: to be honest.. I never tried to untar on windows | 11:27 |
| perrito666 | :p | 11:27 |
| rogpeppe1 | perrito666: i probably have :-) | 11:27 |
| rogpeppe1 | perrito666: tbh none of the /var/lib/juju paths will work in windows, so it's all pretty academic | 11:28 |
| perrito666 | I have been using either osx or linux since .. well since like a ton of years, I recall using xp as my desktop when It jut came out for a few months and then that was it | 11:28 |
| voidspace | I think the tests are done for the backup downloading (server side) | 11:29 |
| perrito666 | rogpeppe1: I know, that is why the pat is set up there, I guess that if we try to run in windows we will have some convenience getter for that | 11:29 |
| voidspace | now for the client side implementation | 11:29 |
| rogpeppe1 | perrito666: yeah, you could have the getFiles implementation forked, one for each platform in two files | 11:29 |
| perrito666 | rogpeppe1: from the tests of archive/tar on the go source I cannot find a clear way to actually untar those into the hd, specially directories, have you ever done it? | 11:32 |
| rogpeppe1 | perrito666: you don't have to untar to disk | 11:33 |
| rogpeppe1 | perrito666: just read the contents (for files) | 11:33 |
| rogpeppe1 | perrito666: see io.ReadAll | 11:33 |
| perrito666 | rogpeppe1: well, the restore part wich Ill write after I fix your comments says otherwise :p | 11:34 |
| rogpeppe1 | perrito666: ah, i see | 11:34 |
| rogpeppe1 | perrito666: i thought you were talking about checking contents | 11:34 |
| perrito666 | rogpeppe1: nope, that is pretty much clear, I just need to add contents to these files | 11:35 |
| perrito666 | :p | 11:35 |
| rogpeppe1 | perrito666: the current restore plugin shows how you can extract files from a tar file in go | 11:37 |
| perrito666 | rogpeppe1: really? | 11:38 |
| rogpeppe1 | perrito666: well, it doesn't bother to actually extract them to disk, it's true | 11:39 |
| rogpeppe1 | perrito666: it should be relatively straightforward to write a tar file extraction function | 11:39 |
| rogpeppe1 | perrito666: there might be one already around somewhere | 11:40 |
| rogpeppe1 | perrito666: but it's just a matter of iterating through the contents, creating and writing each file in turn | 11:40 |
| perrito666 | rogpeppe1: I am not sure how to handle directories, I did google a bit but found nothing, everyone seems to be happy enough with buffer | 11:40 |
| rogpeppe1 | perrito666: if there's an explicit dir entry, mkdir it, otherwise MkdirAll the file's directory before writing the file | 11:41 |
| perrito666 | ok, tx | 11:42 |
| rogpeppe1 | does anyone know anything about the juju local plugin? | 12:12 |
| rogpeppe1 | i can't see that it does anything | 12:12 |
| rogpeppe1 | the only substantive logic in there is runAsRoot, but AFAICS that never gets called | 12:13 |
| === vladk is now known as vladk|offline | ||
| rogpeppe1 | i guess it might be a place holder for future stuff | 12:17 |
| rogpeppe1 | fwereade, dimitern, jam: any idea? | 12:17 |
| jam1 | rogpeppe1: thumper was working on it as a namespace for the local provider tweaks he wanted to do | 12:18 |
| jam1 | IIRC he wanted to be able to refresh the LXC templates | 12:18 |
| jam1 | though now we cache on all providers | 12:18 |
| jam1 | which means just having it in "local" isn't good enough | 12:18 |
| jam1 | rogpeppe1: so either it isn't complete yet, or its functionality got moved out | 12:18 |
| jam1 | (I'm personally not a fan of putting that into a plugin vs core functionality, but thumper likes it) | 12:19 |
| rogpeppe1 | jam1: ok, thanks | 12:20 |
| rogpeppe1 | jam1: one other thing: do you know why it was split into two packages rather than just having one main package like all the other commands? | 12:21 |
| jam1 | no idea | 12:21 |
| rogpeppe1 | jam1: ta | 12:22 |
| fwereade | rogpeppe1, I would guess that it's because he shares my opinion that the single-main-package thing is a horrible antipattern :) | 12:30 |
| rogpeppe1 | fwereade: i don't see how factoring out the one-line main() function helps | 12:30 |
| rogpeppe1 | fwereade: if the package being imported was actually useful to be used from Go, i might agree | 12:31 |
| rogpeppe1 | fwereade: but the difference between func Main and func main seems trivial to me | 12:31 |
| fwereade | rogpeppe1, it means that (1) all the code is easily accessible from elsewhere without weirdness, so it's a good habit independent of whether the code in a given command is currently obviously useful from elsewhere; and (2) it turns in-package testing into a shameful fallback, as it should be, rather than a necessity ;p | 12:33 |
| rogpeppe1 | fwereade: if Main didn't call os.Exit, i might possibly agree to (1). but it does - packages should be written to be useful to call from Go. just separating main from Main doesn't help anyone. | 12:35 |
| fwereade | rogpeppe1, fair point there, sure | 12:35 |
| fwereade | rogpeppe1, I think that's just an argument that part of it is in the wrong package, rather than an argument against spltting packages, though | 12:36 |
| rogpeppe1 | fwereade: and about in-package testing... really, who cares? for main packages, all the stuff you're going to be testing is likely to be internal anyway | 12:36 |
| rogpeppe1 | fwereade: i'm totally up for factoring out useful functionality from main packages | 12:37 |
| rogpeppe1 | fwereade: but splitting them just "because" just adds obfuscation | 12:37 |
| fwereade | rogpeppe1, if you need internal testing, your packages are probably too big ;) | 12:37 |
| rogpeppe1 | fwereade: i don't think all the grubby implementation details of a package are always worth factoring out. it's nice to hide things. but they may very well be worth testing. | 12:38 |
| fwereade | rogpeppe1, I dunno, the ideal code is lasagna, but given a choice between spaghetti and ravioli I've generally found the latter to be more palatable | 12:39 |
| mattyw | does anyone know why this might be failing? http://juju-ci.vapour.ws:8080/job/github-merge-juju/138/console | 12:40 |
| rogpeppe1 | fwereade: we can bake lasagna within packages too :-) | 12:40 |
| fwereade | rogpeppe1, IME that doesn't work -- without the language helping you to enforce the boundaries, it invariably degrades spaghettiwards | 12:41 |
| fwereade | rogpeppe1, even super-strong convention like python's _field members doesn't seem to actually help | 12:41 |
| fwereade | rogpeppe1, it does help a *little* but the temptation to violate layers is strong for the programmer in a hurry | 12:42 |
| rogpeppe1 | fwereade: if people want to violate layers, they'll do it regardless of package boundaries. hiding implementation details inside a well defined package boundary is good for avoiding needless reliance of external code on internal details | 12:43 |
| === psivaa is now known as psivaa-afk | ||
| fwereade | rogpeppe1, right, but without package boundaries people are often not aware that the layers even exist to be violated | 12:45 |
| rogpeppe1 | fwereade: internal types are a pretty good indication | 12:45 |
| fwereade | rogpeppe1, even the careful and conscientious programmer-in-a-hurry is susceptible to perpetrating that sort of breakage | 12:45 |
| rogpeppe1 | fwereade: there are many forms of breakage that we can do at any time :-) | 12:46 |
| fwereade | rogpeppe1, sure, I'm arguing from anecdotal evidence: I have spent a lot of my life rolling my eyes at many forms of bad code -- not to mention writing plenty of it myself -- and ISTM that failing to take advantage of the encapsulation constructs available is the root of an awful lot of avoidable evil | 12:49 |
| fwereade | rogpeppe1, that go only offers package boundaries is not *necessarily* a strike against go, but it does constrain the forms that long-term-robust code can actually take | 12:50 |
| rogpeppe1 | fwereade: it's a trade-off, as usual. making packages with no decently explainable reasons for existing is another way to make spaghetti code that's really hard to fathom IME. | 12:50 |
| fwereade | rogpeppe1, that's the ravioli code metaphor I think | 12:50 |
| fwereade | rogpeppe1, hundreds of tiny things with hardly any meat in | 12:50 |
| fwereade | rogpeppe1, long-term, it's *much* easier to deal with than spaghetti is | 12:51 |
| fwereade | rogpeppe1, possibly this is just because all the boundaries make it harder to spaghettify | 12:51 |
| fwereade | rogpeppe1, so after N years of maintenance there's still *some* structure discernible | 12:52 |
| rogpeppe1 | fwereade: i think it just makes for spaghetti at another level | 12:52 |
| rogpeppe1 | fwereade: for me, the key thing is strong, useful abstractions | 12:52 |
| rogpeppe1 | fwereade: then you can understand why a package exists and how you might change it to do what you want without compromising external clients. | 12:53 |
| rogpeppe1 | fwereade: in all honesty, i don't think we suffer much from violation of intra-package boundaries in juju. the most egregious violations of boundaries that i've seen have been cross-package. | 12:56 |
| bodie_ | if I could get a LGTM on this, it would be fantastic! https://github.com/juju/charm/pull/4 | 13:01 |
| bodie_ | also, good morning all | 13:01 |
| mattyw | has anyone ever seen the 'Pull Request is not mergeable' error from the github-lander? | 13:09 |
| mattyw | I can't see a reason why the request isn't landable | 13:09 |
| rogpeppe1 | anyway, i strongly disagree that if it's worth testing a function, it's worth exporting it from another package. a package is often built from quite a few functions that make sense only within the context of that package and operate on types and concepts that are really internal implementation details. an example is desiredPeerGroup in worker/peergrouper. it's very useful to be able to test it directly, but it only makes sense in the | 13:09 |
| rogpeppe1 | context of what the rest of the package is doing. | 13:09 |
| fwereade | rogpeppe1, I'm not saying internal tests are *never* a good idea | 13:10 |
| rogpeppe1 | [13:37:39] <fwereade> rogpeppe1, if you need internal testing, your packages are probably too big ;) | 13:11 |
| natefinch | it's often way way WAY easier to test a single internal function than it is to test a huge external function. A failure from a test against a very small internal function is a hell of a lot easier to understand than a failure from a huge external function. | 13:11 |
| fwereade | rogpeppe1, I would say they *are* a code smell, though -- an indication that something's probably a bit off | 13:11 |
| fwereade | rogpeppe1, closer inspection may reveal that everything's really fine | 13:11 |
| rogpeppe1 | fwereade: the only thing that's "off" about them is IMO is that it makes it harder to refactor the code because your tests are dependant on internal implementation details to some extent. | 13:12 |
| natefinch | fwereade: I disagree completely. There are lots of individual bits of logic that you can test in isolation which can help you when you're editing/refactoring later. | 13:12 |
| fwereade | natefinch, yeah, agreed there -- I'd just usually rather put a couple of helper packages behind the outward-facing one, and have properly segregated tests against theose | 13:12 |
| rogpeppe1 | fwereade: but that's not made any better by factoring out the code | 13:12 |
| rogpeppe1 | fwereade: because they're implementation details whether they're in a separate package or not | 13:13 |
| natefinch | fwereade: except that then you have exposed logic that should only be an implementation detail, but now other developers will be tempted to use it | 13:13 |
| fwereade | natefinch, you've written a package which is the language in which another package is written | 13:13 |
| fwereade | natefinch, ratherthan embedding the implementation language in the implementation | 13:13 |
| rogpeppe1 | fwereade: that makes sense *if* that language is coherent in itself | 13:14 |
| fwereade | rogpeppe1, and so it should be..? | 13:14 |
| rogpeppe1 | fwereade: but if it's just an implementation detail, it often makes sense only in the package that's doing the implementation | 13:15 |
| natefinch | fwereade: it just breaks encapsulation... and many times, the implementation details are not something you want anyone else to get access to, so you can freely refactor later. If they're exposed, then you have to worry about maintaining compatibility with other packages that use them | 13:15 |
| rogpeppe1 | natefinch: fwereade is concerned about inappropriate access to parts of that implementation from within the package. | 13:15 |
| fwereade | natefinch, I'd rather take the risk code-sharing than giant overgrown packages ;p | 13:15 |
| fwereade | natefinch, yes, it demands a bit of extra effort to build the layers in the right places | 13:16 |
| rogpeppe1 | natefinch: and i can see that p.o.v. too - for instance (to continue with worker/peergrouper) some other part of the package *could* call one of the other functions inside desired.go. | 13:16 |
| fwereade | natefinch, but IME the more clients you have the better-factored the code generally is, but the causal relationship is not entirely clear | 13:17 |
| rogpeppe1 | natefinch: but tbh i don't see that as a significant risk | 13:17 |
| bodie_ | at the last place I worked, we used to have 4-hour yelling arguments in the conference room. I much prefer this style ^_^ | 13:17 |
| fwereade | bodie_, haha | 13:17 |
| wwitzel3 | my love of corkscrew pasta has doomed me to always writing poor code. | 13:18 |
| fwereade | wwitzel3, lol | 13:18 |
| rogpeppe1 | lol | 13:18 |
| rogpeppe1 | using Go packages like java name spaces is not a great fit IMO. | 13:20 |
| fwereade | natefinch, rogpeppe1: anyway, I'm worried that I'm not making myself clear -- I understand the risks you cite, I'm just saying that I'd rather [err towards small packages and risk inappropriate reuse of incomplete abstractions] than [err towards large packages and risk spaghetti behind clean, but large, boundaries] because I have generally found it easier to unfuck systems that made the former mistake | 13:21 |
| fwereade | natefinch, rogpeppe1: I'm certainly not saying my approach can't go wrong | 13:22 |
| rogpeppe1 | personally i'd prefer to err towards packages with small boundaries that encapsulate useful functionality, even if that internal implementation might get big sometimes | 13:22 |
| fwereade | natefinch, rogpeppe1: everything goes wrong | 13:22 |
| fwereade | rogpeppe1, natefinch: https://twitter.com/DEVOPS_BORAT/status/224171832771739648 | 13:23 |
| rogpeppe1 | i think one can easily have a package with a significantly sized implementation that nonetheless has a small API | 13:23 |
| bodie_ | fwereade, on that note, I now have a reasonably good JSON-Schema validator and YAML grinder-into-suitable-format and I'm thinking about how it might be useful for charm Config | 13:23 |
| fwereade | bodie_, I heartily endorse that direction, but not at the moment :) | 13:24 |
| bodie_ | right now, those things are members of charm Actions, the grinder is an unexported method | 13:24 |
| rogpeppe1 | many things in the stdlib are a good example of that | 13:24 |
| bodie_ | was thinking about whether that stuff needs to be its own bit in Charm, or where it would belong | 13:24 |
| gnuoy | Hi, I'm having my first go at compiling juju (1.18) from src. After "go get -v launchpad.net/juju-core/1.18/..." I'm moving the content of the 1.18 dir up one into juju-core otherwise go install seems unable to find anything. After doing that install fails due to missing src/github.com/juju/testing/logging, so I grabbed those files from old revision. After doing that install fails with "utils/ssh/ssh_gocrypto.go:77: undefined: ssh.ClientConn". I can't | 13:25 |
| gnuoy | help but feel I'm doing something fundamentally wrong here | 13:25 |
| fwereade | bodie_, I would personally consider each of those pieces to be a viable small package | 13:25 |
| bodie_ | gnuoy, I think what you want to do is rm -rf launchpad.net/juju-core and go get -u -v github.com/juju/juju/... | 13:26 |
| bodie_ | it's moved to github :) | 13:26 |
| fwereade | gnuoy, if you need 1.18, moving the branch up a level is right; but you need to run `godeps -u dependencies.tsv` as well to get the right packages | 13:26 |
| bodie_ | although, I'm not totally certain where to go for the versioned historic branches | 13:26 |
| bodie_ | pay attention to fwereade | 13:27 |
| gnuoy | bodie_, achk :) | 13:27 |
| gnuoy | fwereade, thanks | 13:27 |
| fwereade | gnuoy, most of what you need to know should be in CONTRIBUTING and README | 13:28 |
| mattyw | mgz, ping? | 13:28 |
| gnuoy | fwereade, ok, thank you | 13:28 |
| bodie_ | fwereade, on a side note, I've updated some code in my gojsonschema dependency -- does that mean I need to push out a tweak to dependencies.tsv and tell people they need to re-up on their deps? | 13:28 |
| mgz | mattyw: hey | 13:29 |
| fwereade | bodie_, yeah, although it probably doesn't demand a specific message, running godeps is just a habit one needs to develop, I think | 13:29 |
| mgz | gnuoy: you just need to run godeps on the branch, which is in CONTRIBUTING | 13:32 |
| mgz | gnuoy: 1.18 is on launchpad still | 13:32 |
| gnuoy | mgz, ta | 13:33 |
| mattyw | mgz, for the purposes of this conversation you're responsible for github and jenkins - ok? | 13:33 |
| mgz | mattyw: okay :) | 13:34 |
| mattyw | mgz, any idea what the pull request not mergable error is all about? http://juju-ci.vapour.ws:8080/job/github-merge-juju/138/console | 13:34 |
| mattyw | mgz, only it seems mergable to me - it's only a trivial change to the readme | 13:34 |
| mgz | mattyw: as best I can tell it's the github api being weird, just retrying often seems to work | 13:34 |
| mattyw | mgz, I'll try again - thanks :) | 13:35 |
| mgz | mattyw: the only other thing to check is if it merges cleanly into trunk, but I expect it does | 13:35 |
| mattyw | mgz, just in case my git foo isn't good enough - I did a git merge master on my local branch - and master is up to date with trunk - and that all worked | 13:36 |
| bodie_ | mgz / fwereade -- so, I have some new code in juju/charm that has an updated dependency requirement, but I noticed the dependencies.tsv is in juju/juju | 13:36 |
| bodie_ | I just became aware that that could pose a problem | 13:37 |
| mgz | rogpeppe1: ^ | 13:37 |
| mgz | what's our solution to new subpackages that have dep requirements? | 13:37 |
| bodie_ | I'm guessing I just need to put the updated dep in juju/juju | 13:37 |
| bodie_ | but, it seems a little clunky | 13:37 |
| bodie_ | then again, dep management in go seems... a little clunky ;) | 13:38 |
| mgz | mattyw: the bot did successfully merge your branhc into tip, so it's an ongoing mystery why github is failing with that error sometimes | 13:38 |
| voidspace | perrito666: how far off merging is your branch? | 13:38 |
| rogpeppe1 | bodie_: yeah, in general only main specifies deps | 13:38 |
| voidspace | perrito666: I think mine (well - the first of mine) is ready to be integrated with yours | 13:38 |
| rogpeppe1 | bodie_: otherwise you can get conflicting deps | 13:38 |
| bodie_ | ah | 13:39 |
| bodie_ | that makes sense | 13:39 |
| rogpeppe1 | bodie_: the real solution to this particular problem is to export stable APIs | 13:39 |
| mattyw | mgz, I can't see it in tip | 13:39 |
| mattyw | mgz, and https://github.com/juju/juju the readme is still old | 13:39 |
| rogpeppe1 | bodie_: then you can go get -u with impunity | 13:39 |
| mgz | mattyw: I'm not saying it landed | 13:39 |
| mattyw | mgz, oh right | 13:40 |
| mgz | I'm saying the *bot* managed to do the merge in order to run the tests, so the merge itself shouldn't be the reason github failed the merge itself at the end | 13:40 |
| rogpeppe1 | bodie_: that's something we should really do for all our packages under github.com/juju, perhaps excepting juju core itself | 13:40 |
| mattyw | mgz, nice, well I tried it again, 3rd time's the charm I guess | 13:40 |
| mgz | one option if this continues to be a pain is to drop using the github api here and get the bot to commit/push/etc | 13:40 |
| bodie_ | rogpeppe1, not sure I'm following -- I made a tweak to gojsonschema to get a subset of functionality working properly, so the API I'm exporting definitely depends on that fix | 13:41 |
| bodie_ | now I'm worrying about whether there will be more such cases | 13:41 |
| bodie_ | obviously I don't want to keep forcing dep updates | 13:41 |
| rogpeppe1 | bodie_: it sounds like this is basically a bug fix to gojsonschema, right? | 13:42 |
| rogpeppe1 | bodie_: not a backwardly incompatible change | 13:42 |
| bodie_ | yeah, but tests won't pass on charm without the fix | 13:43 |
| bodie_ | so... not totally backward compatible with our test base | 13:44 |
| bodie_ | s/totally/ | 13:44 |
| bodie_ | // | 13:44 |
| rogpeppe1 | bodie_: that's fine. go get -u will fix it, and because it's backwardly compatible, won't break anything else that's importing gojsonschema | 13:44 |
| rogpeppe1 | bodie_: in general, we should test against the latest version of a package | 13:45 |
| gnuoy | mgz, assuming the "no version control" messages are just warning the dep process completed without error http://paste.ubuntu.com/7638931/ but the undefined: ssh.ClientConn error is still present when trying to do an install | 13:46 |
| bodie_ | rogpeppe1, okay, so I can basically update the dependency willy-nilly as long as I'm not changing the API significantly / in such a way that builds will fail? | 13:46 |
| rogpeppe1 | bodie_: yup | 13:46 |
| mgz | gnuoy: you're doing it the wrong way round :) | 13:46 |
| bodie_ | rogpeppe1, but, shouldn't that be in dependencies.tsv? | 13:46 |
| mgz | you *have* a dependencies.tsv in the juju-core branch, you want to make the other branches match that, which is `godeps -u ...` | 13:47 |
| mgz | not - t | 13:47 |
| rogpeppe1 | bodie_: see http://labix.org/gopkg.in for an explanation of how to maintain backward compatibility | 13:47 |
| gnuoy | mgz, ah, ok | 13:47 |
| mgz | so, un-overwrite the deps, and just do the -u | 13:47 |
| rogpeppe1 | bodie_: if every repo has its own dependencies.tsv, which one do you believe? | 13:48 |
| bodie_ | heh | 13:48 |
| mgz | you probably still need a go get first, use the -d flag on that | 13:48 |
| rogpeppe1 | bodie_: IMO, the only decent place to specify dependencies is at the root (i.e. in main packages) | 13:48 |
| perrito666 | voidspace: working a re-reproposal | 13:49 |
| mgz | gnuoy: so, `cd juju-core && go get -v -d ./... && godeps -u dependencies.tsv` | 13:49 |
| voidspace | perrito666: heh, you'll be happy to finally get this in! | 13:50 |
| gnuoy | tbh it looked to me like go get was doing all the dependency handling | 13:50 |
| bodie_ | rogpeppe1, good link re. gopkg :) | 13:50 |
| rogpeppe1 | bodie_: and if you combine that with maintaining stable APIs, we should find that a) all dependencies should build and test ok against (at least) the latest version of their deps and b) we can have reproducible builds of our binaries | 13:50 |
| gnuoy | mgz, all compiled and happy, thank yo | 13:57 |
| * fwereade needs to be away, on later tonight | 13:58 | |
| mgz | gnuoy: ace | 14:00 |
| voidspace | ericsnow: this is the initial prototype of the api client Backup method | 14:14 |
| voidspace | ericsnow: https://github.com/voidspace/juju/compare/backup-client#diff-e3e783960401dd1c43cf368383b4992eR577 | 14:14 |
| ericsnow | voidspace: yeah, plugging that into the CLI shouldn't be a problem | 14:31 |
| voidspace | ericsnow: cool | 14:32 |
| voidspace | ericsnow: it occurs to me that I can just leave you to test it... ;-) | 14:32 |
| voidspace | only mostly joking... | 14:33 |
| ericsnow | voidspace: we'll see :) | 14:33 |
| ericsnow | voidspace: such a kidder | 14:33 |
| rogpeppe1 | frankban, dimitern_, fwereade, voidspace, mgz, perrito666: factor cmd package out of juju-core: https://github.com/juju/juju/pull/93 | 14:36 |
| dimitern_ | rogpeppe1, why?! | 14:36 |
| rogpeppe1 | dimitern_: because we want stuff outside of juju-core to be able to use it | 14:36 |
| rogpeppe1 | dimitern_: specifically, the store commands are moving out of juju-core too | 14:37 |
| dimitern_ | rogpeppe1, oh brother.. | 14:37 |
| dimitern_ | explosion of deps and repos :) | 14:37 |
| mgz | dimitern_: most of these pacakge splits are so rog can use 'em from elsewhere | 14:37 |
| rogpeppe1 | dimitern_: and really, it should not be juju-specific | 14:37 |
| rogpeppe1 | dimitern_: i thought you liked external repos :-) | 14:37 |
| mgz | it's quite a lot of short term pain though... | 14:37 |
| mgz | well, and some ongoing pain, given the non-smoothness of dep management | 14:38 |
| voidspace | for every new repo I have to create a new mail rule... | 14:38 |
| rogpeppe1 | voidspace: can't you create one mail rule that matches all of 'em? | 14:38 |
| dimitern_ | rogpeppe1, I'll like them even more when we stop moving stuff around in 5000+ line diffs :) | 14:38 |
| rogpeppe1 | dimitern_: most of the diff there is deletion | 14:38 |
| rogpeppe1 | dimitern_: i'm sure i remember you arguing that more stuff should be factored out of juju-core, ages ao | 14:39 |
| rogpeppe1 | ago | 14:39 |
| voidspace | rogpeppe1: well I could do - so long as I never work with any non-juju git repos | 14:39 |
| dimitern_ | rogpeppe1, even the agents are not juju-specific? | 14:40 |
| voidspace | rogpeppe1: and I don't yet, but I don't want to assume I never will | 14:40 |
| natefinch | voidspace: on your canonical account? Probably safe assumption | 14:40 |
| rogpeppe1 | dimitern_: the agents haven't moved | 14:40 |
| voidspace | natefinch: I only have one github account | 14:40 |
| rogpeppe1 | dimitern_: it's the cmd package only | 14:40 |
| natefinch | voidspace: you can give it multiple email addresses and address notifications on a per-team basis | 14:40 |
| rogpeppe1 | dimitern_: (and cmd/testing) | 14:40 |
| voidspace | natefinch: ah, I didn't know that | 14:40 |
| natefinch | voidspace: so my juju notifications all go to canonical, everything else to my gmail | 14:40 |
| dimitern_ | rogpeppe1, so there will be juju/cmd repo and juju/juju/cmd/jujud ? | 14:40 |
| voidspace | natefinch: I will do that immediately - thanks! | 14:40 |
| natefinch | voidspace: np | 14:41 |
| voidspace | yep, that's exactly what I want | 14:41 |
| rogpeppe1 | dimitern_: yup | 14:41 |
| * voidspace lunches | 14:41 | |
| dimitern_ | rogpeppe1, ah, i see - just the root cmd package then | 14:41 |
| rogpeppe1 | dimitern_: yup | 14:41 |
| rogpeppe1 | dimitern_: which is pretty general tbh (and should probably be more so, but i didn't want to break everything and take ages doing that) | 14:42 |
| dimitern_ | rogpeppe1, lgtm | 14:42 |
| rogpeppe1 | dimitern_: thanks! | 14:42 |
| rogpeppe1 | dimitern_: there were a couple of non-mechanical pieces | 14:43 |
| rogpeppe1 | dimitern_: specifically, the new functions NewSuperCommand and NewSubSuperCommand which are now in github.com/juju/juju/cmd | 14:43 |
| rogpeppe1 | dimitern_: which wrap cmd.NewSuperCommand in a juju-specific way (to do the expected logging) | 14:44 |
| frankban | rogpeppe1: LGTM thanks | 14:45 |
| dimitern_ | rogpeppe1, right, still lgtm | 14:48 |
| bodie_ | odd | 14:53 |
| bodie_ | I tagged my repo as .v1 | 14:53 |
| bodie_ | http://gopkg.in/binary132/gojsonschema.v1 | 14:53 |
| bodie_ | when adding it to imports( ... ) as gopkg.in/binary132/gojsonschema.v1, I think gofix is altering it to point to the repo it was forked from | 14:54 |
| bodie_ | never mind, I'd had the original repo alongside my forked one | 14:55 |
| bodie_ | in $GOPATH | 14:55 |
| bodie_ | removed and it works | 14:55 |
| rogpeppe1 | bodie_: awesome, good plan | 14:55 |
| bodie_ | yeah, gofix was messing with my head though, heh. | 14:56 |
| bodie_ | anyway, hopefully this is the last we have to think about gojsonschema for quite some time. | 14:56 |
| * rogpeppe1 hopes so too | 14:56 | |
| bodie_ | rogpeppe1, since I now am using the gopkg.in dep, I need to alter dependencies.tsv too, don't I. | 14:57 |
| rogpeppe1 | bodie_: yup | 14:57 |
| bodie_ | very well then. I think this is prepared for review other than the addition of the dep. I'll add that in a separate PR momentarily | 14:59 |
| bodie_ | https://github.com/juju/charm/pull/4 | 14:59 |
| bodie_ | rogpeppe1, mgz, fwereade | 14:59 |
| === psivaa-afk is now known as psivaa | ||
| bodie_ | might be cool to add tagged releases to github juju | 15:19 |
| bodie_ | that way if someone wanted a stable build from source, they could check out and build a specific version | 15:21 |
| rick_h_ | we use master vs develop for that :) | 15:25 |
| rick_h_ | in UI land | 15:25 |
| bodie_ | okay, I'm having some confusion here with the dependencies.tsv stuff | 15:29 |
| bodie_ | I made sure I had the latest juju/juju with go get -u -v, and then ran godeps -u dependencies.tsv in juju/juju | 15:30 |
| bodie_ | but, it looks like a bunch of my versions are different in my new dependencies.tsv | 15:30 |
| bodie_ | er, the one I just generated with godeps -t $(go list github.com/juju/juju/...) > dependencies.tsv.new | 15:30 |
| bodie_ | http://www.diffchecker.com/3en2efa8 | 15:32 |
| bodie_ | okay, I didn't have the correct pinned deps due to an issue with the new ones I got. looks good now. | 15:34 |
| bodie_ | THERE we go. | 15:39 |
| bodie_ | okay, I need to get this PR in so that I can update dependencies.tsv properly. can anyone vet this? https://github.com/juju/charm/pull/4 | 15:39 |
| bodie_ | it's not terribly complicated | 15:39 |
| bodie_ | however, juju/juju/dependencies.tsv has an incorrect dep on a dev branch for charm, so I need to get that merged into master in order to update deps correctly. | 15:40 |
| bodie_ | fwereade, mgz, rogpeppe1, anyone? I guess you guys are probably in a meeting | 15:40 |
| rogpeppe1 | bodie_: oops | 15:41 |
| rogpeppe1 | i wonder how that got merged | 15:41 |
| bodie_ | it didn't | 15:42 |
| bodie_ | rogpeppe1, I'm building against a dev branch right now | 15:42 |
| bodie_ | the master doesn't have my changes yet | 15:42 |
| bodie_ | so, my generated dependencies.tsv doesn't have the correct version of charm | 15:42 |
| bodie_ | slowly going insane | 15:43 |
| bodie_ | lol | 15:43 |
| rogpeppe1 | bodie_: i'm not sure exactly what you're asking me to vet | 15:43 |
| rogpeppe1 | bodie_: unfortunately github doesn't make it easy to see what changes have been made in response to what comments | 15:44 |
| bodie_ | rogpeppe1, basically I nuked most of that PR, fixed a bunch of code, and it should be thought of as a new PR | 15:44 |
| rogpeppe1 | bodie_: you rebased? | 15:45 |
| bodie_ | rebased, amended commit message | 15:45 |
| rogpeppe1 | bodie_: hmm, it would have been nice to have been able to diff from the comments | 15:46 |
| rogpeppe1 | bodie_: because now i have no idea what's changed | 15:46 |
| bodie_ | rogpeppe1, right.... so, when I alter something that you commented on, the history hides the comment | 15:47 |
| rogpeppe1 | bodie_: it doesn't look totally different | 15:47 |
| rogpeppe1 | bodie_: i can see the old comments | 15:47 |
| rogpeppe1 | bodie_: but i want to find out how the code has changed since i made the comment | 15:47 |
| bodie_ | it's not that different, I mostly addressed your issues and beefed up the tests, stripped out some useless tests | 15:47 |
| rogpeppe1 | bodie_: so i don't have to continually cross-refer | 15:47 |
| bodie_ | hmmmm | 15:47 |
| bodie_ | there must be a way to do that | 15:47 |
| rogpeppe1 | bodie_: perhaps you could reply to the comments saying which ones you've done or not done | 15:48 |
| rogpeppe1 | bodie_: it's something i found indispensable in rietveldt, and i'm a bit at a loss without it | 15:48 |
| bodie_ | perhaps the issue is my rebase | 15:49 |
| bodie_ | rogpeppe1, basically I addressed the concerns exactly, except for a couple where I left comments | 15:49 |
| bodie_ | https://github.com/juju/charm/pull/4#discussion_r13701371 | 15:49 |
| bodie_ | https://github.com/juju/charm/pull/4#discussion_r13704644 | 15:49 |
| bodie_ | I don't see why they don't have a feature to address exactly your concern, that does seem really silly | 15:51 |
| rogpeppe1 | bodie_: hmm, looks like i never published one comment | 15:55 |
| natefinch | how github gets new features is really quite a mystery given the very obvious deficiencies they've had for a long long time. | 15:55 |
| rogpeppe1 | bodie_: the cleanse function doesn't properly give an error on all bad keys | 15:56 |
| rogpeppe1 | bodie_: (AFAICS) | 15:56 |
| bodie_ | rogpeppe1, in the case of type map[i{}]i{}, it just coerces the keys to strings and then runs through it again in the m[s]i{} case | 15:57 |
| rogpeppe1 | bodie_: ah, i missed that | 16:02 |
| rogpeppe1 | bodie_: BTW if prohibitedSchemaKeys was a map[string]bool (or a set.Strings) then the lookup would not require a loop | 16:04 |
| bodie_ | ah, good point rogpeppe1 | 16:09 |
| rogpeppe1 | godeps: cannot parse "/mnt/jenkinshome/jobs/github-merge-juju/workspace/tmp.gduuL94JJe/RELEASE/src/github.com/juju/juju/dependencies.tsv": cannot find directory for "github.com/binary132/gojsonpointer": not found in GOPATH | 16:12 |
| rogpeppe1 | mgz: doesn't the 'bot automatically get new deps? | 16:12 |
| rogpeppe1 | mgz: if not, then how can i fix it (FWIW, i don't *think* i added that dependency) | 16:13 |
| mgz | rogpeppe1: it does, and that's not a new dep | 16:13 |
| rogpeppe1 | hmm, weird | 16:13 |
| mgz | is it not actually imported in the branch? | 16:13 |
| mgz | we still rely of go get for fetch | 16:13 |
| bodie_ | rogpeppe1, I'm actually going to revert the gopkg changes | 16:14 |
| rogpeppe1 | mgz: ah... | 16:14 |
| bodie_ | I think mgz had some good points that we're already pinning to a version via dependencies.tsv | 16:14 |
| rogpeppe1 | mgz: it's quite possible we don't have that as a dep any more | 16:14 |
| rogpeppe1 | mgz: hmm, no, we must do | 16:15 |
| mgz | rogpeppe1: I think it's just gopkg weirdness we don't need to deal with for now | 16:16 |
| rogpeppe1 | mgz: gopkg? | 16:16 |
| mgz | rogpeppe1: gopkg.in | 16:17 |
| rogpeppe1 | mgz: oh, i see | 16:17 |
| rogpeppe1 | pwd | 16:18 |
| rogpeppe1 | bodie_: but the branch i'm committing doesn't have any gopkg.in deps | 16:18 |
| bodie_ | rogpeppe1, come again? | 16:19 |
| bodie_ | rogpeppe1, I'm going to push a couple of tweaks to the PR, so we don't have to deal with this gopkg stuff right now | 16:19 |
| rogpeppe1 | bodie_: ok, fair enough. | 16:20 |
| rogpeppe1 | bodie_: sorry, i thought you were linking it to my 'bot failure | 16:20 |
| mgz | rogpeppe1: it is related | 16:22 |
| mgz | see the go get higher up in the console log | 16:22 |
| mgz | having tip of gojsonschema pointing at gopkg.in borked us | 16:22 |
| mgz | I'll requeue the proposals when that gets sorted | 16:23 |
| mgz | bodie_: poke me when we're back to normality please :) | 16:23 |
| rogpeppe1 | ah, i get it | 16:23 |
| rogpeppe1 | we to go get, which has no dependencies; then we update the deps, and that means we really need to go get again | 16:24 |
| wwitzel3 | fwereade: updated https://github.com/juju/juju/pull/2 when you have a moment to review. thanks. | 16:28 |
| bodie_ | rogpeppe1, mgz https://github.com/juju/charm/pull/4 ready | 16:36 |
| rogpeppe1 | bodie_: thanks for not rebasing :-) | 16:37 |
| rogpeppe1 | bodie_: i think a load of my comments must've got lost in the ether | 16:45 |
| rogpeppe1 | bodie_: did you see a comment about var swap = unmarshaledActions.ActionSpecs[name] | 16:46 |
| rogpeppe1 | ? | 16:46 |
| rogpeppe1 | bodie_: i suggested: spec := unmarshaledActions.ActionSpecs[name] | 16:46 |
| rogpeppe1 | bodie_: because nothing is being actually swapped | 16:46 |
| mgz | rogpeppe1: there's a possibly valid error on your 010 merge | 16:46 |
| rogpeppe1 | mgz: link? | 16:47 |
| mgz | job 144, should be on the pr | 16:47 |
| mgz | (sorry, can't easily paste url into irc) | 16:47 |
| bodie_ | rogpeppe1, one moment, looking | 16:48 |
| rogpeppe1 | mgz: ok, looking | 16:48 |
| rogpeppe1 | mgz: ah, perhaps i haven't pushed the latest version of cmd | 16:49 |
| * rogpeppe1 juggles dependencies | 16:49 | |
| bodie_ | rogpeppe1, https://github.com/binary132/charm/blob/actions-validate/actions.go#L77-L94 | 16:50 |
| bodie_ | I'm not seeing the problem here | 16:51 |
| rogpeppe1 | bodie_: the "swap" variable isn't actually swapping anything. it's just a temporary mutable store for the struct. | 16:51 |
| rogpeppe1 | bodie_: it confused me for a few moments | 16:51 |
| bodie_ | ah, so just the naming | 16:51 |
| rogpeppe1 | yeah | 16:51 |
| mgz | yeah, I'd generally name those kinds of things temp | 16:52 |
| bodie_ | that syntax is a little kludgy, imo | 16:52 |
| mgz | (or more commonly, tempSomething) | 16:52 |
| rogpeppe1 | bodie_: also, we can do this later, but i'm inclined to think that bundling the bad-key checking inside the cleanse function isn't great | 16:52 |
| bodie_ | I get why it's there, since map resolution happens at runtime, and things need to be good at compile time | 16:52 |
| rogpeppe1 | bodie_: why what's there? | 16:53 |
| rogpeppe1 | i generally name it after the thing that it is | 16:53 |
| rogpeppe1 | in this case "spec" should work fine | 16:53 |
| bodie_ | er, the need to use a temp stuct | 16:53 |
| bodie_ | struct* | 16:53 |
| bodie_ | rather than assigning to the struct member via map resolution ActionSpecs[name] | 16:53 |
| rogpeppe1 | bodie_: there have been murmurings about allowing the assignment of fields inside by-value structs in maps | 16:53 |
| rogpeppe1 | bodie_: it's a slightly awkward language spec change to make though | 16:54 |
| rogpeppe1 | bodie_: as values in maps are deliberately not addressable | 16:54 |
| bodie_ | there we go | 16:54 |
| rogpeppe1 | bodie_: and that's currently the rule for allowing mutation of struct members | 16:54 |
| bodie_ | new bit up | 16:54 |
| bodie_ | I think it's nice that Go is oriented towards usefulness without total depth of knowledge ;) | 16:55 |
| natefinch | bodie_: I like that total depth of knowledge is not too hard to obtain | 16:56 |
| natefinch | (especially compared to other languages) | 16:56 |
| bodie_ | :) | 16:56 |
| bodie_ | I always find myself comparing everything to C in my head | 16:56 |
| bodie_ | it doesn't get much simpler than that, really | 16:57 |
| natefinch | bodie_: there's a lot of memory management stuff that you need to know about C and using pointers as arrays & strings | 16:57 |
| bodie_ | you mean, like chunking for the cpu and caching behavior, heap vs stack? | 16:58 |
| natefinch | like malloc etc | 16:58 |
| bodie_ | yeah, the mechanics can be kind of klutzy, for sure, especially starting out | 16:59 |
| natefinch | oh yeah, and data structures getting created with completely random data... that's an awesome feature | 16:59 |
| bodie_ | makes perfect sense, though | 16:59 |
| natefinch | lots of foot guns :) | 16:59 |
| bodie_ | what's really fun is when you manage to mangle your stored code, and things start blowing up in weird ways that are impossible to debug "the normal way" | 17:00 |
| bodie_ | because you're actually altering your program's behavior in unexpected, unpredictable ways.... | 17:01 |
| bodie_ | wheee | 17:01 |
| bodie_ | rogpeppe1 / mgz is that pr good to land? | 17:01 |
| mgz | bodie_: is from my perspective | 17:02 |
| bodie_ | I changed the name of the variable, I'd like to get this dependency stuff over with so I can fix the deps.tsv stuff and get on with my life (heh) | 17:02 |
| rogpeppe1 | bodie_: yeah, land it. i might fix up a couple of trivials later. | 17:02 |
| bodie_ | rogpeppe1, it's meant to be landed with $$merge$$ .... right? | 17:08 |
| rogpeppe1 | bodie_: no, just click merge | 17:09 |
| bodie_ | ah | 17:09 |
| rogpeppe1 | bodie_: we haven't got CI set up yet on any of the external repos | 17:09 |
| rogpeppe1 | bodie_: make sure that the tests pass tho'! | 17:09 |
| bodie_ | :) | 17:10 |
| bodie_ | I'm not seeing a merge button. | 17:11 |
| bodie_ | I'm sure that now that I've said so, it will become immediately obvious | 17:12 |
| bodie_ | probably just need to rebase on master | 17:14 |
| bodie_ | nope | 17:15 |
| bodie_ | rogpeppe1, I'm sorry for all the constant interrupt polling I'm doing here, do I just not have permissions or what's going on here? I just want to get this finished. | 17:17 |
| rogpeppe1 | bodie_: hmm, you *should* have perms, assuming you're a member of juju-hackers. i'll just check. | 17:18 |
| bodie_ | I am a member | 17:18 |
| bodie_ | I think...? | 17:18 |
| jcw4 | And you're marked public I think bodie_ right? | 17:18 |
| bodie_ | I'm a member of juju | 17:18 |
| rogpeppe1 | bodie_: ah, try again | 17:18 |
| rogpeppe1 | bodie_: i hadn't added juju-hackers to the collabs | 17:18 |
| bodie_ | I see | 17:19 |
| bodie_ | well, that's nice to know, at least I wasn't doing something daft | 17:19 |
| bodie_ | and merged. | 17:19 |
| bodie_ | thank god. | 17:19 |
| rogpeppe1 | yay, merged! | 17:22 |
| * rogpeppe1 high fives bodie_ | 17:22 | |
| bodie_ | this doesn't look right | 17:35 |
| bodie_ | https://github.com/binary132/juju/compare/dependencies-charm-gojsonschema?expand=1 | 17:35 |
| bodie_ | ugh | 17:35 |
| bodie_ | okay, fixing | 17:35 |
| bodie_ | https://github.com/juju/juju/pull/96 | 17:40 |
| bodie_ | rogpeppe1, mgz.... that should be all | 17:41 |
| * rogpeppe1 is done for the day | 17:47 | |
| voidspace | g'night folks | 18:03 |
| voidspace | EOW | 18:03 |
| voidspace | see you all on Monday | 18:03 |
| ericsnow | voidspace: have a nice one | 18:04 |
| natefinch | see ya voidspace | 18:04 |
| perrito666 | btw, adding this to your ~/.gitconfig might easy your lives http://pastebin.ubuntu.com/7640097/ | 18:08 |
| jcw4 | perrito666: which part in particular, or all of it? | 18:09 |
| natefinch | perrito666: looks like there's some duplicate data in there | 18:10 |
| natefinch | like color for status | 18:10 |
| perrito666 | natefinch: might be some dupes I have ben tweaking it for some time | 18:10 |
| jcw4 | perrito666: I see now.. I just saw a wall of text and didn't read enough to see it was all related to color coding git status info | 18:10 |
| perrito666 | jcw4: I get colors on status, a few useful shortcuts | 18:10 |
| perrito666 | jcw4: yup, basically it all makes to display git data into better ways | 18:11 |
| natefinch | it's funny, my biggest gripe with git is that git difftool won't open more than one diff at a time. I like being able to go through all the diffs in different tabs and see how they relate to one another | 18:11 |
| perrito666 | jcw4: looking it more in depth, I might have two files pasted there :p I just over cated | 18:12 |
| natefinch | heh | 18:12 |
| jcw4 | :) | 18:15 |
| perrito666 | but that makes very clear the output of my git :) just needs a bit of cleaning | 18:18 |
| perrito666 | jcw4: natefinch http://pastebin.ubuntu.com/7640139/ | 18:22 |
| perrito666 | there better | 18:22 |
| jcw4 | sweet | 18:22 |
| perrito666 | I find the aliases at the bottom to be specially life improving | 18:23 |
| perrito666 | as you can see some of those come from when I used svn :p | 18:24 |
| natefinch | heh... yeah... I wish all the vcs people could just agree on a naming scheme. It would make things so much simpler | 18:27 |
| jcw4 | perrito666: I like git aliases too...http://paste.ubuntu.com/7640151/ | 18:27 |
| perrito666 | natefinch: oh git agrees on the naming, they just have the commands do different stuff | 18:28 |
| natefinch | haha, exactly | 18:29 |
| bodie_ | so, any chance I could get that dep update landed? do I need a LGTM for this? | 18:38 |
| bodie_ | https://github.com/juju/juju/pull/96 | 18:38 |
| natefinch | wyou always need a LGTM :) | 18:39 |
| natefinch | not that I can tell at all if you screwed up or not ;) | 18:40 |
| bodie_ | hehe, yep... seemed like a pretty simple thing to get landed | 18:40 |
| jcw4 | bodie_: LGTM | 18:40 |
| jcw4 | ;0 | 18:40 |
| jcw4 | ;) even | 18:40 |
| bodie_ | I'm really anxious to move on to the action stuff... | 18:40 |
| natefinch | jcw4: you gotta do it for realz in the PR, so it's recorded that it's your head on the line if there's a problem :) | 18:40 |
| jcw4 | er... umm | 18:41 |
| jcw4 | well... | 18:41 |
| bodie_ | what, natefinch, you can't eyeball the difference between 1be916ca1fee152004f27cf83df96b130411ea9f and dbe10f58fcb80669aa3972574f51d92fdd20ee47? | 18:41 |
| jcw4 | my head is now on the line | 18:41 |
| bodie_ | from a certain perspective, it's just moved from one line to another | 18:41 |
| natefinch | you can actually just go look at the ids of the heads of those repos and eyeball that they're the same as in the dependencies file | 18:42 |
| natefinch | LGTM to me too | 18:43 |
| bodie_ | thanks gents | 18:43 |
| bodie_ | and this is where I need to do the $$merge$$ bit? | 18:43 |
| jcw4 | bodie_: yep $$merge$$ | 18:45 |
| perrito666 | mm, just the kind of mail to get from curtis a friday afternoon | 18:48 |
| natefinch | ahh, the weekly "everything is totally screwed up!" email :/ | 18:50 |
| jcw4 | what does PTAL mean? | 19:04 |
| natefinch | please take a look | 19:04 |
| jcw4 | ah... thanks! | 19:04 |
| natefinch | took me a while to figure that one out too | 19:04 |
| jcw4 | I got SGTM, LGTM, WTF (j/k) but I couldn't get that one | 19:05 |
| lazyPower | have you guys had a chance to look at https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1329429 | 19:06 |
| _mup_ | Bug #1329429: local bootstrap fails <amd64> <apport-bug> <trusty> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1329429> | 19:06 |
| lazyPower | i'm seeing more users show up with this null pointer dereference problem, so far about 3 | 19:06 |
| lazyPower | however, the user being affected by this particular issue is here now, ali1234 is the filer of 1329429 | 19:09 |
| natefinch | lazyPower: you shouldn't need to sudo for bootstrap... in fact that may mess things up (obviously a nil pointer panic is not really an acceptable handling of that) | 19:09 |
| ali1234 | hi | 19:09 |
| lazyPower | natefinch: is that the root of the issue, using sudo? | 19:09 |
| lazyPower | let me update that AU answer - since juju has evolved beyond requiring sudo to run the bootstrap for local. | 19:09 |
| natefinch | I don't know. juju bootstrap with local will work without sudo (if it needs sudo, it'll prompt you for creds) | 19:10 |
| natefinch | so... it may need sudo, but running it preemptively with sudo is not necessary nor recommended | 19:10 |
| lazyPower | natefinch: good point. I've got an edit filed for that AU answer, i didn't realize it wasp ointing to still using sudo | 19:11 |
| lazyPower | that's been corrected for a little over what, 4 months now? | 19:11 |
| natefinch | something like that yeah | 19:12 |
| natefinch | we wanted it to be completely sudo-less but there were some userspace-lxc things that I think either didn't make it in or weren't available on all platforms | 19:13 |
| lazyPower | ali1234: when you run juju bootstrap without prefixing with sudo, do you still get the nil pointer problem? | 19:14 |
| ali1234 | yes | 19:14 |
| ali1234 | ~/.juju/environments/ is owned by root, this probably doesn't help | 19:15 |
| natefinch | I figured that would be too much to hope for | 19:15 |
| ali1234 | i only get the null pointer problem when running without sudo | 19:16 |
| ali1234 | i don't get it when running with sudo, i get a different error telling me not to use sudo :) | 19:16 |
| natefinch | oh yeah, sorry, I see that now in the bug description. well, it's good to get the documentation correct anyway | 19:17 |
| ali1234 | yeah. i expect if i hadn't made that mistake i wouldn't be in this situation | 19:17 |
| natefinch | I'm trying to dredge up the 1.18.1 code so I can make sure I'm looking at the right code for the tracebacks in the bug | 19:21 |
| lazyPower | Thanks for taking a look natefinch | 19:22 |
| ali1234 | ~/.juju/environments/ was empty so i deleted it... now i don't get the error | 19:24 |
| natefinch | huh | 19:24 |
| natefinch | like.... bootstrap worked? | 19:24 |
| ali1234 | yes | 19:24 |
| ali1234 | it recreated the dir and now i have a local.jenv inside it | 19:25 |
| natefinch | I wonder if that got created with root credentials and then it couldn't be written to | 19:25 |
| ali1234 | yes, that is exactly what happened | 19:25 |
| natefinch | I think we've seen that.... I think we fixed it... there was another bug for it, let me check | 19:25 |
| natefinch | Have you tried this with 1.18.4? | 19:29 |
| ali1234 | no | 19:30 |
| ali1234 | i just wanted to try out juju, i have never used it before | 19:30 |
| ali1234 | i have no idea how to do that | 19:30 |
| natefinch | apologies for such a bad first impression | 19:31 |
| ali1234 | np, i've seen worse | 19:31 |
| jcw4 | [miracle max's wife]: you think it'll work? | 19:31 |
| jcw4 | [miracle max]: it'll take a miracle | 19:32 |
| ali1234 | so my question now is are there going to be more root owned files? where does it keep all the local stuff? | 19:34 |
| natefinch | There should not be any root owned files. We only need root for local environments because we start lxc containers. | 19:34 |
| natefinch | the local stuff is all kept under $HOME/.juju/ | 19:34 |
| ali1234 | yeah, where are those containers stored? in ~/.juju? | 19:34 |
| ali1234 | ~/.juju/local/ has a load of root owned files | 19:35 |
| natefinch | ali1234: the containers are stored in the standard lxc place, I believe, /var/lib/lxc? something like that. | 19:35 |
| ali1234 | /var/lib/lxc/ is empty | 19:36 |
| ali1234 | should i just nuke ~/.juju and start again? | 19:36 |
| natefinch | ali1234: that's probably not a bad idea. I was wrong, it looks like there are some root owned files in .juju, at least under the .juju/local/ directory | 19:37 |
| ali1234 | now i get "ERROR cannot use 37017 as state port, already in use" | 19:43 |
| ali1234 | apparently mongodb is running on that port | 19:44 |
| natefinch | ali1234: so the mongo server from the first bootstrap is evidently still running. Assuming you're not running mongod on your local box for anything else, you can just do sudo killall mongod | 19:44 |
| ali1234 | start: Job is already running: juju-agent-al-local Bootstrap failed, destroying environment | 19:45 |
| natefinch | try running juju destroy-environment local --force | 19:46 |
| ali1234 | ERROR open /home/al/.juju/environments.yaml: no such file or directory | 19:46 |
| natefinch | heh, oops, ok, so we've been blowing stuff away so it's all confused | 19:47 |
| ali1234 | i did init, switch, destroy and that seems to have worked | 19:47 |
| natefinch | ahh, cool | 19:47 |
| ali1234 | bootstrap appears to have worked | 19:47 |
| ali1234 | i was under the impression it had to download a lot of stuff, but it ran very quickly | 19:48 |
| natefinch | the local provider is super quick | 19:54 |
| natefinch | great for demos and proof of concepts | 19:54 |
| ali1234 | so the askubuntu page says "The first time this runs it might take a bit, as it's doing a netinstall for the container, it's around a 300 megabyte download. Subsequent bootstraps should be much quicker. " | 19:57 |
| ali1234 | it definitely didn't download 300mb... | 19:57 |
| ali1234 | looks like it's working now, thanks! | 20:08 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| bodie_ | does anyone happen to know much about juju run? | 20:51 |
| bodie_ | I'm trying to figure out where to look for the bits where it builds the hook context | 20:51 |
| natefinch | bodie_: thumper wrote that, but it's saturday where he is | 20:51 |
| bodie_ | :) | 20:51 |
| bodie_ | on that note, if fwereade sees this -- https://github.com/juju/juju/blob/master/doc/charms-in-action.txt#L80-L92 | 20:55 |
| bodie_ | I think this content is outdated, but I want to be sure | 20:55 |
| === Ursinha is now known as Ursinha-afk | ||
| perrito666 | ok, EOD | EOW for me, cheers | 21:32 |
| === Ursinha-afk is now known as Ursinha | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!