| === thumper-afk is now known as thumper | ||
| thumper | wallyworld_: I can't use logger as there is already a package level logger called "logger" | 01:42 |
|---|---|---|
| thumper | wallyworld_: and go doesn't give us a way to have file-local variables | 01:42 |
| thumper | davecheney: does it? | 01:43 |
| davecheney | thumper: no, there are no file local variables | 01:47 |
| davecheney | only package, func and block scopes | 01:47 |
| davecheney | what are you trying to do | 01:47 |
| thumper | davecheney: don't suppose there could be? | 01:47 |
| davecheney | ? | 01:47 |
| thumper | davecheney: idiomatic usage, at least in other languages, is to have a file local "logger" variable | 01:48 |
| thumper | this allows different files in one package to have different loggers | 01:48 |
| davecheney | thumper: you already know what i'm going to say | 01:48 |
| thumper | in my example... | 01:48 |
| thumper | I have the lxc provisioner / broker in the worker/provisioner package | 01:48 |
| thumper | davecheney: you are going to say "put them in a different package?" | 01:49 |
| thumper | however, I have the tests for them share some common suite info | 01:49 |
| thumper | and there doesn't seem to be a way to import _test declared stuff from another package | 01:49 |
| thumper | so suites need exported stuff | 01:50 |
| thumper | exported stuff in export_test only available in local package tests | 01:50 |
| thumper | shared suites then impossible | 01:50 |
| thumper | across other packages | 01:50 |
| thumper | that is part of the problem | 01:51 |
| davecheney | thumper: i am confused | 01:59 |
| davecheney | have you moved on from file scopes vars ? | 02:00 |
| thumper | davecheney: don't worry... | 02:00 |
| thumper | I was talking myself through the problem of moving them to different packages | 02:00 |
| davecheney | ok | 02:00 |
| thumper | davecheney: I've been asked to ping you | 02:12 |
| thumper | davecheney: about a problem that I have just fixed | 02:12 |
| thumper | davecheney: JujuConnSuite wasn't closing the API connections, and fwereade was wondering if this may be related to the races you were looking into | 02:12 |
| thumper | davecheney: the branch I'm about to land fixes this | 02:12 |
| davecheney | related to the mgo stuff | 02:13 |
| davecheney | could be | 02:13 |
| davecheney | let me find my notes | 02:13 |
| davecheney | land it and lets see | 02:13 |
| * thumper nods | 02:22 | |
| thumper | davecheney: what is the difference between %v and %s in a sprintf? | 02:23 |
| davecheney | %v chooses the %s,%f,%d or %b depending on the type of the thing | 02:25 |
| davecheney | it's pretty much the default unless you absolutely know you want a string | 02:25 |
| wallyworld_ | thumper: thanks for extending the comment. i didn't make the connection that embedded = nested. makes more sense now | 02:26 |
| thumper | wallyworld_: np | 02:26 |
| thumper | wallyworld_: just did a local test run | 02:27 |
| * thumper approves the mp | 02:27 | |
| wallyworld_ | yay | 02:27 |
| * thumper does a little dance | 02:27 | |
| thumper | bigger dance coming when it is actually landed | 02:27 |
| thumper | wallyworld_: this gives automatic provisioning of lxc containers | 02:28 |
| thumper | non-addressable containers, but containers none the less | 02:28 |
| wallyworld_ | yeah i know :-) will be good | 02:28 |
| * thumper had forgotten to set a commit msg | 02:44 | |
| thumper | oh arse | 03:46 |
| thumper | damn local dependencies... | 03:51 |
| davecheney | arosales: ping me when you're ready | 03:57 |
| arosales | davecheney, ping | 04:01 |
| davecheney | two secs | 04:02 |
| === tasdomas_afk is now known as tasdomas | ||
| thumper | davecheney: how do I build the tests without running them? | 04:16 |
| davecheney | go test -c is one way | 04:17 |
| davecheney | that will produce $PKG.test | 04:17 |
| thumper | hmm... don't really want anything created | 04:18 |
| davecheney | it should be in $CWD | 04:19 |
| davecheney | if it complets then your tests work fine | 04:19 |
| davecheney | this is a way to check that your tests compile on other os's | 04:19 |
| davecheney | GOOS=windows go test -c launchpad.net/juju-core/cmd/juju | 04:19 |
| davecheney | eg | 04:19 |
| davecheney | thumper: oh, you donn't want it crated | 04:20 |
| davecheney | we.... cd $(mktemp -d) && go test -c $PKG | 04:20 |
| davecheney | ^ try that | 04:20 |
| * thumper cocks his head | 04:20 | |
| * thumper sighs... | 04:37 | |
| thumper | import cycles | 04:37 |
| * thumper beats the codebase into submission | 04:45 | |
| thumper | ok, trying to land again | 04:54 |
| davecheney | thumper: sorry, was on da phone | 05:46 |
| davecheney | i may have another way to builkd, but not run tests ... | 05:46 |
| davecheney | actaully ... no | 05:46 |
| davecheney | what i was thinking of didn't work at all | 05:46 |
| davecheney | bummer | 05:46 |
| rogpeppe | thumper: i've got a script that builds all the tests but doesn't run them | 06:06 |
| rogpeppe | thumper: but it uses some of my local stuff - you'd probably want to translate it into a shell you've got installed | 06:07 |
| rogpeppe | thumper: http://paste.ubuntu.com/5803790/ | 06:08 |
| rogpeppe | thumper: i call it "gotest-c" | 06:08 |
| rogpeppe | mornin' all, BTW | 06:09 |
| jam | davecheney: you reviewed https://codereview.appspot.com/10465043/ but didn't LGTM. I don't quite understand what more you are asking for. | 06:12 |
| jam | thumper: the idiom we've used in juju-core is to create a 'testing' package when we need test-related stuff shared between other packages. We've got a small number of them in the source tree already. | 06:14 |
| jam | thumper: otherwise, why is the package level logger the wrong one? | 06:14 |
| davecheney | jam: that is correct, i was confused about the whole passing back a *string | 06:20 |
| jam | davecheney: well it works just fine. I suppose I could pass it back via a buffered channel if it makes you feel happier | 06:21 |
| rogpeppe | davecheney, thumper: here's a bash version of my "gotest-c" script: http://paste.ubuntu.com/5803813/ | 06:28 |
| rogpeppe | davecheney, thumper: you'll have to go get code.google.com/p/rog-go/cmd/pxargs first though | 06:29 |
| rogpeppe | davecheney, thumper: then you can do "gotest-c ./..." build all tests without running them. i use it a lot | 06:29 |
| === thumper is now known as thumper-afk | ||
| thumper-afk | rogpeppe: ta | 06:31 |
| rogpeppe | thumper-afk: you might want to adjust the "5" constant, which should really be dependent on the number of cpus you've got | 06:32 |
| rogpeppe | thumper-afk: actually, i fell foul of the usual bourne shell quoting gotchas. this is slightly better: http://paste.ubuntu.com/5803829/ | 06:38 |
| === thumper-afk is now known as thumper | ||
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: dimitern | Bugs: 6 Critical, 83 High - https://bugs.launchpad.net/juju-core/ | ||
| jam | rogpeppe: merge conflict on submitting your patch again. I got my patch landed which resolved some of the previous Resource changes. | 08:46 |
| rogpeppe | jam: darn, ok thanks | 08:47 |
| rogpeppe | jam: it had a transitory error when i landed it before (must fix those tests!) | 08:47 |
| jam | rogpeppe: yeah, I haven't seen that failure before, so I wasn't sure. | 08:47 |
| * thumper afk until the meeting in 2 hours | 09:06 | |
| === thumper is now known as thumper-afk | ||
| wallyworld_ | mgz_: ping | 09:13 |
| rogpeppe | jam: re-approved. let's see if it lands this time. | 09:30 |
| jtv | Probably a beginner's question... when export_test.go exports something from a package, is there anything else that needs to be done to make it available to tests outside the package? | 09:32 |
| jtv | I tried importing launchpad.net/juju-core/environs/local, and then using local.Listen in my test — but the compiler insisted that local.Listen was undefined. | 09:32 |
| jtv | But the local provider's own tests can do the same thing and not have that problem. | 09:33 |
| dimitern | https://codereview.appspot.com/10617043/ | 09:35 |
| jtv | dimitern: is that an answer for me or are you asking for a review? | 09:40 |
| dimitern | jtv: for review :) | 09:40 |
| jtv | Ah :( | 09:40 |
| jtv | Trade you? | 09:40 |
| dimitern | jtv: sorry wasn't paying attention - will read the backlog | 09:41 |
| jtv | Thanks. | 09:41 |
| dimitern | jtv: so export_test makes package internals available to tests, but only inside the same package | 09:41 |
| jtv | ...But the export_test.go is in the "local" package, and the test that makes use of it is in the "local_test" package. How does that work? | 09:42 |
| dimitern | jtv: go magic :) | 09:42 |
| * jtv screams at heavens | 09:42 | |
| dimitern | jtv: anything with packagename_test is accessible in tests, including stuff in export_test | 09:43 |
| dimitern | jtv: if you need something from a tests package in more than one place, it's best to factor it out in a common testing package | 09:43 |
| jtv | Damn. | 09:43 |
| dimitern | wallyworld_: bug 1195223 | 09:44 |
| _mup_ | Bug #1195223: juju all-machines.log is repetitive and grows unbounded <juju-core:New for wallyworld> <https://launchpad.net/bugs/1195223> | 09:44 |
| jtv | Deeper and deeper into the rabbit hole for a single job... :( | 09:44 |
| dimitern | jtv: what do you need? | 09:44 |
| jtv | I need to invoke local.Listen, for purposes related to the local package, in my test. | 09:44 |
| * rogpeppe goes for breakfast | 09:44 | |
| * dimitern looks at local.Listen | 09:45 | |
| dimitern | jtv: and you need to invoke it where? | 09:46 |
| jtv | In a test for the azure provider, where I use the local provider's storage implementation as a test double. | 09:46 |
| dimitern | jtv: that's probably a bad idea | 09:46 |
| dimitern | jtv: the local provider's storage is overengineered and probably needs to be simplified | 09:47 |
| jtv | Oh great. I was using the dummy provider's one, but fwereade preferred me to use the local provider's storage. | 09:47 |
| dimitern | jtv: if you just need a simple http server, why not create one and handle a specific url? | 09:47 |
| rogpeppe | jtv: why not just export local.listen? | 09:47 |
| jtv | rogpeppe: that's what I did to get it working, but now I'm trying to find out what the "proper" way would have been! | 09:48 |
| jtv | dimitern: I do not want a simple http server! | 09:48 |
| jtv | I don't want any http at all. | 09:48 |
| rogpeppe | jtv, dimitern: i think it's perfectly reasonable to have a working local storage provider from local that other things can use | 09:48 |
| jtv | I just need a test double for a storage object. | 09:48 |
| dimitern | jtv: yeah, that's another option - just export local.listen and NewStorage and get rid of export_test | 09:48 |
| jtv | That's what I did, actually — but I figured since *another* package used the export_test trick, it looked as if I ought to be able to as well. | 09:49 |
| dimitern | jtv: nah.. it only works inside the same package | 09:49 |
| jtv | Well it's exported from package "local" and imported into package "local_test" | 09:50 |
| jtv | And I do mean package, not source file. | 09:50 |
| dimitern | jtv: yeah, but the azure provider is in a different package, hence it's not visible, even if you import it | 09:51 |
| jtv | Oh God don't tell me the rule is "exported exactly 1 package up, but no more"! | 09:51 |
| dimitern | rogpeppe: care for a review after breakfast? https://codereview.appspot.com/10617043/ | 09:52 |
| jtv | dimitern: I was already looking at yours actually. My end of the implied bargain. :) | 09:52 |
| dimitern | jtv: sweet! | 09:52 |
| fwereade | jtv, dimitern: I suggested the local provider's storage because it's independent and it works | 09:58 |
| fwereade | jtv, dimitern: and if we make it simpler, then great | 09:58 |
| dimitern | fwereade: it has to be exported to work like that | 09:59 |
| jtv | Not in this branch though. Gotta manage the scope of a branch or things will get waaaay out of hand. :) | 09:59 |
| fwereade | dimitern, I'm fine exporting it somewhere -- tying storage implementations to providers is kinda dumb in the first place | 09:59 |
| rogpeppe | jtv: i suggest that you change environs/local to export an interface like this: http://paste.ubuntu.com/5804251/ | 10:00 |
| rogpeppe | fwereade: does that seem reasonable to you? | 10:00 |
| dimitern | rogpeppe: +1 | 10:00 |
| fwereade | rogpeppe, looks sane | 10:00 |
| rogpeppe | actually, NewStorage should probably be func NewStorage(addr string) environs.Storage | 10:00 |
| fwereade | rogpeppe, better yet | 10:01 |
| rogpeppe | unless there were some fancy introspection methods we'd want to put on it | 10:01 |
| rogpeppe | but i can't think of any | 10:01 |
| rogpeppe | jtv: the changes to environs/local to do that should be pretty trivial | 10:01 |
| fwereade | rogpeppe, it would still be best if it were actually outside local | 10:02 |
| rogpeppe | fwereade: environs/localstorage ? | 10:02 |
| fwereade | rogpeppe, sounds reasonable | 10:02 |
| rogpeppe | filestorage? | 10:02 |
| rogpeppe | localstorage.New(addr string) environs.Storage | 10:03 |
| rogpeppe | or Client | 10:03 |
| fwereade | rogpeppe, TrivialStorage :/ | 10:03 |
| rogpeppe | fwereade: nah - it's actually potentially useful and not *entirely* trivial | 10:04 |
| fwereade | rogpeppe, as you like :) | 10:04 |
| rogpeppe | jtv, fwereade, dimitern: i think this is a bit better actually: http://paste.ubuntu.com/5804267/ | 10:06 |
| dimitern | rogpeppe: sgtm | 10:07 |
| jtv | dimitern: done with your review | 10:13 |
| * jtv catches up on backscroll | 10:13 | |
| dimitern | jtv: thanks | 10:13 |
| dimitern | jtv: helpful comments, cheers | 10:16 |
| jtv | np | 10:16 |
| jtv | Deal's a deal. :) | 10:16 |
| wallyworld_ | fwereade: you happy with https://codereview.appspot.com/10447045/ now? | 10:17 |
| jtv | rogpeppe, fwereade: it's never *entirely* trivial — if you don't mind I'll just make that a separate branch, and first get this never-landing branch saga to a conclusion. | 10:18 |
| wallyworld_ | mgz_: ping | 10:22 |
| fwereade | wallyworld_, helldamn I have drafts | 10:23 |
| fwereade | wallyworld_, let me see what I said, just a mo | 10:24 |
| fwereade | wallyworld_, sent; give it a quick read and let me know what you think | 10:25 |
| wallyworld_ | fwereade: also, on introducing a new DeploymentValue constraint embedding Value - to make this viable, I'll need to introduce a new Constraints interface | 10:26 |
| wallyworld_ | and use that throughout the codebase where feasible | 10:26 |
| wallyworld_ | given Go lacks polymorphism and other useful inheritance constructs | 10:26 |
| fwereade | wallyworld_, I lean towards keeping it a single type until we've seen how the actual usage patterns end up | 10:27 |
| wallyworld_ | fwereade: so this would mean adding checks to other places where container constraint is not valid | 10:27 |
| wallyworld_ | besides add-machine | 10:28 |
| fwereade | wallyworld_, I think that's more than we need actually -- just an understanding that different bits of the system pay attention to different parts of the constraints | 10:28 |
| wallyworld_ | fwereade: i'd rather code defensively and fail if people try and pass in the wrong thing | 10:29 |
| wallyworld_ | the system should fail if given invalid inputs | 10:29 |
| wallyworld_ | as people might have certain expectations and winder why stuff didn;t behave as expected | 10:29 |
| fwereade | wallyworld_, agreed re *inputs* -- so I think what you did originally was fine -- but internally I think it's ok that different components pay attention to different parts of the structure | 10:30 |
| fwereade | wallyworld_, if I knew for sure which parts handled what I'd be keener on splitting the type | 10:30 |
| wallyworld_ | fwereade: right, that's indeed how i coded it | 10:30 |
| fwereade | wallyworld_, but I don't think we know enough to get it right there | 10:30 |
| fwereade | wallyworld_, sorry for all the hassles | 10:31 |
| fwereade | s/right there/right yet/ | 10:31 |
| wallyworld_ | fwereade: i'm happy to defer the work, i just seem to recall you were unhappy with what i did but now it seems you agree? | 10:31 |
| wallyworld_ | i'm saying that from memory | 10:31 |
| wallyworld_ | will have to re-read the comments | 10:31 |
| fwereade | wallyworld_, yeah, I was a bit more paranoid than I think I needed to be -- sorry about that | 10:31 |
| wallyworld_ | np | 10:32 |
| wallyworld_ | fwereade: just read the comments on the instance data branch. all good, i'll make the tweaks suggested. thanks for pointing out the checker, i didn't know we had one | 10:34 |
| fwereade | wallyworld_, I think it's very new | 10:35 |
| wallyworld_ | fwereade: i'll try to get it done before bed, but if not first thing tomorrow | 10:35 |
| dimitern | fwereade: can we get rid of WatchPrincipalUnits and WatchSubordinateUnits now after I land this? | 10:36 |
| dimitern | fwereade: no one else is using them | 10:37 |
| dimitern | jtv: if you don't mind I'll do the loggo and if/else if/else changes in follow-ups | 10:41 |
| dimitern | fwereade: ping | 10:50 |
| fwereade | dimitern, pong, quickly, meeting in 10 :) | 10:50 |
| dimitern | fwereade: ^^ | 10:50 |
| fwereade | dimitern, ah sorry missed that | 10:50 |
| fwereade | dimitern, hmm | 10:50 |
| fwereade | dimitern, let's not just yet | 10:50 |
| dimitern | fwereade: I mean in a follow-up | 10:50 |
| dimitern | fwereade: or you think it's useful to keep them for now? | 10:51 |
| fwereade | dimitern, yeah, I'm just not sure I want to drop them yet | 10:51 |
| dimitern | fwereade: ok then | 10:51 |
| dimitern | rogpeppe: so do we have API connection for all agents now? | 10:53 |
| rogpeppe | dimitern: no, the unit agent doesn't have an API connection yet | 10:54 |
| rogpeppe | dimitern: it needs the uniter facade first | 10:54 |
| dimitern | rogpeppe: but openState now opens an API connection in agent.go? | 10:54 |
| jtv | dimitern: fine with me! | 10:54 |
| rogpeppe | dimitern: yes | 10:54 |
| * jtv stalks off to get a stiff drink | 10:55 | |
| dimitern | rogpeppe: my question is: once I implement the deployer facade, can I start replacing state calls for api calls and have a connection? | 10:55 |
| rogpeppe | dimitern: yes | 10:55 |
| dimitern | rogpeppe: sweet! | 10:55 |
| rogpeppe | dimitern: we also need the agent-alive mechanism in place | 10:57 |
| dimitern | rogpeppe: yeah, but not for the deployer at least | 10:58 |
| rogpeppe | dimitern: the deployer isn't its own agent, is it? | 10:59 |
| rogpeppe | dimitern: ah, it's just a worker alongside the machiner | 10:59 |
| rogpeppe | dimitern: cool | 10:59 |
| dimitern | rogpeppe: no, but it has its own facade | 10:59 |
| rogpeppe | dimitern: that sounds good | 10:59 |
| rogpeppe | dimitern: when you do the deployer facade, please follow the example of apiserver/client | 10:59 |
| dimitern | rogpeppe: that at least haven't changed while i was gone, right? a facade per worker/agent | 11:00 |
| dimitern | rogpeppe: you mean with root replacement after login? | 11:00 |
| rogpeppe | dimitern: i.e. a top level API type with a single method: Deployer(id string) (*Deployer, error) | 11:00 |
| rogpeppe | dimitern: currently there's still only a single root type after login | 11:00 |
| dimitern | rogpeppe: ok, will follow it | 11:00 |
| rogpeppe | dimitern: when all the facades are factored out into their own packages, we'll do a switch on the user name after login and choose a facade to present | 11:01 |
| rogpeppe | dimitern: each kind of client will have its own package (e.g. machine, unit, client) which will have an API type that presents the whole API for that client, integrating in all the facades as necessary | 11:01 |
| dimitern | rogpeppe: i'd like to see that | 11:01 |
| rogpeppe | dimitern: if that seems ok to you | 11:01 |
| rogpeppe | dimitern: i'm knocking up a spike proof of concept | 11:02 |
| dimitern | rogpeppe: cool | 11:02 |
| * dimitern waiting impatiently for tarmac (hopefully not to kick me in the teeth :) | 11:04 | |
| rogpeppe | jtv, fwereade, dimitern: https://codereview.appspot.com/10678043/ (only slightly less trivial than i thought) | 11:11 |
| dimitern | rogpeppe: on it | 11:11 |
| * rogpeppe wants a "wait for tarmac" command that waits for a branch and prints tarmac's final judgement on it | 11:14 | |
| dimitern | juju wait-tarmac --retry-intermittent-failures ? :) | 11:15 |
| * TheMue -> lunchtime | 11:16 | |
| dimitern | \o/ Merged! | 11:17 |
| dimitern | rogpeppe: you've got a review | 11:18 |
| rogpeppe | dimitern: ta! | 11:18 |
| rogpeppe | TheMue: i'd appreciate a review from you too, as it was your code originally, i believe: https://codereview.appspot.com/10678043/ | 11:20 |
| dimitern | so are we all now doing the standup/meeting now instead of kanban? | 11:26 |
| rogpeppe | hmm, trunk is broken live: 2013-06-27 11:28:30 ERROR juju runner.go:198 worker: fatal "lxc-provisioner": error executing "lxc-ls": exec: "lxc-ls": executable file not found in $PATH | 11:29 |
| jam | mgz_, dimitern, danilos, wallyworld_: i'm in the manager meeting, but we'll likely wrapup quickly | 11:33 |
| wallyworld_ | rogpeppe: thumper's fault! | 11:34 |
| rogpeppe | wallyworld_: yeah, but actually it's doubly broken. i have also broken it :-( | 11:34 |
| rogpeppe | wallyworld_: am working on a fix for the other issue now | 11:35 |
| wallyworld_ | the more the merrier :-) | 11:35 |
| rogpeppe | wallyworld_: well, i'll incorporate a fix for apt-get lxc too | 11:35 |
| wallyworld_ | \o/ | 11:35 |
| thumper-afk | rogpeppe: eh? | 11:38 |
| === thumper-afk is now known as thumper | ||
| jam | d | 11:38 |
| jam | dimitern: https://code.launchpad.net/~jameinel/goose/transfer-content-length-1124561/+merge/170976 | 11:38 |
| thumper | rogpeppe: no, trunk is good | 11:38 |
| rogpeppe | thumper: ah! | 11:38 |
| thumper | it landed | 11:38 |
| rogpeppe | thumper: i've just realised why it happened | 11:38 |
| rogpeppe | thumper: i upgraded | 11:38 |
| rogpeppe | thumper: and upgrading just gets the binaries | 11:38 |
| rogpeppe | thumper: it doesn't install new dependencies | 11:38 |
| thumper | rogpeppe: oh, and the machines don't have lxc | 11:38 |
| rogpeppe | thumper: yeah | 11:38 |
| thumper | that seems like it could be a problem | 11:38 |
| thumper | do we have a plan for that? | 11:39 |
| rogpeppe | thumper: not yet :) | 11:39 |
| thumper | ok, and with that, I'm off | 11:39 |
| rogpeppe | thumper: i think it could be quite simple though; we'll see | 11:39 |
| * thumper nods | 11:39 | |
| thumper | night everyone | 11:39 |
| * rogpeppe goes for some lunch and packing | 11:48 | |
| rogpeppe | i might be a couple of hours, but i will be back | 11:48 |
| mattyw | fwereade, do you know if anyone is doing https://bugs.launchpad.net/juju-core/+bug/1191066? I thought I might give it a go to help me get setup on contributing to core | 11:49 |
| _mup_ | Bug #1191066: ssh command line help incorrect <bitesize> <cmdline> <juju-core:Triaged> <https://launchpad.net/bugs/1191066> | 11:49 |
| TheMue | rogpeppe: back from lunch, let me just propose my code (test is done) and then you'll get the review | 11:49 |
| fwereade | mattyw, not that I'm aware of | 11:49 |
| dimitern | jtv, rogpeppe, fwereade: almost trivial https://codereview.appspot.com/10681044 | 11:50 |
| fwereade | mattyw, fwiw I am doing another pass through the bugs and have started to tag "easy" as well as "bitesize" | 11:50 |
| mattyw | fwereade, ok cool, I'll keep any eye out for that | 11:50 |
| fwereade | mattyw, where "bitesize" implies few lines of code to fix, and "easy" also implies that you shouldn't need to know too much arcane junk | 11:50 |
| fwereade | to identify which lines | 11:51 |
| wallyworld_ | fwereade: with bug 1130051 you pointed out in your review, it is implicitly fixed by the new implementation :-) | 11:52 |
| _mup_ | Bug #1130051: juju ssh doesn't wait properly for instance id <bitesize> <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1130051> | 11:52 |
| fwereade | wallyworld_, hmm, doesn't it short-circuit to checking the doc id? maybe I misremembered | 11:52 |
| fwereade | wallyworld_, I probably did | 11:53 |
| wallyworld_ | fwereade: only for old machines, where the instance id should be set already | 11:53 |
| jam | mramm: there is no hangout for API meeting in 10 minutes. Are we just doing it on IRC? | 11:53 |
| wallyworld_ | fwereade: new ones will have the instance id in the new doc | 11:53 |
| mramm | jam: that is fine with me | 11:54 |
| fwereade | wallyworld_, ok, and you always check for a doc first? cool | 11:54 |
| wallyworld_ | fwereade: yes | 11:54 |
| mramm | or I can add one in quickly | 11:54 |
| mramm | whatever is most efficient ;) | 11:54 |
| mramm | added one to the invite in case we want it | 11:54 |
| mramm | I *think* we can go more quickly this week, and probably don't need an hour. | 11:55 |
| jam | mramm: I'm on the hangount | 12:00 |
| jam | fwereade: care to join us for a fast API overview? https://plus.google.com/hangouts/_/91b92a337684b97321e7521463a14ec318401052 | 12:02 |
| mattyw | just made my first attempt at fixing a small bug: https://codereview.appspot.com/10683043/ | 12:13 |
| jcastro | hey guys, I'm trying to file bugs on the documentation, but they seem to show up on juju-core, not juju-core/docs | 12:59 |
| jcastro | I submitted via https://bugs.launchpad.net/juju-core/docs | 12:59 |
| jam | jcastro: there is no 'juju-core/docs' package, just a branch | 12:59 |
| jam | jcastro: if you want them to show up in that series... just a sec | 13:00 |
| jam | jcastro: can you link a bug? | 13:00 |
| jam | jcastro: I just did something here: https://bugs.launchpad.net/juju-core/+bug/1195293 | 13:01 |
| _mup_ | Bug #1195293: Docs need workflow contribution examples <juju-core:New> <juju-core docs:New> <https://launchpad.net/bugs/1195293> | 13:01 |
| jam | you can use the "Target to series" link undernead the bug tasks | 13:01 |
| jam | jcastro: I now see stuff in https://bugs.launchpad.net/juju-core/docs so hopefully its doing what you want | 13:06 |
| jcastro | ok got it! | 13:06 |
| === BradCrittenden is now known as bac | ||
| jcastro | jam: so there's no way for me to report doc bugs without spamming you guys? | 13:12 |
| jam | jcastro: 'juju-core/docs' is configured as a juju-core series, not as a separate project. So you have to target bugs to the series | 13:14 |
| jcastro | yeah so nick just landed new docs, so there might be a buncha little bugs coming in | 13:14 |
| jam | jcastro: when submitting a new bug, it is possible to target a milestone immediately, but for a series you have to submit the bug, then come back and set a target | 13:15 |
| * jcastro nods | 13:15 | |
| jam | jcastro: it is a bit of an misuse of launchpad to have a branch called lp:juju-core/docs that isn't actually a branch of juju-core source code | 13:16 |
| jam | Arguably it should be called lp:juju-core-docs | 13:16 |
| jcastro | we were inside of core before, and then we moved out, and now we're moving back in | 13:16 |
| robbiew | lol | 13:16 |
| jam | jcastro: we can live with what you have, but it doesn't fit the LP model. | 13:16 |
| jcastro | not my decision, and I don't even know why or how | 13:17 |
| jam | jcastro: as in there will be a juju-core/docs subdirectory with the website ? | 13:17 |
| jam | or just we are sharing the project name ? | 13:17 |
| jcastro | the html docs are in there | 13:17 |
| jcastro | and they went live this morning, and I just wanted to fix a <pre> tag. :) | 13:18 |
| jam | jcastro: I mean, when I do "bzr branch lp:juju-core" today, I don't get docs | 13:18 |
| jam | is the intent that the html docs will share the same source tree as the code | 13:18 |
| jam | ? | 13:18 |
| jcastro | I belive so | 13:19 |
| jcastro | let me get evilnick for you. | 13:19 |
| jam | jcastro: if so, then it makes sense to have them in one project, and eventually lp:juju-core/docs will be merged into lp:juju-core | 13:19 |
| jam | If they are intended to be developed "independently" then it would make more sense to have them as separate LP projects. | 13:19 |
| * dimitern lunch | 13:19 | |
| jcastro | I think the intent was together so like we can maintain docs for stable vs. trunk, etc. | 13:20 |
| evilnickveitch | jcastro, hey | 13:20 |
| jam | jcastro: well, you could do that anyway, though you'd have to take care to branch when we branch. | 13:20 |
| jam | we could share the https://launchpad.net/juju-project | 13:20 |
| jam | as for ownership, bug visibilicty, etc. | 13:20 |
| jam | we already have several projects there related to dependent code that we are also maintaining | 13:20 |
| jcastro | evilnickveitch: hey so jam thinks he can help organize this better | 13:21 |
| jcastro | but all I wanted to do is drive by fix some docs with no other responsibilities. :) | 13:22 |
| evilnickveitch | jcastro :) | 13:22 |
| evilnickveitch | jam, so what's the plan? | 13:22 |
| * jcastro slowly tiptoes away from the conversation | 13:22 | |
| jam | evilnickveitch: I'm just trying to get a feel for how we are wanting to use Launchpad to manage the thing currently called "juju-core/docs" | 13:23 |
| jam | LP has the idea that everything underneath a given project shares the same source code and bugs | 13:24 |
| jam | So having a "juju-core/docs" as a series (rather than a related-but-independent project) confuses things like bug triage | 13:24 |
| evilnickveitch | jam, uhuh. I was following the model from the previous juju + juju/docs model. but yes, I have noticed that | 13:24 |
| evilnickveitch | jam should we just have it as a standalone project then? | 13:25 |
| jam | evilnickveitch: that is how I would do it | 13:25 |
| jam | called juju-core-docs | 13:25 |
| jam | or juju-docs | 13:25 |
| jam | It can be part of the 'juju-project' if we want to be clear about the affiliation | 13:25 |
| jam | and make it easy to share bug maintainers, etc. | 13:25 |
| fwereade | evilnickveitch, fwiw, I just this morning tagged a couple of juju-core bugs as "doc" because I *think* they stem from inadequate communication | 13:26 |
| jam | But otherwise, when people make a change to docs, it is going to show up as a branch against juju-core itself, etc. | 13:26 |
| evilnickveitch | fwereade, thanks! | 13:26 |
| fwereade | evilnickveitch, there will surely be more :) | 13:26 |
| evilnickveitch | jam, yes, it is a bit confusing - I am not sure how it used to work with the old juju project. | 13:26 |
| evilnickveitch | jam, but it will be painful for me to trawl through bugs and target them to docs series all the time | 13:27 |
| jam | evilnickveitch: right, and if we really want a 'juju-core' bug to also be a 'juju-core-docs' bug, we can still target both projects | 13:28 |
| evilnickveitch | jam, sure. I think that will happen! | 13:28 |
| jam | evilnickveitch: I'm pretty sure having a separate project will just fit LP's model better, and still let us do everything we want. | 13:29 |
| evilnickveitch | jam, cool. I will sort it out | 13:30 |
| === BradCrittenden is now known as bac | ||
| benji__ | teknico: I'll take it | 13:31 |
| benji__ | pfft; wrong channel | 13:31 |
| === benji__ is now known as benji | ||
| === benji is now known as Guest32120 | ||
| evilnickveitch | jam, although, another option might be to host the docs with the juju-core code. | 13:40 |
| jam | evilnickveitch: I could live with either, but I think either would be better than what we have today. | 13:42 |
| evilnickveitch | jam, okay, will discuss with arosales et al. | 13:43 |
| jam | evilnickveitch: I probably slightly lean towards separate projects, mostly because I don't think people will want the raw HTML who are developing the source code (because the target audience is different), but I'm not strongly that way. | 13:44 |
| evilnickveitch | jam, to be honest, in some ways it would be easier for me if it was a separate project too. But there are advantages to it being contained alongside the main code. | 13:45 |
| evilnickveitch | it makes versioning a lot simpler for one thing, and maybe it isn't a bad idea that coders also realise that docs exist :) | 13:46 |
| fwereade | jam, hey, about the upgrader -- for maximum simplicity, I think we should be able to just EntityWatcher the env config, and then have an api method taking series/arch and returning a *Tools | 13:50 |
| fwereade | jam, we can still pass series/arch in for smarter watching in future | 13:50 |
| wallyworld_ | fwereade: could you take a peek at my comments on https://codereview.appspot.com/10534043/ and if my thinking is aligned with yours, i'll polish off the branch tomorrow. in particular the bit on env vs deployment constraints and general usage | 14:01 |
| === wedgwood_away is now known as wedgwood | ||
| fwereade | wallyworld_, will do | 14:02 |
| ackk | hi, is there a way to get the environment UUID through the juju-core API? | 14:04 |
| fwereade | ackk, ...apparently not? this is slightly surprising, but maybe the GUI hasn't wanted to use it yet | 14:15 |
| fwereade | ackk, that's been the primary driver for the public API | 14:15 |
| ackk | fwereade, right. It'd be nice to have it in the EnvironmentInfo, though | 14:16 |
| fwereade | ackk, yeah, agreed, that should be a nice easy fix and it should kinda obviously be there | 14:17 |
| ackk | fwereade, I just opened a bug for it, FIY: #1195344 | 14:20 |
| dimitern | ackk: if you type "bug 1195344" _mup_ will print a link to it | 14:25 |
| _mup_ | Bug #1195344: Add the environment UUID to EnvironmentInfo response <juju-core:New> <https://launchpad.net/bugs/1195344> | 14:25 |
| ackk | dimitern, thanks | 14:26 |
| fwereade | ackk, tyvm | 14:27 |
| TheMue | dimitern: thx for review | 14:34 |
| dimitern | TheMue: yw | 14:34 |
| TheMue | dimitern: will add a comment, assert is just to ensure, that at least two runs have been done so that times could be compared | 14:35 |
| dimitern | TheMue: my comment was not specifically for the assert, but for the for loop mostly | 14:35 |
| dimitern | TheMue: thanks | 14:35 |
| TheMue | dimitern: ah, ic | 14:39 |
| TheMue | dimitern: ok, will find some words. it's based on a discussion we had during kanban ;) | 14:39 |
| dimitern | TheMue: yeah, but you can see how it can be confusing - if it's hard to describe in a couple of sentences it might not be a good idea :) | 14:41 |
| mramm | can somebody join the cross-team juju call? | 14:45 |
| mramm | fwereade: ^^^ | 14:45 |
| === tasdomas is now known as tasdomas_afk | ||
| mattyw | dimitern, linking an MP to the bug, do I still just do that as I normally would do in launchpad or is there something I need to do in rietveld? | 15:20 |
| dimitern | mattyw: you can pass -bug="" in lbox or just link it in LP | 15:20 |
| mattyw | dimitern, ok thanks | 15:23 |
| dimitern | TheMue: can you take a look at this mostly trivial CL? https://codereview.appspot.com/10681044/ | 15:32 |
| TheMue | dimitern: sure | 15:33 |
| fwereade_ | mramm, hell, sorry, I was having a very late lunch | 15:33 |
| dimitern | TheMue: thanks | 15:33 |
| TheMue | dimitern: you've got a +1 | 15:35 |
| dimitern | TheMue: cheers | 15:36 |
| rogpeppe | fwereade_: ping | 17:43 |
| rogpeppe | fwereade_: ping | 18:57 |
| wallyworld_ | fwereade_: you around? | 20:47 |
| thumper | morning | 21:27 |
| fwereade_ | wallyworld_, heyhey, I'm around if it's quick :) | 22:35 |
| fwereade_ | wallyworld_, I'm still not sure there's a firm distinction between provisioning and deployment constraints | 22:38 |
| wallyworld_ | fwereade_: hi, was just pinging you to hopefully +1 that instance metadata branch | 22:39 |
| fwereade_ | wallyworld_, but it did just cross my mind that we probably don't want to use "" to mean "no containerization", because the current meaning of "" elsewhere is "I don't care" | 22:39 |
| fwereade_ | wallyworld_, "none" might work better | 22:40 |
| wallyworld_ | fwereade_: ok, so i can introduce a new value | 22:40 |
| fwereade_ | wallyworld_, I'll take a look sorry about that | 22:40 |
| wallyworld_ | none sounds good | 22:40 |
| wallyworld_ | if you +1 it, i'll then nag thumper :-) | 22:40 |
| wallyworld_ | thumper: could you look at this one (display hardware info in status)? https://codereview.appspot.com/10667043/ | 22:46 |
| thumper | ok | 22:46 |
| wallyworld_ | thumper: thanks. as a matter of consistency, i prefer not to name variables the same as packages irrespective of if the package is accessed in the scope of the variable. just easier to read the code etc | 23:08 |
| fwereade_ | wallyworld_, reviewed | 23:15 |
| * fwereade_ bed | 23:15 | |
| wallyworld_ | fwereade_: thanks | 23:22 |
| === wedgwood is now known as wedgwood_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!