/srv/irclogs.ubuntu.com/2013/06/27/#juju-dev.txt

=== thumper-afk is now known as thumper
thumperwallyworld_: I can't use logger as there is already a package level logger called "logger"01:42
thumperwallyworld_: and go doesn't give us a way to have file-local variables01:42
thumperdavecheney: does it?01:43
davecheneythumper: no, there are no file local variables01:47
davecheneyonly package, func and block scopes01:47
davecheneywhat are you trying to do01:47
thumperdavecheney: don't suppose there could be?01:47
davecheney?01:47
thumperdavecheney: idiomatic usage, at least in other languages, is to have a file local "logger" variable01:48
thumperthis allows different files in one package to have different loggers01:48
davecheneythumper: you already know what i'm going to say01:48
thumperin my example...01:48
thumperI have the lxc provisioner / broker in the worker/provisioner package01:48
thumperdavecheney: you are going to say "put them in a different package?"01:49
thumperhowever, I have the tests for them share some common suite info01:49
thumperand there doesn't seem to be a way to import _test declared stuff from another package01:49
thumperso suites need exported stuff01:50
thumperexported stuff in export_test only available in local package tests01:50
thumpershared suites then impossible01:50
thumperacross other packages01:50
thumperthat is part of the problem01:51
davecheneythumper: i am confused01:59
davecheneyhave you moved on from file scopes vars ?02:00
thumperdavecheney: don't worry...02:00
thumperI was talking myself through the problem of moving them to different packages02:00
davecheneyok02:00
thumperdavecheney: I've been asked to ping you02:12
thumperdavecheney: about a problem that I have just fixed02:12
thumperdavecheney: JujuConnSuite wasn't closing the API connections, and fwereade was wondering if this may be related to the races you were looking into02:12
thumperdavecheney: the branch I'm about to land fixes this02:12
davecheneyrelated to the mgo stuff02:13
davecheneycould be02:13
davecheneylet me find my notes02:13
davecheneyland it and lets see02:13
* thumper nods02:22
thumperdavecheney: 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 thing02:25
davecheneyit's pretty much the default unless you absolutely know you want a string02:25
wallyworld_thumper: thanks for extending the comment. i didn't make the connection that embedded = nested. makes more sense now02:26
thumperwallyworld_: np02:26
thumperwallyworld_: just did a local test run02:27
* thumper approves the mp02:27
wallyworld_yay02:27
* thumper does a little dance02:27
thumperbigger dance coming when it is actually landed02:27
thumperwallyworld_: this gives automatic provisioning of lxc containers02:28
thumpernon-addressable containers, but containers none the less02:28
wallyworld_yeah i know :-) will be good02:28
* thumper had forgotten to set a commit msg02:44
thumperoh arse03:46
thumperdamn local dependencies...03:51
davecheneyarosales: ping me when you're ready03:57
arosalesdavecheney, ping04:01
davecheneytwo secs04:02
=== tasdomas_afk is now known as tasdomas
thumperdavecheney: how do I build the tests without running them?04:16
davecheneygo test -c is one way04:17
davecheneythat will produce $PKG.test04:17
thumperhmm... don't really want anything created04:18
davecheneyit should be in $CWD04:19
davecheneyif it complets then your tests work fine04:19
davecheneythis is a way to check that your tests compile on other os's04:19
davecheneyGOOS=windows go test -c launchpad.net/juju-core/cmd/juju04:19
davecheneyeg04:19
davecheneythumper: oh, you donn't want it crated04:20
davecheneywe.... cd $(mktemp -d) && go test -c $PKG04:20
davecheney^ try that04:20
* thumper cocks his head04:20
* thumper sighs...04:37
thumperimport cycles04:37
* thumper beats the codebase into submission04:45
thumperok, trying to land again04:54
davecheneythumper: sorry, was on da phone05:46
davecheneyi may have another way to builkd, but not run tests ...05:46
davecheneyactaully ... no05:46
davecheneywhat i was thinking of didn't work at all05:46
davecheneybummer05:46
rogpeppethumper: i've got a script that builds all the tests but doesn't run them06:06
rogpeppethumper: but it uses some of my local stuff - you'd probably want to translate it into a shell you've got installed06:07
rogpeppethumper: http://paste.ubuntu.com/5803790/06:08
rogpeppethumper: i call it "gotest-c"06:08
rogpeppemornin' all, BTW06:09
jamdavecheney: you reviewed https://codereview.appspot.com/10465043/ but didn't LGTM. I don't quite understand what more you are asking for.06:12
jamthumper: 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
jamthumper: otherwise, why is the package level logger the wrong one?06:14
davecheneyjam: that is correct, i was confused about the whole passing back a *string06:20
jamdavecheney: well it works just fine. I suppose I could pass it back via a buffered channel if it makes you feel happier06:21
rogpeppedavecheney, thumper: here's a bash version of my "gotest-c" script: http://paste.ubuntu.com/5803813/06:28
rogpeppedavecheney, thumper: you'll have to go get code.google.com/p/rog-go/cmd/pxargs first though06:29
rogpeppedavecheney, thumper: then you can do "gotest-c ./..." build all tests without running them. i use it a lot06:29
=== thumper is now known as thumper-afk
thumper-afkrogpeppe: ta06:31
rogpeppethumper-afk: you might want to adjust the "5" constant, which should really be dependent on the number of cpus you've got06:32
rogpeppethumper-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/
jamrogpeppe: merge conflict on submitting your patch again. I got my patch landed which resolved some of the previous Resource changes.08:46
rogpeppejam: darn, ok thanks08:47
rogpeppejam: it had a transitory error when i landed it before (must fix those tests!)08:47
jamrogpeppe: yeah, I haven't seen that failure before, so I wasn't sure.08:47
* thumper afk until the meeting in 2 hours09:06
=== thumper is now known as thumper-afk
wallyworld_mgz_: ping09:13
rogpeppejam: re-approved. let's see if it lands this time.09:30
jtvProbably 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
jtvI 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
jtvBut the local provider's own tests can do the same thing and not have that problem.09:33
dimiternhttps://codereview.appspot.com/10617043/09:35
jtvdimitern: is that an answer for me or are you asking for a review?09:40
dimiternjtv: for review :)09:40
jtvAh  :(09:40
jtvTrade you?09:40
dimiternjtv: sorry wasn't paying attention - will read the backlog09:41
jtvThanks.09:41
dimiternjtv: so export_test makes package internals available to tests, but only inside the same package09: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
dimiternjtv: go magic :)09:42
* jtv screams at heavens09:42
dimiternjtv: anything with packagename_test is accessible in tests, including stuff in export_test09:43
dimiternjtv: if you need something from a tests package in more than one place, it's best to factor it out in a common testing package09:43
jtvDamn.09:43
dimiternwallyworld_: bug 119522309: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
jtvDeeper and deeper into the rabbit hole for a single job...  :(09:44
dimiternjtv: what do you need?09:44
jtvI need to invoke local.Listen, for purposes related to the local package, in my test.09:44
* rogpeppe goes for breakfast09:44
* dimitern looks at local.Listen09:45
dimiternjtv: and you need to invoke it where?09:46
jtvIn a test for the azure provider, where I use the local provider's storage implementation as a test double.09:46
dimiternjtv: that's probably a bad idea09:46
dimiternjtv: the local provider's storage is overengineered and probably needs to be simplified09:47
jtvOh great.  I was using the dummy provider's one, but fwereade preferred me to use the local provider's storage.09:47
dimiternjtv: if you just need a simple http server, why not create one and handle a specific url?09:47
rogpeppejtv: why not just export local.listen?09:47
jtvrogpeppe: 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
jtvdimitern: I do not want a simple http server!09:48
jtvI don't want any http at all.09:48
rogpeppejtv, dimitern: i think it's perfectly reasonable to have a working local storage provider from local that other things can use09:48
jtvI just need a test double for a storage object.09:48
dimiternjtv: yeah, that's another option - just export local.listen and NewStorage and get rid of export_test09:48
jtvThat'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
dimiternjtv: nah.. it only works inside the same package09:49
jtvWell it's exported from package "local" and imported into package "local_test"09:50
jtvAnd I do mean package, not source file.09:50
dimiternjtv: yeah, but the azure provider is in a different package, hence it's not visible, even if you import it09:51
jtvOh God don't tell me the rule is "exported exactly 1 package up, but no more"!09:51
dimiternrogpeppe: care for a review after breakfast? https://codereview.appspot.com/10617043/09:52
jtvdimitern: I was already looking at yours actually.  My end of the implied bargain.  :)09:52
dimiternjtv: sweet!09:52
fwereadejtv, dimitern: I suggested the local provider's storage because it's independent and it works09:58
fwereadejtv, dimitern: and if we make it simpler, then great09:58
dimiternfwereade: it has to be exported to work like that09:59
jtvNot in this branch though.  Gotta manage the scope of a branch or things will get waaaay out of hand.  :)09:59
fwereadedimitern, I'm fine exporting it somewhere -- tying storage implementations to providers is kinda dumb in the first place09:59
rogpeppejtv: i suggest that you change environs/local to export an interface like this: http://paste.ubuntu.com/5804251/10:00
rogpeppefwereade: does that seem reasonable to you?10:00
dimiternrogpeppe: +110:00
fwereaderogpeppe, looks sane10:00
rogpeppeactually, NewStorage should probably be func NewStorage(addr string) environs.Storage10:00
fwereaderogpeppe, better yet10:01
rogpeppeunless there were some fancy introspection methods we'd want to put on it10:01
rogpeppebut i can't think of any10:01
rogpeppejtv: the changes to environs/local to do that should be pretty trivial10:01
fwereaderogpeppe, it would still be best if it were actually outside local10:02
rogpeppefwereade: environs/localstorage ?10:02
fwereaderogpeppe, sounds reasonable10:02
rogpeppefilestorage?10:02
rogpeppelocalstorage.New(addr string) environs.Storage10:03
rogpeppeor Client10:03
fwereaderogpeppe, TrivialStorage :/10:03
rogpeppefwereade: nah - it's actually potentially useful and not *entirely* trivial10:04
fwereaderogpeppe, as you like :)10:04
rogpeppejtv, fwereade, dimitern: i think this is a bit better actually: http://paste.ubuntu.com/5804267/10:06
dimiternrogpeppe: sgtm10:07
jtvdimitern: done with your review10:13
* jtv catches up on backscroll10:13
dimiternjtv: thanks10:13
dimiternjtv: helpful comments, cheers10:16
jtvnp10:16
jtvDeal's a deal.  :)10:16
wallyworld_fwereade: you happy with https://codereview.appspot.com/10447045/ now?10:17
jtvrogpeppe, 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_: ping10:22
fwereadewallyworld_, helldamn I have drafts10:23
fwereadewallyworld_, let me see what I said, just a mo10:24
fwereadewallyworld_, sent; give it a quick read and let me know what you think10:25
wallyworld_fwereade: also, on introducing a new DeploymentValue constraint embedding Value - to make this viable, I'll need to introduce a new Constraints interface10:26
wallyworld_and use that throughout the codebase where feasible10:26
wallyworld_given Go lacks polymorphism and other useful inheritance constructs10:26
fwereadewallyworld_, I lean towards keeping it a single type until we've seen how the actual usage patterns end up10:27
wallyworld_fwereade: so this would mean adding checks to other places where container constraint is not valid10:27
wallyworld_besides add-machine10:28
fwereadewallyworld_, 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 constraints10:28
wallyworld_fwereade: i'd rather code defensively and fail if people try and pass in the wrong thing10:29
wallyworld_the system should fail if given invalid inputs10:29
wallyworld_as people might have certain expectations and winder why stuff didn;t behave as expected10:29
fwereadewallyworld_, 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 structure10:30
fwereadewallyworld_, if I knew for sure which parts handled what I'd be keener on splitting the type10:30
wallyworld_fwereade: right, that's indeed how i coded it10:30
fwereadewallyworld_, but I don't think we know enough to get it right there10:30
fwereadewallyworld_, sorry for all the hassles10:31
fwereades/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 memory10:31
wallyworld_will have to re-read the comments10:31
fwereadewallyworld_, yeah, I was a bit more paranoid than I think I needed to be -- sorry about that10:31
wallyworld_np10: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 one10:34
fwereadewallyworld_, I think it's very new10:35
wallyworld_fwereade: i'll try to get it done before bed, but if not first thing tomorrow10:35
dimiternfwereade: can we get rid of WatchPrincipalUnits and WatchSubordinateUnits now after I land this?10:36
dimiternfwereade: no one else is using them10:37
dimiternjtv: if you don't mind I'll do the loggo and if/else if/else changes in follow-ups10:41
dimiternfwereade: ping10:50
fwereadedimitern, pong, quickly, meeting in 10 :)10:50
dimiternfwereade: ^^10:50
fwereadedimitern, ah sorry missed that10:50
fwereadedimitern, hmm10:50
fwereadedimitern, let's not just yet10:50
dimiternfwereade: I mean in a follow-up10:50
dimiternfwereade: or you think it's useful to keep them for now?10:51
fwereadedimitern, yeah, I'm just not sure I want to drop them yet10:51
dimiternfwereade: ok then10:51
dimiternrogpeppe: so do we have API connection for all agents now?10:53
rogpeppedimitern: no, the unit agent doesn't have an API connection yet10:54
rogpeppedimitern: it needs the uniter facade first10:54
dimiternrogpeppe: but openState now opens an API connection in agent.go?10:54
jtvdimitern: fine with me!10:54
rogpeppedimitern: yes10:54
* jtv stalks off to get a stiff drink10:55
dimiternrogpeppe: my question is: once I implement the deployer facade, can I start replacing state calls for api calls and have a connection?10:55
rogpeppedimitern: yes10:55
dimiternrogpeppe: sweet!10:55
rogpeppedimitern: we also need the agent-alive mechanism in place10:57
dimiternrogpeppe: yeah, but not for the deployer at least10:58
rogpeppedimitern: the deployer isn't its own agent, is it?10:59
rogpeppedimitern: ah, it's just a worker alongside the machiner10:59
rogpeppedimitern: cool10:59
dimiternrogpeppe: no, but it has its own facade10:59
rogpeppedimitern: that sounds good10:59
rogpeppedimitern: when you do the deployer facade, please follow the example of apiserver/client10:59
dimiternrogpeppe: that at least haven't changed while i was gone, right? a facade per worker/agent11:00
dimiternrogpeppe: you mean with root replacement after login?11:00
rogpeppedimitern: i.e. a top level API type with a single method: Deployer(id string) (*Deployer, error)11:00
rogpeppedimitern: currently there's still only a single root type after login11:00
dimiternrogpeppe: ok, will follow it11:00
rogpeppedimitern: 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 present11:01
rogpeppedimitern: 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 necessary11:01
dimiternrogpeppe: i'd like to see that11:01
rogpeppedimitern: if that seems ok to you11:01
rogpeppedimitern: i'm knocking up a spike proof of concept11:02
dimiternrogpeppe: cool11:02
* dimitern waiting impatiently for tarmac (hopefully not to kick me in the teeth :)11:04
rogpeppejtv, fwereade, dimitern: https://codereview.appspot.com/10678043/ (only slightly less trivial than i thought)11:11
dimiternrogpeppe: on it11:11
* rogpeppe wants a "wait for tarmac" command that waits for a branch and prints tarmac's final judgement on it11:14
dimiternjuju wait-tarmac --retry-intermittent-failures ? :)11:15
* TheMue -> lunchtime11:16
dimitern\o/ Merged!11:17
dimiternrogpeppe: you've got a review11:18
rogpeppedimitern: ta!11:18
rogpeppeTheMue: i'd appreciate a review from you too, as it was your code originally, i believe:  https://codereview.appspot.com/10678043/11:20
dimiternso are we all now doing the standup/meeting now instead of kanban?11:26
rogpeppehmm, 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 $PATH11:29
jammgz_, dimitern, danilos, wallyworld_: i'm in the manager meeting, but we'll likely wrapup quickly11:33
wallyworld_rogpeppe: thumper's fault!11:34
rogpeppewallyworld_: yeah, but actually it's doubly broken. i have also broken it :-(11:34
rogpeppewallyworld_: am working on a fix for the other issue now11:35
wallyworld_the more the merrier :-)11:35
rogpeppewallyworld_: well, i'll incorporate a fix for apt-get lxc too11:35
wallyworld_\o/11:35
thumper-afkrogpeppe: eh?11:38
=== thumper-afk is now known as thumper
jamd11:38
jamdimitern: https://code.launchpad.net/~jameinel/goose/transfer-content-length-1124561/+merge/17097611:38
thumperrogpeppe: no, trunk is good11:38
rogpeppethumper: ah!11:38
thumperit landed11:38
rogpeppethumper: i've just realised why it happened11:38
rogpeppethumper: i upgraded11:38
rogpeppethumper: and upgrading just gets the binaries11:38
rogpeppethumper: it doesn't install new dependencies11:38
thumperrogpeppe: oh, and the machines don't have lxc11:38
rogpeppethumper: yeah11:38
thumperthat seems like it could be a problem11:38
thumperdo we have a plan for that?11:39
rogpeppethumper: not yet :)11:39
thumperok, and with that, I'm off11:39
rogpeppethumper: i think it could be quite simple though; we'll see11:39
* thumper nods11:39
thumpernight everyone11:39
* rogpeppe goes for some lunch and packing11:48
rogpeppei might be a couple of hours, but i will be back11:48
mattywfwereade, 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 core11:49
_mup_Bug #1191066: ssh command line help incorrect <bitesize> <cmdline> <juju-core:Triaged> <https://launchpad.net/bugs/1191066>11:49
TheMuerogpeppe: back from lunch, let me just propose my code (test is done) and then you'll get the review11:49
fwereademattyw, not that I'm aware of11:49
dimiternjtv, rogpeppe, fwereade: almost trivial https://codereview.appspot.com/1068104411:50
fwereademattyw, fwiw I am doing another pass through the bugs and have started to tag "easy" as well as "bitesize"11:50
mattywfwereade, ok cool, I'll keep any eye out for that11:50
fwereademattyw, where "bitesize" implies few lines of code to fix, and "easy" also implies that you shouldn't need to know too much arcane junk11:50
fwereadeto identify which lines11: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
fwereadewallyworld_, hmm, doesn't it short-circuit to checking the doc id? maybe I misremembered11:52
fwereadewallyworld_, I probably did11:53
wallyworld_fwereade: only for old machines, where the instance id should be set already11:53
jammramm: 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 doc11:53
mrammjam: that is fine with me11:54
fwereadewallyworld_, ok, and you always check for a doc first? cool11:54
wallyworld_fwereade: yes11:54
mrammor I can add one in quickly11:54
mrammwhatever is most efficient ;)11:54
mrammadded one to the invite in case we want it11:54
mrammI *think* we can go more quickly this week, and probably don't need an hour.11:55
jammramm: I'm on the hangount12:00
jamfwereade: care to join us for a fast API overview? https://plus.google.com/hangouts/_/91b92a337684b97321e7521463a14ec31840105212:02
mattywjust made my first attempt at fixing a small bug: https://codereview.appspot.com/10683043/12:13
jcastrohey guys, I'm trying to file bugs on the documentation, but they seem to show up on juju-core, not juju-core/docs12:59
jcastroI submitted via https://bugs.launchpad.net/juju-core/docs12:59
jamjcastro: there is no 'juju-core/docs' package, just a branch12:59
jamjcastro: if you want them to show up in that series... just a sec13:00
jamjcastro: can you link a bug?13:00
jamjcastro: I just did something here: https://bugs.launchpad.net/juju-core/+bug/119529313:01
_mup_Bug #1195293: Docs need workflow contribution examples <juju-core:New> <juju-core docs:New> <https://launchpad.net/bugs/1195293>13:01
jamyou can use the "Target to series" link undernead the bug tasks13:01
jamjcastro: I now see stuff in https://bugs.launchpad.net/juju-core/docs so hopefully its doing what you want13:06
jcastrook got it!13:06
=== BradCrittenden is now known as bac
jcastrojam: so there's no way for me to report doc bugs without spamming you guys?13:12
jamjcastro: 'juju-core/docs' is configured as a juju-core series, not as a separate project. So you have to target bugs to the series13:14
jcastroyeah so nick just landed new docs, so there might be a buncha little bugs coming in13:14
jamjcastro: 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 target13:15
* jcastro nods13:15
jamjcastro: 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 code13:16
jamArguably it should be called lp:juju-core-docs13:16
jcastrowe were inside of core before, and then we moved out, and now we're moving back in13:16
robbiewlol13:16
jamjcastro: we can live with what you have, but it doesn't fit the LP model.13:16
jcastronot my decision, and I don't even know why or how13:17
jamjcastro: as in there will be a juju-core/docs subdirectory with the website ?13:17
jamor just we are sharing the project name ?13:17
jcastrothe html docs are in there13:17
jcastroand they went live this morning, and I just wanted to fix a <pre> tag. :)13:18
jamjcastro: I mean, when I do "bzr branch lp:juju-core" today, I don't get docs13:18
jamis the intent that the html docs will share the same source tree as the code13:18
jam?13:18
jcastroI belive so13:19
jcastrolet me get evilnick for you.13:19
jamjcastro: if so, then it makes sense to have them in one project, and eventually lp:juju-core/docs will be merged into lp:juju-core13:19
jamIf they are intended to be developed "independently" then it would make more sense to have them as separate LP projects.13:19
* dimitern lunch13:19
jcastroI think the intent was together so like we can maintain docs for stable vs. trunk, etc.13:20
evilnickveitchjcastro, hey13:20
jamjcastro: well, you could do that anyway, though you'd have to take care to branch when we branch.13:20
jamwe could share the https://launchpad.net/juju-project13:20
jamas for ownership, bug visibilicty, etc.13:20
jamwe already have several projects there related to dependent code that we are also maintaining13:20
jcastroevilnickveitch: hey so jam thinks he can help organize this better13:21
jcastrobut all I wanted to do is drive by fix some docs with no other responsibilities. :)13:22
evilnickveitchjcastro :)13:22
evilnickveitchjam, so what's the plan?13:22
* jcastro slowly tiptoes away from the conversation13:22
jamevilnickveitch: 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
jamLP has the idea that everything underneath a given project shares the same source code and bugs13:24
jamSo having a "juju-core/docs" as a series (rather than a related-but-independent project) confuses things like bug triage13:24
evilnickveitchjam, uhuh. I was following the model from the previous juju + juju/docs model. but yes, I have noticed that13:24
evilnickveitchjam should we just have it as a standalone project then?13:25
jamevilnickveitch: that is how I would do it13:25
jamcalled juju-core-docs13:25
jamor juju-docs13:25
jamIt can be part of the 'juju-project' if we want to be clear about the affiliation13:25
jamand make it easy to share bug maintainers, etc.13:25
fwereadeevilnickveitch, fwiw, I just this morning tagged a couple of juju-core bugs as "doc" because I *think* they stem from inadequate communication13:26
jamBut otherwise, when people make a change to docs, it is going to show up as a branch against juju-core itself, etc.13:26
evilnickveitchfwereade, thanks!13:26
fwereadeevilnickveitch, there will surely be more :)13:26
evilnickveitchjam, yes, it is a bit confusing - I am not sure how it used to work with the old juju project.13:26
evilnickveitchjam, but it will be painful for me to trawl through bugs and target them to docs series all the time13:27
jamevilnickveitch: right, and if we really want a 'juju-core' bug to also be a 'juju-core-docs' bug, we can still target both projects13:28
evilnickveitchjam, sure. I think that will happen!13:28
jamevilnickveitch: 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
evilnickveitchjam, cool. I will sort it out13:30
=== BradCrittenden is now known as bac
benji__teknico: I'll take it13:31
benji__pfft; wrong channel13:31
=== benji__ is now known as benji
=== benji is now known as Guest32120
evilnickveitchjam, although, another option might be to host the docs with the juju-core code.13:40
jamevilnickveitch: I could live with either, but I think either would be better than what we have today.13:42
evilnickveitchjam, okay, will discuss with arosales et al.13:43
jamevilnickveitch: 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
evilnickveitchjam, 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
evilnickveitchit 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
fwereadejam, 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 *Tools13:50
fwereadejam, we can still pass series/arch in for smarter watching in future13: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 usage14:01
=== wedgwood_away is now known as wedgwood
fwereadewallyworld_, will do14:02
ackkhi, is there a way to get the environment UUID through the juju-core API?14:04
fwereadeackk, ...apparently not? this is slightly surprising, but maybe the GUI hasn't wanted to use it yet14:15
fwereadeackk, that's been the primary driver for the public API14:15
ackkfwereade, right. It'd be nice to have it in the EnvironmentInfo, though14:16
fwereadeackk, yeah, agreed, that should be a nice easy fix and it should kinda obviously be there14:17
ackkfwereade, I just opened a bug for it, FIY: #119534414:20
dimiternackk: if you type "bug 1195344" _mup_ will print a link to it14:25
_mup_Bug #1195344: Add the environment UUID to EnvironmentInfo response <juju-core:New> <https://launchpad.net/bugs/1195344>14:25
ackkdimitern, thanks14:26
fwereadeackk, tyvm14:27
TheMuedimitern: thx for review14:34
dimiternTheMue: yw14:34
TheMuedimitern: will add a comment, assert is just to ensure, that at least two runs have been done so that times could be compared14:35
dimiternTheMue: my comment was not specifically for the assert, but for the for loop mostly14:35
dimiternTheMue: thanks14:35
TheMuedimitern: ah, ic14:39
TheMuedimitern: ok, will find some words. it's based on a discussion we had during kanban ;)14:39
dimiternTheMue: 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
mrammcan somebody join the cross-team juju call?14:45
mrammfwereade: ^^^14:45
=== tasdomas is now known as tasdomas_afk
mattywdimitern, 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
dimiternmattyw: you can pass -bug="" in lbox or just link it in LP15:20
mattywdimitern, ok thanks15:23
dimiternTheMue: can you take a look at this mostly trivial CL? https://codereview.appspot.com/10681044/15:32
TheMuedimitern: sure15:33
fwereade_mramm, hell, sorry, I was having a very late lunch15:33
dimiternTheMue: thanks15:33
TheMuedimitern: you've got a +115:35
dimiternTheMue: cheers15:36
rogpeppefwereade_: ping17:43
rogpeppefwereade_: ping18:57
wallyworld_fwereade_: you around?20:47
thumpermorning21: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 constraints22:38
wallyworld_fwereade_: hi, was just pinging you to hopefully +1 that instance metadata branch22: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 better22:40
wallyworld_fwereade_: ok, so i can introduce a new value22:40
fwereade_wallyworld_, I'll take a look sorry about that22:40
wallyworld_none sounds good22: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
thumperok22: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 etc23:08
fwereade_wallyworld_, reviewed23:15
* fwereade_ bed23:15
wallyworld_fwereade_: thanks23:22
=== wedgwood is now known as wedgwood_away

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!