| bigjools | wallyworld_, thumper: should have you a working maas in about an hour, need to download 300MB of updates and re-commission nodes | 00:41 |
|---|---|---|
| wallyworld_ | rightio | 00:42 |
| * thumper noticed that the ubuntu edge igg has stalled just under 7m | 01:39 | |
| thumper | bigjools: if you could fling wallyworld_ and me the details for the environments.yaml file, that'd be swell (when it's ready) | 01:40 |
| bigjools | I will | 01:40 |
| davecheney | what is a MIR ? https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-mongodb | 01:46 |
| * thumper looks | 01:48 | |
| thumper | davecheney: where is MIR mentioned? | 01:49 |
| thumper | ah | 01:50 |
| thumper | Main Inclusion Request | 01:50 |
| thumper | AFAIK | 01:50 |
| thumper | at least that is what I think it is | 01:50 |
| davecheney | I only know MRE | 01:51 |
| thumper | which is? | 01:51 |
| davecheney | Meals Ready to Eat | 01:52 |
| thumper | haha | 01:54 |
| thumper | wallyworld_: I noticed today that when I started up a second machine on ec2, and it had two ccontainers on it | 01:56 |
| thumper | wallyworld_: when the lxc provisioner task started, it didn't get told about the new containers | 01:56 |
| thumper | so they never started | 01:57 |
| thumper | the two containers on machine 0 started | 01:57 |
| thumper | but their machine agent would have been running first | 01:57 |
| bigjools | thumper: which ssh key of yours should I put on here? | 01:57 |
| thumper | whereas the machine 1 would have been booted after the two containers in state | 01:57 |
| * thumper looks | 01:57 | |
| wallyworld_ | it should have queried state | 01:57 |
| thumper | wallyworld_: I agree, it should have | 01:58 |
| thumper | wallyworld_: but it does that by starting the watcher | 01:58 |
| wallyworld_ | you think this is a new bug? | 01:58 |
| thumper | wallyworld_: what I'm saying is that something is screwy there | 01:58 |
| thumper | probably | 01:58 |
| thumper | may need some more poking | 01:58 |
| wallyworld_ | afaik the watcher returns the inital state of play | 01:59 |
| thumper | yes it should | 01:59 |
| thumper | but it seems in this case, it didn't | 01:59 |
| thumper | I probably need some extra tracing... | 01:59 |
| wallyworld_ | so i wonder what has changed. i can't recall any of us touching this stuff | 01:59 |
| thumper | no | 01:59 |
| thumper | but the machine agent has had some messing around with the state -> api stuff recently | 01:59 |
| wallyworld_ | hmmmm | 02:00 |
| thumper | also, general watchers have seen change since this worked before | 02:00 |
| bigjools | thumper: ? | 02:00 |
| thumper | bigjools: I dm'ed you the key | 02:00 |
| bigjools | ah nm got it | 02:00 |
| bigjools | was looking on LP and you have loads | 02:00 |
| thumper | yeah | 02:00 |
| thumper | jake is the current machine | 02:00 |
| thumper | elwood was the last one | 02:00 |
| bigjools | jake is my eldest twin's name | 02:01 |
| thumper | :) | 02:01 |
| thumper | what did you call the other? | 02:01 |
| bigjools | he's getting better, thank goodness | 02:01 |
| bigjools | Harley | 02:02 |
| thumper | you missed an opportunity there | 02:02 |
| bigjools | s/missed/avoided/ | 02:02 |
| thumper | there was a funny facebook message the other day about nature names | 02:02 |
| thumper | Dragonhunter FTW | 02:02 |
| bigjools | /o\ | 02:02 |
| thumper | luckily for the children, i can't have any more | 02:03 |
| thumper | unless advances in stem cell research changes things | 02:03 |
| jtv | thumper: any chance you could review this branch for me: https://codereview.appspot.com/11923043/ ? | 02:43 |
| thumper | jtv: there is always a chance | 02:43 |
| * jtv rolls dice | 02:43 | |
| jtv | davecheney: my information is that MRE stands not for Meal Ready to Eat, but Meal Rejected by Ethiopians. | 02:44 |
| * thumper starts reviewing | 02:55 | |
| thumper | done, school pickup, back shortly | 03:01 |
| * thumper considers a branch that allows setting log levels remotely | 03:26 | |
| axw | *sigh* gotta go see the neighbour, fence fell over | 03:45 |
| axw | bbs | 03:45 |
| thumper | :( | 03:54 |
| === thumper is now known as thumper--afk | ||
| === tasdomas_afk is now known as tasdomas | ||
| rvba | Morning guys… I've got a tiny branch up for review… in case someone is free to review it: https://codereview.appspot.com/11913043/ | 07:38 |
| TheMue | morning | 07:58 |
| axw | morning | 07:59 |
| rogpeppe | rvba: reviewed | 08:00 |
| rogpeppe | axw, TheMue: mornin' | 08:00 |
| rvba | Thanks a lot rogpeppe. | 08:01 |
| axw | hey rog | 08:01 |
| === TheRealMue is now known as TheMue | ||
| rogpeppe | dimitern, fwereade: thanks for the reviews; responded. https://codereview.appspot.com/11932043/ | 09:07 |
| dimitern | rogpeppe: me too :) (replied to one of your comments) | 09:12 |
| rogpeppe | dimitern: i like the idea of reusable constructs for writing tests, but not when using them is more work than doing the basic version. | 09:13 |
| rogpeppe | dimitern: i don't think statetesting.AssertStop gains us anything at all | 09:14 |
| dimitern | rogpeppe: how can it possibly be more work? | 09:14 |
| dimitern | rogpeppe: don't you use code completion? :) | 09:15 |
| rogpeppe | dimitern: is that why it's less work? | 09:15 |
| rogpeppe | dimitern: it's also less obvious than the basic version | 09:15 |
| rogpeppe | dimitern: and i like to keep test code as simple as possible | 09:15 |
| rogpeppe | dimitern: it should really be called AssertThatStopSucceeds | 09:16 |
| dimitern | rogpeppe: ohh.. | 09:16 |
| dimitern | rogpeppe: :) well, ignore me then, but my point was to enforce consistency when possible | 09:17 |
| dimitern | rogpeppe: otherwise each module can be its own world because it makes sense there and then, rather than having a codebase-wide uniformity | 09:17 |
| jtv | Hi folks — how's tarmac doing today? | 09:18 |
| dimitern | jtv: still dead i think | 09:18 |
| * jtv wipes away tear | 09:18 | |
| jtv | Did I hear mention of a workaround? | 09:19 |
| rogpeppe | dimitern: Assert(x.Stop(), IsNil) seems about evenly balanced with AssertStop in the code base | 09:19 |
| dimitern | jtv: manual landing | 09:19 |
| jtv | I don't think I have privileges for landing. :( | 09:19 |
| dimitern | mgz: can you explain jtv about how can he land his code manually? | 09:19 |
| * rvba listens | 09:20 | |
| * jtv turns on the water heater in anticipation | 09:20 | |
| dimitern | rogpeppe: and if it was s.AssertStop(c, w) would it be better? | 09:20 |
| rogpeppe | dimitern: not really. | 09:20 |
| rogpeppe | dimitern: i like to see the Stop call directly in the code. | 09:21 |
| dimitern | rogpeppe: so you're not complaining about the length of the idents | 09:21 |
| jtv | FWIW for me as an outsider, Assert(x.Stop(), IsNil) is a lot easier to understand. Might I suggest a compromise of "AssertStopSucceeds"? | 09:21 |
| rogpeppe | dimitern: not really. just the fact that it's a single line of code which i think is clearer written out each time than calling a function to do it | 09:22 |
| dimitern | rogpeppe: how about statetesting.AssertCanStopWhenSending then? | 09:22 |
| rogpeppe | jtv: exactly. | 09:22 |
| rogpeppe | jtv: thanks | 09:22 |
| fwereade | rogpeppe, dimitern: fwiw you can also defer AssertStop without dropping errors on the floor | 09:22 |
| dimitern | fwereade: ah! very good point | 09:22 |
| rogpeppe | fwereade: now *that* is a good reason for using it | 09:22 |
| fwereade | rogpeppe, dimitern: and once you're using it in one place you may as well keep doing so IMO | 09:22 |
| dimitern | exactly | 09:23 |
| dimitern | jtv, rvba: well don't know if mgz is around, but basically the process goes as follows | 09:23 |
| fwereade | rogpeppe, dimitern, jtv: and while we're bikeshedding -- AssertCleanStop? | 09:24 |
| jtv | The hard part is expressing both the side effect and the assertion. | 09:24 |
| rogpeppe | jtv: yeah | 09:25 |
| dimitern | 1) switch to trunk, 2) pull, 3) bzr merge lp:~user/juju-core/yourbranch, 4) go build ./... && go test ./... (in juju-core/), 5) if all pass (and assuming no live testing is needed), 6) commit locally, setting the commit message as in LP, 7)bzr push bzr+ssh://go-bot@bazaar.launchpad.net/~go-bot/juju-core/trunk | 09:25 |
| dimitern | jtv: rvba ^^ | 09:25 |
| dimitern | 8) set MP to Merged + set revision in LP | 09:26 |
| mgz | dimitern: I odn;t think red squad have hte bot creds | 09:26 |
| dimitern | step 7) requires you to have access to go-bot's branch | 09:26 |
| mgz | or rather, red squad's ssh keys aren't on the launchpad bot accout | 09:27 |
| dimitern | mgz: ah, right, but did i summarize it well? | 09:27 |
| mgz | ypu | 09:27 |
| jtv | dimitern: thanks, that push URL was the part I was missing of course. | 09:27 |
| jtv | Should I give it a try anyway? | 09:27 |
| mgz | you can bzr info i | 09:28 |
| mgz | *it | 09:28 |
| dimitern | jtv: perhaps after all is done, you could push it to lp:~user/juju-core/trunk and let me or mgz push it to trunk for you until the ssh keys are sorted | 09:28 |
| mgz | running the test suite after merge and setting commit message in the mp will do | 09:29 |
| mgz | I can land pretty easily after that | 09:29 |
| jtv | mgz: "bzr info" says permission denied. :( | 09:30 |
| mgz | right. | 09:30 |
| jtv | But yes, I guess I could just merge all my approved branches into a personal trunk for the time being. | 09:30 |
| jtv | I think bzr has just implemented netsplits. | 09:30 |
| mgz | oh, that would work too | 09:30 |
| jtv | I thought that was what you meant when you said "push it to lp:~user/juju-core/trunk".. ? | 09:31 |
| jtv | Sorry, what Dimiter meant. | 09:31 |
| mgz | well bundling lots of changes up there saves some time | 09:32 |
| * fwereade_ is going to try to find somewhere with coffee, bbiab | 09:33 | |
| dimitern | jtv: but please, get in line so we won't introduce conflicts/breakages | 09:34 |
| dimitern | ideally, after bzr pull on trunk, run go build ./... && go test ./... before starting to merge to make sure trunk is sane | 09:34 |
| rogpeppe | perhaps we could make lbox submit work again for the time being | 09:34 |
| dimitern | rogpeppe: I don't think this is a good idea | 09:35 |
| rogpeppe | dimitern: ok | 09:35 |
| dimitern | rogpeppe: doing it manually will enforce some discipline and when the bot comes it'll be easier to switch | 09:36 |
| rogpeppe | dimitern: at least lbox submit checks that the code builds and is gofmt'd | 09:36 |
| jtv | dimitern: no need for that command line when just the age-old conventional "make check" will do. :-) | 09:36 |
| jtv | It has the added advantage of giving clear failure output at the end if the tests failed. | 09:36 |
| jtv | With the manual command, any test failures may have scrolled out of view. | 09:37 |
| jtv | Or "make build check format" to combine building, testing, and formatting. | 09:38 |
| jtv | Anybody willing to review https://codereview.appspot.com/12018043 ? | 09:43 |
| dimitern | jtv: i'll take a look | 09:43 |
| jtv | Thanks | 09:44 |
| TheMue | And another review from my side: https://codereview.appspot.com/11910043/ ? | 09:45 |
| jtv | Looking | 09:45 |
| jtv | Oh, I already approved that one so I don't qualify. :) | 09:46 |
| dimitern | TheMue: will take a look after jtv's review | 09:47 |
| TheMue | dimitern: great, cheers | 09:48 |
| wallyworld_ | fwereade_: making a juju validate super command didn't work out very well. there were a number of dead ends, especially wrt flag processing for sub commands. the juju cmd infrastructure is really only designed for only one level of sub command off juju. so it will be easier just to land as is for now | 10:01 |
| rogpeppe | dimitern: i got this error trying to push to trunk as suggested: | 10:02 |
| rogpeppe | bzr: ERROR: Server sent an unexpected error: ('error', 'AppendRevisionsOnlyViolation', 'Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "chroot-74851280:///~go-bot/juju-core/trunk/".') | 10:02 |
| dimitern | jtv: reviewed | 10:02 |
| rogpeppe | anyone got any idea what that error means? | 10:03 |
| jtv | Thanks dimitern | 10:03 |
| mgz | rogpeppe: you messed up the merge :) | 10:03 |
| dimitern | rogpeppe: hmm, not really - perhaps mgz or some lp/bzr guys? | 10:03 |
| rogpeppe | mgz: ok, so *how* did i mess up the merge? | 10:04 |
| jtv | Might it mean that somebody pushed something during your pull/merge/commit/push? | 10:04 |
| mgz | if for instance you merge trunk into your branch, then try pushing your branch over trunk, you get | 10:04 |
| jtv | Which then wouldn't be in the revisions you were trying to push? | 10:04 |
| rogpeppe | jtv: i'd have expected a "branch has diverged" error in that case | 10:04 |
| mgz | you have all the revs, history hasn't diverged, but you rearranged it's order | 10:04 |
| rogpeppe | ah, i know what i did wrong! | 10:04 |
| axw | if anyone cares about debug-hooks, I've got it working now: https://code.launchpad.net/~axwalk/juju-core/lp1027876-implement-debug-hooks/+merge/177353 | 10:05 |
| axw | I'll add more tests tomorrow, and hopefully propose it | 10:05 |
| jtv | Thanks for the review dimitern | 10:05 |
| rogpeppe | i forgot to pull from trunk before merging | 10:05 |
| dimitern | jtv: yw, tried to adhere to the way you prefer reading them :) | 10:06 |
| rogpeppe | axw: nice one! | 10:06 |
| jtv | dimitern: I noticed. Thoughtful of you — it really helps. | 10:07 |
| axw | gtg, night folks | 10:07 |
| jtv | nn axw | 10:08 |
| dimitern | jtv: it's strange that even though I put a blank line before every comment, not all of them appear like that in the mail | 10:08 |
| jtv | No, Rietveld is sneaky and likes to remove them when you edit them. | 10:08 |
| dimitern | jtv: aahh! good to know | 10:08 |
| TheMue | dimitern: seen your s/. Foo /. Foo/ statements in a review. it seems to be a convention for some of us to use two spaces after a point. i already wondered too. | 10:11 |
| dimitern | TheMue: That's madness :) | 10:12 |
| dimitern | TheMue: the only way I've seen this happen is when I use M-q in emacs to auto-format and align a comment block | 10:12 |
| TheMue | dimitern: dunno, maybe it's normal in some countries. but not in Germany. | 10:12 |
| TheMue | dimitern: ah, emacs, may be a reason. | 10:13 |
| dimitern | TheMue: when you have // ...something.\n// something else. M-q will make it // ...something. something else. | 10:13 |
| dimitern | (2 spaces after the .) | 10:13 |
| TheMue | dimitern: strange behavior, would like to know the reason | 10:14 |
| dimitern | TheMue: perhaps, as with everything in emacs, it's configurable, but I don't know | 10:18 |
| jtv | It's something I learned in my typing course. I find it greatly helps legibility, especially with the weird stuff we type with lots of dots that aren't full stops. | 10:19 |
| dimitern | ha! I found it | 10:19 |
| dimitern | it's called "sentence-end-double-space", and if set to nil won't do it | 10:20 |
| jtv | There is a rant on the internet that says it's nonsense, and people who oppose double-spacing invariable point to it with no more than the implication that since it's on the internet, it's the unassailable truth. | 10:20 |
| jtv | The rant starts out with a few inobtrusive assumptions: | 10:20 |
| jtv | (1) There is no such thing as monospace fonts, anywhere in the world, ever. | 10:21 |
| dimitern | LOL | 10:21 |
| TheMue | hehe | 10:21 |
| dimitern | i'd stop reading after (1) :) | 10:21 |
| dimitern | i know possibly only one person ever who used proportional fonts while editing code | 10:21 |
| jtv | (2) Software such as LaTeX can reliably tell the difference between a dot and a full stop, despite the fact that it regularly needs help telling them apart. | 10:22 |
| rogpeppe | dimitern: :-) | 10:22 |
| rogpeppe | dimitern: i know quite a few :) | 10:22 |
| jtv | So do I... Never could quite bring myself to try it. | 10:22 |
| jtv | Should I proceed with assumption (3)? | 10:22 |
| dimitern | why try it - it's *evil* | 10:22 |
| rogpeppe | dimitern: ha ha | 10:23 |
| rogpeppe | dimitern: you get more legible text in less space. what's not to like? | 10:23 |
| jtv | Sometimes I think I'd like an IDE to render unformatted block comments as flowing, proportionally-kerned text. | 10:23 |
| TheMue | Funnily Smalltalk environments often use non-monospace fonts and still format their methods (because that's what you see in the code browser) in a very aesthetic way. | 10:23 |
| jtv | SmallTalk. So far ahead the rest of the world will never catch up. :) | 10:23 |
| TheMue | jtv: Smalltalk, not SmallTalk :P | 10:24 |
| dimitern | reading fiction and reading code is quite a different thing and requires different focus | 10:24 |
| jtv | I believe it. | 10:24 |
| TheMue | jtv: A wonderful language for some domains, sadly very bad regarding concurrency and distribution. *sigh* | 10:24 |
| dimitern | when i'm reading code I notice characters, then words, in fiction, I rarely notice such things, because they won't induce a compile error :) | 10:25 |
| TheMue | dimitern: NOT? *rofl* | 10:25 |
| jtv | Maybe "fiction" is not quite the right word. | 10:25 |
| jtv | Because some code is fictional, and much non-code writing is nonfiction. | 10:25 |
| dimitern | ok then, natural text? | 10:25 |
| jtv | Sure. | 10:25 |
| jtv | Running text. Human-readable text. Prose. | 10:25 |
| jtv | (Prose isn't so good because it raises the question: what about poetry?) | 10:26 |
| TheMue | Isn't code pure ficction? The idea of something that happens? :D | 10:26 |
| jtv | No, in code we oppose a sea of troubles and by opposing end them. | 10:26 |
| jtv | Which I feel is nobler in the mind than suffering the guns and roses of outrageous fortune. | 10:27 |
| TheMue | And introduce new troubles. | 10:27 |
| jtv | I don't think the Bard mentioned secondary bugs. | 10:27 |
| dimitern | reminds me of wordpress' moto "code is poetry" :) | 10:27 |
| jtv | Then again, he didn't actually say "guns 'n' roses" either. | 10:28 |
| jtv | All code should be in dactylic hexameter. That'll stop idiots from knocking out crud without thinking. | 10:28 |
| jtv | Quidquid id est timeo danaos et dona ferentes. | 10:28 |
| TheMue | Ouch | 10:28 |
| dimitern | :D | 10:29 |
| TheMue | Next round: Isn't LISP the pure incarnation of poetry? | 10:29 |
| TheMue | *duck* | 10:29 |
| dimitern | I prefer Scheme | 10:29 |
| TheMue | dimitern: me too | 10:30 |
| jtv | Common Lisp! Variables! | 10:30 |
| dimitern | why do you need variables when you have lambdas? :) | 10:30 |
| jtv | Ich weiß nicht was soll es bedeuten / das ich so traurig bin / eine Routine aus ur-alten Zeiten... | 10:30 |
| dimitern | even I got most of this | 10:31 |
| TheMue | jtv: Hey, wow | 10:31 |
| dimitern | it my poor german | 10:31 |
| jtv | TheMue: sorry, didn't mean to insult your cultural heritage. :-) | 10:31 |
| dimitern | *with | 10:31 |
| jtv | But I do feel like that sometimes when I read ancient functions. | 10:32 |
| TheMue | jtv: no problem, only have been surprised | 10:35 |
| rogpeppe | trivial CL (func rename and arg reorder) https://codereview.appspot.com/12021043/ | 10:35 |
| dimitern | TheMue: reviewed | 10:35 |
| jtv | TheMue: what surprised me is that quite possibly the most beautiful German I've ever heard was an American reciting that poem off the cuff... | 10:36 |
| TheMue | dimitern: cheers | 10:36 |
| TheMue | rogpeppe: question about godoc | 10:36 |
| rogpeppe | TheMue: go on | 10:36 |
| TheMue | rogpeppe: the line break after // ...directory. (line 54 in upgrader.go). | 10:37 |
| TheMue | rogpeppe: will it be visible in the godocs too? your intention seems to be a paragraph, isn't it? | 10:37 |
| rogpeppe | TheMue: godoc will reformat the whole thing into one paragraph | 10:37 |
| rogpeppe | TheMue: i should probably cfmt the comment | 10:38 |
| jtv | rogpeppe: you have my vote. | 10:38 |
| rogpeppe | jtv: thanks | 10:38 |
| TheMue | rogpeppe: that's what I expected. | 10:38 |
| TheMue | rogpeppe: won't an empty line render as a new paragraph? | 10:38 |
| rogpeppe | TheMue: yes | 10:38 |
| rogpeppe | TheMue: i didn't really intend them to be different paras | 10:39 |
| TheMue | rogpeppe: ah, ok | 10:39 |
| TheMue | rogpeppe: reviewd | 10:39 |
| rogpeppe | TheMue: thanks | 10:39 |
| * TheMue => lunch | 11:03 | |
| mgz | hm, no mail since friday, must be imapclean day | 11:03 |
| rogpeppe | another pretty trivial CL: https://codereview.appspot.com/12025043 | 11:05 |
| dimitern | rogpeppe: does the upgrader now use the API? | 11:09 |
| rogpeppe | dimitern: yes | 11:10 |
| rogpeppe | dimitern: although cmd/jujud doesn't yet use worker/upgrader | 11:10 |
| dimitern | rogpeppe: ok (updating the blueprint) | 11:10 |
| dimitern | rogpeppe: also, you've got a review | 11:10 |
| rogpeppe | dimitern: thanks | 11:10 |
| natefinch | Hi all. In theory I am joining the juju dev team today, though HR/IT/whoever has not actually given me any login information. So I figured I'd just come here and say hi. | 11:22 |
| dimitern | natefinch: hey! welcome aboard! | 11:24 |
| dimitern | natefinch: so you'll be working on juju-core or on some related project, like the gui, etc. ? | 11:25 |
| fwereade_ | natefinch, welcome! | 11:26 |
| natefinch | Hi, thanks. You'll have to forgive me if I am not up on my IRC skills... it's been... oh god, like 15 years since I was last on irc, in college. | 11:26 |
| natefinch | I'll be on juju-core, from what Mark Ramm said | 11:27 |
| fwereade_ | natefinch, not to worry :) | 11:27 |
| fwereade_ | dimitern, hey, did the last one we released actually use the api for the machiner? or did that not get in in time? | 11:28 |
| dimitern | fwereade_: I think it did | 11:28 |
| fwereade_ | dimitern, oh bugger | 11:29 |
| fwereade_ | dimitern, ah well, not to worry | 11:29 |
| natefinch | mramm: Morning, Mark. This appears to be the only place I can access currently, FYI. | 11:31 |
| mramm | ok | 11:31 |
| dimitern | fwereade_, rogpeppe, wallyworld_: standup | 11:32 |
| wallyworld_ | i would if the stupid google plugin would upgrade | 11:33 |
| TheMue | natefinch: heya, welcome here in the channel too | 11:33 |
| dimitern | natefinch: if you want to join the daily standup: https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471 | 11:33 |
| natefinch | awesome, thanks | 11:33 |
| natefinch | TheMue: plugin installing... forgot I hadn't done that yet | 11:34 |
| ehg | hope i'm not intruding, but is there anyway to do https://bugs.launchpad.net/juju-core/+bug/1089291 manually atm? like modifying the mongo db? | 11:43 |
| _mup_ | Bug #1089291: terminate-machine --force <juju-core:Triaged> <https://launchpad.net/bugs/1089291> | 11:43 |
| mgz | mramm, natefinch: IS has the ticket for nate's new staff task, but it seems no one is on to get started with it yet. | 11:54 |
| natefinch | alexlist is giving me a hand | 11:55 |
| mramm | mgz: yea I see nobody is on vanguard yet | 11:55 |
| mgz | ace, if alex is handling it that's fine. | 11:55 |
| alexlist | Nobody around until deej starts working today ... looks very holiday-ish today ... | 11:56 |
| * dimitern lunch | 12:09 | |
| mgz | dear go, have working juju on lcy02 finally | 12:37 |
| mgz | that was painful | 12:37 |
| rogpeppe | lunch | 13:16 |
| mgz | warning all, the bot is up but not yet tweaked into happiness | 13:27 |
| mgz | I'll mail the list when I get it rolling properly again | 13:27 |
| TheMue | mgz: thanks for your effort already | 13:43 |
| rogpeppe | fwereade_: how about this for an API in common to both the machine and unit agent? http://paste.ubuntu.com/5925443/ | 14:30 |
| fwereade_ | rogpeppe, LGTM | 14:31 |
| rogpeppe | fwereade_: thanks | 14:31 |
| === tasdomas is now known as tasdomas_afk | ||
| fwereade_ | rogpeppe, are you likely to be implementing a state.Agent interface roughly matching that? because I find myself heading in a very similar dirction, I think | 15:03 |
| rogpeppe | fwereade_: i've just done the front end bits. i'm just about to do the server side. | 15:04 |
| rogpeppe | fwereade_: i'm not sure quite what you mean by the state.Agent interface | 15:04 |
| fwereade_ | rogpeppe, as Authenticator, Remover, Lifer, whatever | 15:04 |
| fwereade_ | rogpeppe, ISTM that making unit and machine's agenty methods accessible via a State.Agent() call using state.entity() would fit nicely | 15:05 |
| rogpeppe | fwereade_: perhaps. i'm not sure. | 15:05 |
| rogpeppe | fwereade_: i thought i might do Jobs as a special case | 15:05 |
| rogpeppe | fwereade_: as it doesn't really make sense to implement Unit.Jobs | 15:05 |
| rogpeppe | fwereade_: the other methods aren't really Agent - they're *used* by the agent API, which i think is a bit of a different thing | 15:06 |
| fwereade_ | rogpeppe, fwiw I think that "a unit is an agent with just one job" is quite a neat model | 15:06 |
| rogpeppe | fwereade_: i considered it, but i don't think it helps much | 15:06 |
| fwereade_ | rogpeppe, and remeber this isn't about how the API looks, it's about how it's convenient to present state to the API layer for clarity/convenience | 15:07 |
| rogpeppe | fwereade_: it makes the unit agent code more complex (what's the point of having a Jobs method that you don't consult?) | 15:07 |
| fwereade_ | rogpeppe, it eliminates the distinction between machine and unit agent | 15:07 |
| rogpeppe | fwereade_: ah, is that your intention? | 15:08 |
| fwereade_ | rogpeppe, except we're talking about different things still | 15:08 |
| fwereade_ | rogpeppe, long-term, maybe | 15:08 |
| fwereade_ | rogpeppe, but the jobs thing seems like the biggest issue | 15:08 |
| rogpeppe | fwereade_: it seems pretty trivial to me | 15:08 |
| rogpeppe | fwereade_: i'd just put a dynamic type check in the Job API entry point | 15:08 |
| fwereade_ | rogpeppe, indeed, and so "an agent is a thing that runs jobs on behalf of some entity" becomes an nice clear accurate explanation | 15:09 |
| rogpeppe | s/Job/Jobs | 15:09 |
| rogpeppe | fwereade_: i like the fact that the unit agent code is simpler than the machine agent code | 15:09 |
| rogpeppe | fwereade_: because it doesn't need to inspect dynamic jobs to run | 15:09 |
| fwereade_ | rogpeppe, but the thing I'm thinking about today is state.Agent, which would have a whole bunch of methods used by various bits of the api, eg uniter machiner upgrader | 15:10 |
| fwereade_ | rogpeppe, if that's not on your mind then all the better, we won't collide and you can see if you like it when I propose ;) | 15:11 |
| rogpeppe | fwereade_: i think it's probably better to have separate interfaces for each piece of the API | 15:11 |
| rogpeppe | fwereade_: rather than one agent interface to rule them all | 15:12 |
| rogpeppe | fwereade_: tbh i'd prefer it if each of those interfaces was defined in the respective API server package | 15:12 |
| rogpeppe | fwereade_: rather than in state | 15:12 |
| rogpeppe | fwereade_: i think that matches Go's post-hoc interface definition idiom better | 15:12 |
| fwereade_ | rogpeppe, I am not talking about the interfaces exposed by the API, I am talking about the interfaces exposed *to* the API | 15:12 |
| rogpeppe | fwereade_: that's what i'm talking about too | 15:13 |
| rogpeppe | fwereade_: i don't think the state package should need to second-guess the interfaces needed by the APIs built on top of it | 15:14 |
| fwereade_ | rogpeppe, in my mind, it's not second-guess, it's responding to clear need | 15:14 |
| rogpeppe | fwereade_: it's unnecessary - each of those API packages can define their own interface to abstract out the relevant parts of the state package | 15:15 |
| rogpeppe | fwereade_: AFAICS | 15:15 |
| rogpeppe | fwereade_: of course, state needs to define interfaces when it actually returns those interfaces (e.g. Lifer), but i'm not sure that it needs to know about Agent, for example. that seems like something built on top of it, at a different level. | 15:17 |
| rogpeppe | fwereade_: but i'm interested to hear your take on it too | 15:17 |
| fwereade_ | rogpeppe, I dunno, I think that the agent concept is already more than a little embedded in state | 15:18 |
| fwereade_ | rogpeppe, AgentTools | 15:18 |
| fwereade_ | rogpeppe, SetAganetAlive | 15:18 |
| fwereade_ | er whatever | 15:18 |
| rogpeppe | fwereade_: yes, there are bits and pieces | 15:18 |
| fwereade_ | rogpeppe, I think that collecting them together will actually be pretty clear | 15:19 |
| rogpeppe | fwereade_: as is necessary - those are pieces of agent-specific state | 15:19 |
| rogpeppe | fwereade_: calling the interface "Agent" is wrong though | 15:19 |
| rogpeppe | fwereade_: perhaps AgentEntity | 15:19 |
| rogpeppe | but i don't like that either | 15:20 |
| fwereade_ | rogpeppe, like LiferEntity and UAuthenticatorEntoty today, you mean ;p | 15:20 |
| fwereade_ | god my typing is shot today | 15:20 |
| rogpeppe | fwereade_: you started to remind me of an ex-coworker who had notoriously bad typing :-) | 15:20 |
| rogpeppe | fwereade_: Lifer defines an object with a Life method | 15:21 |
| rogpeppe | fwereade_: Authenticator defines an object with authentication methods | 15:22 |
| rogpeppe | fwereade_: Agent would *not* define an object with agent methods | 15:22 |
| rogpeppe | fwereade_: but it would simply have some methods that happen to be used by agents | 15:22 |
| rogpeppe | fwereade_: and i don't really see why that interface should be defined in state itself. | 15:22 |
| rogpeppe | fwereade_: in general we don't predefine all possible interfaces in Go, but leave it up to the client code to do that. | 15:23 |
| fwereade_ | rogpeppe, the distinction between "agent methods" and "methods that happen to be used by agents" does not seem to me to present an overwhelming practical difference | 15:23 |
| fwereade_ | rogpeppe, ISTM that if we do that we end up with the funky downcasting we already have in apiserver | 15:24 |
| rogpeppe | fwereade_: they're totally different. an agent method would be something like MachineAgent.Run. | 15:24 |
| fwereade_ | rogpeppe, "meh, everything we're calling here will have hat method, let's just use a Lifer" | 15:24 |
| fwereade_ | rogpeppe, what we're getting kinda needs to be defined at the state level | 15:25 |
| fwereade_ | rogpeppe, lots of little interfaces make sense where overlap is limited | 15:25 |
| fwereade_ | rogpeppe, bigger interfaces also make sense where there's a lot of overlap, I think | 15:25 |
| fwereade_ | rogpeppe, *even if* and given client of an Agent uses only one or two methods on it | 15:26 |
| fwereade_ | s/and/any/ | 15:26 |
| fwereade_ | rogpeppe, anyway, I'm going to go and see if the plan comes off coherently anyway ;p | 15:27 |
| fwereade_ | rogpeppe, cheers | 15:27 |
| dimitern | fwereade_, rogpeppe: https://codereview.appspot.com/12034043 - names package | 15:27 |
| rogpeppe | fwereade_: ok | 15:27 |
| dimitern | a lot of files are changed, but most changes are just renames | 15:28 |
| rogpeppe | dimitern: i think i'd put all the code into one file in names - i don't think the sizes are big enough to justify the separate files, and i'd find it easier to read like that. | 15:29 |
| dimitern | rogpeppe: i could do that, but I think separation is a good thing | 15:30 |
| rogpeppe | dimitern: why so? | 15:30 |
| rogpeppe | dimitern: i don't see that it helps anything really | 15:30 |
| rogpeppe | dimitern: other than meaning i need to flip back and forth to see what things are referring to | 15:31 |
| dimitern | rogpeppe: we could expand it later to include more stuff | 15:31 |
| rogpeppe | dimitern: we could split it into multiple files as appropriate if that happens | 15:31 |
| rogpeppe | dimitern: i find it much easier to see the whole lot on a single page | 15:31 |
| dimitern | rogpeppe: then check LP's diff :) | 15:31 |
| rogpeppe | dimitern: what about it? | 15:32 |
| dimitern | rogpeppe: but seriously, I'm not insiting on it staying like this - fwereade_ what do you think? | 15:32 |
| rogpeppe | dimitern: if nothing else, the related constants should go into the relevant files. | 15:33 |
| dimitern | rogpeppe: this makes more sense to me, ok | 15:33 |
| fwereade_ | dimitern, rogpeppe: I rather liked the bite-size nature of those files | 15:33 |
| fwereade_ | dimitern, rogpeppe: well, maybe, having all the constants in one place also has its benefits | 15:34 |
| rogpeppe | fwereade_: really? | 15:34 |
| fwereade_ | dimitern, rogpeppe: I found it very easy to absorb that package as it was | 15:34 |
| dimitern | rogpeppe: once it lands, using godef to jump to each definition is trivial | 15:34 |
| rogpeppe | fwereade_: i found myself flipping back and forth between constant and code | 15:34 |
| fwereade_ | dimitern, rogpeppe: the conceptual dividing lines are clear, and the simplicity of each chunk is also pretty clear IMO | 15:35 |
| rogpeppe | fwereade_, dimitern: constants.go blurs the conceptual dividing line | 15:35 |
| fwereade_ | rogpeppe, dimitern: the question is kinda what to do about the bits that are common | 15:35 |
| rogpeppe | fwereade_: what bits? | 15:36 |
| fwereade_ | rogpeppe, dimitern: numbers, service names | 15:37 |
| dimitern | rogpeppe: having separate constants.go made sense when I did it, but as I said, I can move them into their relevent files instead | 15:37 |
| fwereade_ | dimitern, rogpeppe: I would be fine with that though | 15:37 |
| dimitern | rogpeppe: not all of them are specific, some are common | 15:37 |
| rogpeppe | fwereade_: if we're staying in separate files (which i can live with) then service.go seems like the right place for service names | 15:37 |
| fwereade_ | dimitern, rogpeppe: OTOH, unit.go will use it too, and one day perhaps relation.go | 15:38 |
| dimitern | rogpeppe: how about NumberSnippet and others, which are used more than once? | 15:38 |
| rogpeppe | although a whole file for a 3 line function does seem like overkill | 15:38 |
| fwereade_ | dimitern, rogpeppe: having one file that describes in a very compact way all the data, and one file per entity that handles the tedious manipulation of each kind, seems to me like a reasonable balance | 15:39 |
| dimitern | rogpeppe: it's better so separate them early, rather than ending up with a monstrous module like state | 15:39 |
| fwereade_ | dimitern, rogpeppe: but I'm happy calling dealer's choice on this, this is the very definition of a bikeshed | 15:39 |
| rogpeppe | i'd really like to see the whole lot in one place, but perhaps i'm old fashioned like that. i never programmed in java. | 15:39 |
| rogpeppe | dimitern: for NumberSnippet, i'd just choose an arbitrary place | 15:40 |
| dimitern | yeah, I forgot to say <bikeshed> earlier (until we reach an agreement </bikeshed> ) :) | 15:40 |
| rogpeppe | dimitern: nicer to have the rest of the constants nearer to where they're used | 15:40 |
| dimitern | rogpeppe: so compromise: having common bits in constants.go and entity-related stuff in their respective files? | 15:41 |
| rogpeppe | dimitern: i guess. | 15:42 |
| rogpeppe | dimitern: 115 lines doesn't seem like too much for a file though. | 15:44 |
| rogpeppe | </bikeshed> | 15:44 |
| dimitern | rogpeppe: "divide and conquer" wasn't invented for java | 15:45 |
| dimitern | rogpeppe: it's generally a good practice for structuring code I think | 15:45 |
| * rogpeppe prefers each file to be worth its weight | 15:46 | |
| dimitern | rogpeppe: how big a file should be at least? | 15:47 |
| dimitern | rogpeppe: is less than 50 lines the limit? or 20? | 15:47 |
| rogpeppe | dimitern: it totally depends | 15:47 |
| dimitern | rogpeppe: of course | 15:47 |
| rogpeppe | dimitern: in this case, i think everything would fit very neatly into one file, and the common patterns in the code would be more evident that way | 15:48 |
| dimitern | rogpeppe: and mixing responsibilities in the same place is a bad idea for the sake of having less files imho | 15:48 |
| rogpeppe | dimitern: all this code is doing a very similar thing. that for me is a good indicator that it belongs together. | 15:49 |
| dimitern | rogpeppe: not really, the packge has very well defined goal, that's why it looks like that | 15:49 |
| rogpeppe | dimitern: whatever | 15:49 |
| rogpeppe | dimitern: i didn't mean this to turn into a bikeshed argument | 15:50 |
| rogpeppe | dimitern: i've stated my preference | 15:50 |
| dimitern | rogpeppe: ok | 15:50 |
| dimitern | rogpeppe: let's agree to disagree on that one | 15:51 |
| dimitern | rogpeppe: :) no need to argue about minor stuff like this | 15:51 |
| rogpeppe | dimitern: yeah | 15:51 |
| rogpeppe | dimitern: one thought: instead of returning (string, error), i'm wondering if (string, bool) might be better | 15:51 |
| rogpeppe | dimitern: i dunno though | 15:52 |
| dimitern | rogpeppe: I was thinking about it, but we already have Is*(string) bool, and most of the code that handles externally received strings is using it | 15:52 |
| rogpeppe | dimitern: yeah | 15:53 |
| dimitern | rogpeppe: only a few places expect to pass a tag and get and id/name, which is wrong I think - the tag should be checked before | 15:53 |
| dimitern | rogpeppe: and moreover, not checking the format and getting an error allows you to "defer the responsibility" of deciding what to do to your caller | 15:55 |
| rogpeppe | dimitern: yeah - it's just the single error thing - when there's only one kind of expected error, i wonder if a bool is more useful | 15:56 |
| dimitern | rogpeppe: I could do that, but then in the few cases when there's a possible error, we have to define and return that error, so potentially it creates a bit of duplication | 15:57 |
| dimitern | rogpeppe: in the place it was called | 15:57 |
| === natefinch is now known as natefinch-lunch | ||
| rogpeppe | dimitern: yeah, that's true. i have mixed feelings. | 15:58 |
| === natefinch-lunch is now known as natefinch | ||
| mgz | can I have some help working out what my last batch of test failures on the bot relate to? | 16:12 |
| mgz | https://code.launchpad.net/~themue/juju-core/035-bootstrap-autosync/+merge/177119/comments/399419/+download | 16:15 |
| mgz | one is obvious... | 16:15 |
| mgz | I guess the others may be related? | 16:15 |
| TheMue | mgz: that branch is not yet approved | 16:16 |
| mgz | I've been approving it as a test | 16:16 |
| mgz | ..is it not approved as in I should be approving it? | 16:16 |
| mgz | I thought it was the one you wanted to land... | 16:16 |
| mgz | no harm done if so, but I guess I should have used a less-real branch | 16:17 |
| mgz | ^*shouldn't | 16:17 |
| TheMue | mgz: I have to land changes first;) | 16:18 |
| mgz | okay, I'll stop using that as a g-pig | 16:19 |
| TheMue | mgz: the BootstrapSuite now show a failure it hadn't before :( | 16:19 |
| mgz | I'm proposing a trivial branch I can test with instead | 16:28 |
| mgz | took too long to find a comment change, darn william and rog being native english and not screwing up grammar enough | 16:28 |
| rogpeppe | dimitern: reviewed | 16:28 |
| dimitern | rogpeppe: cheers | 16:29 |
| mgz | and bah, we've broken 1.0 compat again | 16:29 |
| * mgz adds the ppa | 16:30 | |
| mgz | muh, and it doesn't pass go fmt | 16:33 |
| mgz | rogpeppe: how did you manage that? | 16:33 |
| rogpeppe | mgz: perhaps i ran a different gofmt on it | 16:33 |
| mgz | I guess that's my trivial change to land | 16:34 |
| rogpeppe | mgz: gofmt passes ok against trunk for me | 16:34 |
| mgz | compalins about trailing whitesapce on a comment for me | 16:35 |
| rogpeppe | mgz: what gofmt are we using as standard? | 16:36 |
| rogpeppe | mgz: i've been using go-1.0.2's gofmt for ages now | 16:36 |
| mgz | 1.0.2 is good, but not if we also break 1.0.2 compat >_< | 16:36 |
| rogpeppe | mgz: but go 1.1's does indeed complain about trunk | 16:37 |
| rogpeppe | mgz: i thought gwacl had already broken 1.0.2 compat | 16:37 |
| dimitern | fwereade: ping | 16:38 |
| rogpeppe | mgz: and yes, oops, i didn't test against 1.0.2 before submitting, and i missed a return statement | 16:38 |
| fwereade_ | dimitern, pong | 16:38 |
| fwereade_ | dimitern, blast, I should finish reviewing that | 16:38 |
| dimitern | fwereade: thanks :) | 16:38 |
| fwereade_ | dimitern, quick question -- would dropping "Name" across the board lead to less stuttering? names.IsUnitName etc | 16:38 |
| rogpeppe | fwereade_: i've made a bunch of comments which you might want to take in before you continue | 16:38 |
| rogpeppe | fwereade_: that sounds good to me | 16:39 |
| mgz | I'm self-approving my trivial bot testing branch | 16:39 |
| dimitern | fwereade: makes sense | 16:40 |
| dimitern | TheMue: I can't see the changes you said you did? | 16:52 |
| mgz | okay, my one remaining test failure is commented by rogpeppe as bug 1163983 | 16:52 |
| _mup_ | Bug #1163983: some tests take an unnecessarily long time waiting for the poll interval <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1163983> | 16:52 |
| mgz | is there anything I can do to mitigate that on the bot? | 16:52 |
| dimitern | mgz: what go version is the bot using? | 16:53 |
| dimitern | mgz: I think that failure is intermittent | 16:53 |
| mgz | from the ppa, 1.1.1 | 16:53 |
| mgz | bot has just hit it twice in a row... | 16:54 |
| * mgz reapproves to see how consistent that is | 16:54 | |
| TheMue | dimitern: not yet pushed | 16:55 |
| dimitern | mgz: it seems the issue is [LOG] 19.20390 ERROR juju worker: fatal "deployer": remove /etc/init/jujud-machine-3:unit-tarmac-0.conf: permission denied | 16:55 |
| mgz | thanks | 16:55 |
| mgz | that seems like an isolation issue... | 16:56 |
| dimitern | mgz: seems likely, it the test should be creating /tmp/gocheck-*/etc/init or something | 16:58 |
| * dimitern bbiab | 16:58 | |
| mgz | blame on that change is you? :P | 16:59 |
| mgz | ...there's nothing obviously wrong... | 17:02 |
| mgz | filed bug 1206195 | 17:08 |
| _mup_ | Bug #1206195: TestDyingMachine fails when unit agent is running on machine <juju-core:Confirmed> <https://launchpad.net/bugs/1206195> | 17:08 |
| dimitern | mgz: does it fail on your machine? on mine it doesn't | 17:20 |
| mgz | are you on a juj-deployed machine with a running unit-agent? | 17:20 |
| dimitern | well, obviously not :) | 17:20 |
| mgz | I'd not expect it to break for you then :) | 17:21 |
| dimitern | how does that matter? | 17:21 |
| mgz | because that's what the error is saying | 17:21 |
| mgz | the test is trying to talk to the bot's unit-agent, which obviously tells it to sod off, confusing the test | 17:21 |
| dimitern | how can this happen? | 17:22 |
| mgz | it really shouldn't :) | 17:22 |
| mgz | (I have no idea) | 17:23 |
| dimitern | is there a JUJU_* or ~/.juju/environments.yaml there? | 17:23 |
| mgz | in good news, the bot is now live again | 17:23 |
| mgz | dimitern: no. | 17:23 |
| dimitern | alive, like working properly? | 17:23 |
| mgz | yup. | 17:23 |
| dimitern | except for that issue above | 17:24 |
| mgz | I shall summarise to the list | 17:24 |
| mgz | that issue is gone for now, I skipped out the test | 17:24 |
| dimitern | great! thanks | 17:24 |
| dimitern | hmm, ok, i guess for the time being that's acceptable | 17:25 |
| === natefinch is now known as natefinch-lunch | ||
| TheMue | mgz: fantastic, thx | 17:29 |
| dimitern | fwereade: sorry to bug you again | 17:33 |
| rogpeppe1 | dimitern, fwereade, anyone else interested: https://codereview.appspot.com/12038045 | 17:44 |
| rogpeppe1 | and i need another review of https://codereview.appspot.com/12025043/ please | 17:45 |
| dimitern | rogpeppe1: looking | 17:45 |
| rogpeppe1 | that's me for the night | 17:45 |
| rogpeppe1 | dimitern: ta! | 17:45 |
| dimitern | rogpeppe1: nn then | 17:45 |
| rogpeppe1 | dimitern: it has the ChangeAgentTools CL mixed in unfortunately, but it's separate enough that i think it's ok for the time being | 17:48 |
| rogpeppe1 | dimitern: 'cos i'd prefer to avoid a prereq | 17:48 |
| dimitern | rogpeppe1: no worries | 17:49 |
| rogpeppe1 | right, i really am off now, to pick some peas from the garden | 17:49 |
| rogpeppe1 | g'night all | 17:49 |
| mgz | okay, I'm done for the day, email me if stuff blows up | 18:00 |
| === natefinch-lunch is now known as natefinch | ||
| Beret | can someone bump the priority of https://bugs.launchpad.net/juju-core/+bug/1188126 please? | 18:33 |
| _mup_ | Bug #1188126: Juju unable to interact consistently with an openstack deployment where tenant has multiple networks configured <canonistack> <juju:New> <juju-core:Triaged> <https://launchpad.net/bugs/1188126> | 18:33 |
| === tasdomas_afk is now known as tasdomas | ||
| sidnei | uhm, anyone around that can take a look at https://bugs.launchpad.net/juju-core/+bug/1205112 ? it's blocking me :( | 20:50 |
| _mup_ | Bug #1205112: panic while setting a config value <juju-core:Triaged> <https://launchpad.net/bugs/1205112> | 20:50 |
| === thumper--afk is now known as thumper | ||
| thumper | hi sidnei | 21:00 |
| thumper | sidnei: I don't suppose you have made it reproducable on the local provider? | 21:01 |
| * thumper woners which nick nate is | 21:01 | |
| thumper | and I see he left 19 minutes ago | 21:02 |
| thumper | oh well | 21:02 |
| thumper | arosales: do you know how I can get access to the test MAAS? | 21:11 |
| sidnei | thumper: well, i deployed a new service and got it again | 21:20 |
| sidnei | thumper: i wonder if it's charm-specific | 21:20 |
| thumper | sidnei: could be a good bug for us to give to axw | 21:20 |
| thumper | he seems to be hammering through them | 21:20 |
| thumper | I'll pass on the info when he gets on | 21:21 |
| * thumper is attacking maas | 21:21 | |
| sidnei | thumper: i suppose there's nothing like pdb for golang? | 21:21 |
| thumper | for a stack trace? | 21:21 |
| thumper | or to just stop | 21:21 |
| sidnei | thumper: no, to step through | 21:21 |
| thumper | depends how hard core you are | 21:21 |
| thumper | I have heard that there is a go part for gdb | 21:22 |
| thumper | not tried it though | 21:22 |
| sidnei | i've poked around gdb and pyframes once | 21:22 |
| sidnei | i could just add some prints around the comparison line i guess | 21:23 |
| thumper | when in the SFO go meetup, someone asked what people used for debugging | 21:24 |
| thumper | print statements was the common answer | 21:24 |
| thumper | :-( | 21:24 |
| sidnei | its choking on: | 21:24 |
| sidnei | if new == old { | 21:24 |
| sidnei | continue | 21:24 |
| sidnei | } | 21:24 |
| sidnei | in settings.go | 21:24 |
| thumper | it seems to me, having not looked at the code... | 21:25 |
| thumper | that it is failing to coerse the command line strings into int values | 21:25 |
| thumper | so comparing an int to a string representation of an int | 21:26 |
| thumper | are you changing an int value? | 21:26 |
| thumper | or numeric / bool | 21:26 |
| thumper | ie. non-string | 21:26 |
| sidnei | thumper: nope, it's a string | 21:39 |
| sidnei | one of the commands was: juju set u1-stream host_environment_name=dc -e local | 21:40 |
| sidnei | and the error is: | 21:40 |
| sidnei | panic: runtime error: comparing uncomparable type map[string]interface {} | 21:40 |
| sidnei | im suspecting it might be choking on a previously set value | 21:40 |
| sidnei | the service was deployed with deploy --config <config.yaml> | 21:41 |
| sidnei | there was no error during deploy (at least in the command line) | 21:42 |
| sidnei | it seems only half of the values from the --config config.yaml got set | 21:42 |
| andreas__ | guys, I got a "panic" from juju-core, is this a low memory situation? http://pastebin.ubuntu.com/5926829/ | 21:46 |
| === andreas__ is now known as ahasenack | ||
| thumper | sidnei: sounds very suspect | 21:46 |
| thumper | ahasenack: possibly | 21:47 |
| ahasenack | 500Mb RAM, no swap | 21:47 |
| ahasenack | 2013-07-29 21:48:21 ERROR juju uniter.go:352 worker/uniter: hook failed: fork/exec /var/lib/juju/agents/unit-nova-cloud-controller-0/charm/hooks/install: cannot allocate memory | 21:48 |
| ahasenack | hah | 21:48 |
| arosales | dpb1, looking at the bug 1205466 | 21:57 |
| _mup_ | Bug #1205466: deploy charm uses cached copy even when all services are removed <papercut> <juju-core:Triaged> <https://launchpad.net/bugs/1205466> | 21:57 |
| dpb1 | arosales: yup, need something? | 21:59 |
| arosales | dpb1, nope sorry I was catching up on backscroll | 22:01 |
| arosales | looks like mramm already commented on this bug and discussed it here | 22:01 |
| dpb1 | arosales: cool | 22:02 |
| wallyworld_ | thumper: how's things? | 22:52 |
| thumper | otp | 22:52 |
| wallyworld_ | ok | 22:52 |
| thumper | wallyworld_: hangout? | 23:12 |
| wallyworld_ | sure | 23:12 |
| wallyworld_ | https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471?v=1374717932 | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!