=== wedgwoodz is now known as wedgwood_away
=== bigjools_ is now known as bigjools
davecheneycan anyone else bootstrap and deploy atm ?06:29
davecheneyI think rev 1078 broke everything06:29
rogpeppemornin' all07:04
rogpeppedavecheney: i'll give it a try07:05
fwereade__rogpeppe, I cannot repro that07:23
fwereade__rogpeppe, any luck?07:23
rogpeppefwereade__: live tests work ok; i just did a bootstrap and deploy, then realised i hadn't done upload-tools...07:23
fwereade__rogpeppe, I did do upload-tools and it seems to work ok07:24
rogpeppefwereade__: trying again07:24
rogpeppefwereade__: good07:24
rogpeppefwereade__: have a good weekend? i see a lot of CLs!07:24
fwereade__rogpeppe, cath + laura were away for a bit :)07:25
fwereade__rogpeppe, only really a day, but a day is quite a long time when you can just drop the concept of interruptions from your mind07:25
rogpeppefwereade__: i was looking at jam's sync-tools branch and am unsure about the "noisy by default" approach. this represents a change of direction AFAICS and i'm not convinced it's the right one.07:32
rogpeppefwereade__: i'd be happier if those messages were printed given a -v flag.07:33
fwereade__rogpeppe, hmm, maybe07:35
jamrogpeppe: Consider it an exploration into, "juju doesn't sit there telling me nothing for 2 minutes"07:35
jamI know whenever I use juju I have to run "--debug" because otherwise it just appears to hang.07:35
jamI'd like to find a middle ground07:35
jambut notifying on something that takes more than 10s seems like a good thing to me.07:36
fwereade__rogpeppe, my perspective was that the only reason we didn't provide feedback was because we didn't have a good way to do so, and we've all ended up sliding into the always run --debug trap07:36
rogpeppejam: me too, but i think that's ok. i want these commands to work well in a script without needing to add --quiet flags all over the place07:36
rogpeppefwereade__: i think --debug is too much07:36
jamrogpeppe: I would guess 'juju' is more of a user binary than a script one, so we should bias towards that.07:36
rogpeppefwereade__: but -v should be just right07:36
fwereade__rogpeppe, agreed, I think it's awful07:36
rogpeppejam: i think that's the way we're using it now, but i don't see that as its role in the future necessarily07:37
fwereade__rogpeppe, IMO the somewhat forbidding user experience is a Really Bad Thing and anything that works against that is good07:38
jamrogpeppe: so I feel your argument is a bit in the "hypothetical use case". If it is a concrete one, then we can design around it. But I'd really like to make sure we are getting feedback from people performing that use case.07:38
rogpeppefwereade__: i don't think the unix tradition is a Really Bad Thing07:38
jamBecause we already have feedback from the rest of us (non-scriptors)07:38
jamthat want more feedback07:38
rogpeppejam: i'd like to make -v work well07:38
rogpeppejam: and keep commands quiet by default07:39
jamrogpeppe: I would argue that things that get written into a script can do '-q' more easily than users can do '-v'07:39
rogpeppejam: oh please no. i really don't want us to have a -q flag07:39
rogpeppejam: next we'll be printing vt100 escape sequences07:40
jamrogpeppe: other than the verbosity being too high, telling users "always supply -v to get feedback" isn't really a good user experience, either.07:40
fwereade__rogpeppe, the impact is that *users* don't like it; I personally enjoy this job and would like to keep doing it, and juju being able to attract and retain users is one of the necessary conditions for that to happen long-term07:40
fwereade__rogpeppe, what is your objection to "-q"?07:40
rogpeppefwereade__: in general users follow the instructions they're given, which will probably have a -v flag07:41
fwereade__rogpeppe, I bet there's a corollary to that stephen hawking thing... even command-line flag you make your users type halves your user base07:41
rogpeppefwereade__: it's just one more piece of complexity. we are already (probably) going to have --verbose, --debug, --info, --error and maybe more logging related options07:42
fwereade__rogpeppe, whoa, why would we have those things?07:42
fwereade__rogpeppe, log-level maybe07:42
rogpeppefwereade__: we want to be able to set the level of debugging at run time, no?07:42
rogpeppefwereade__: ok, so --verbose, --debug, --log-level and now --quiet too07:43
fwereade__rogpeppe, well, honestly, --debug and --verbose *are* plainly nonsense07:44
rogpeppefwereade__: i think we should have --verbose and --log-level only probably07:44
rogpeppefwereade__: with maybe --debug grandfathered in07:44
fwereade__rogpeppe, I don;t think that the fact that we have a shitty solution in place is a good argument against making parts of it useful07:44
rogpeppefwereade__: i think that having commands silent by default and chatty when you ask them to be is a good thing.07:45
fwereade__rogpeppe, and our users don't07:45
rogpeppefwereade__: we don't need to tell the user every time we make an RPC07:45
fwereade__rogpeppe, I don;t think I was suggesting we should07:45
rogpeppefwereade__: from the CL "Mostly because those are the bits that sit waiting on RPC"07:46
rogpeppefwereade__: at the least we should have a public discussion about this07:47
fwereade__rogpeppe, it seemed to me that there has been unanimous agreement both at the sprint and among users that our lack of CLI feedback is shit07:48
fwereade__rogpeppe, my user knowledge is, I freely admit, second-hand07:48
fwereade__rogpeppe, there was not necessarily agreement about what the final answer should look like07:49
fwereade__rogpeppe, but I didn't hear anyone claiming that it would be bad to give users a bit of feedback not forced through the log package07:50
rogpeppefwereade__: i think we can give good CLI feedback, but keep things quiet by default. that's the approach we have deliberately taken so far (although our verbose mode is indeed shit) and i think we should have a discussion about it rather than doing it ad hoc in a random CL07:50
rogpeppefwereade__: i agree; i don't think --verbose should affect the log level07:50
fwereade__rogpeppe, ok, I didn't actually think that approach was deliberate at all07:51
rogpeppefwereade__: although... given that we've got lots of log levels now, perhaps --verbose should be equivalent to --log-level info07:51
fwereade__rogpeppe, maybe... I am still trying to figure out whether user output and logging are the same thing or not07:52
rogpeppefwereade__: i agree. i'm not entirely sure either.07:52
fwereade__rogpeppe, I *think* they probably actually are -- but I'm pretty sure the user output doesn't need all that timestamping, badging, etc07:53
rogpeppefwereade__: perhaps we should take all the badging off when printing to std(out? err?)07:54
fwereade__rogpeppe, if we had something that logged to stderr with --quiet: nothing, nothing: notice-and-above, --verbose: info-and-above, etc07:54
fwereade__rogpeppe, yeah07:54
rogpeppefwereade__: that sounds ok to me actualy07:55
rogpeppefwereade__: a notice wants to be seen07:55
fwereade__rogpeppe, yeah07:55
rogpeppefwereade__: the question becomes then: what justifies a notice?07:56
jamrogpeppe: so one small thing, is that '-v' and all the Log values aren't shown by "juju help status". I haven't quite figured out when they are shown to the user07:56
fwereade__jam, they're shown on plain juju help iirc07:57
jamfwereade__: that tells you to init bootstrap etc07:57
jamno flag help07:57
rogpeppejam: juju help global-options07:57
fwereade__jam, tim didn't like polluting all the individual command helps with global flags07:57
rogpeppejam: i argued against the approach of leaving out global flags from individual commands but failed to convince07:58
jamrogpeppe, fwereade__: so if a user does "juju help" then "juju help topics" then "juju help global-options" he can then see them07:58
rogpeppejam: yeah :-|07:58
jamIOW, they will never see them07:58
rogpeppejam: yeah07:58
jamexcept for someone that has a perversity for reading docs07:58
jamor is really struggling with something so goes to each help topic they can find07:59
rogpeppejam: i agree07:59
jam anyway, the help for it says "log additional messages"07:59
jamwhich certainly doesn't sound like give me more feedback.07:59
rogpeppejam: and i don't think we have enough flags to justify the "cleanliness" argument07:59
=== racedo` is now known as racedo
jamrogpeppe: or at least, we should link from "juju help foo" "Additional flags are in: juju help global-options"07:59
fwereade__jam, rogpeppe: all the more important, I think, to provide a more sensible level of output by default08:00
fwereade__rogpeppe, do you know what the situation is wrt multiple log targets with different badging behaviour?08:00
jamfwereade__: so I've obviously made clear why my thoughts are on that, but I think rogpeppe has a fair point that we can have it as a discussion first.08:00
jamhaving it in Log certainly made it undiscoverable08:00
jamboth to users, and to me as a dev.08:00
fwereade__jam, +108:01
jamI'm still not sure how I get access to that flag (ctx.?)08:01
fwereade__jam, you shouldn't need it08:01
fwereade__jam, as a suggestion08:01
rogpeppefwereade__: i suspect you can only have one level of log line taggin08:01
fwereade__jam, maybe land that with the stderr logging going to Notice, and propose something smarter on the lists?08:01
fwereade__jam, cmd/logging.go or something like that08:02
jamfwereade__: so "-v" appears to just add stderr as a place to write log messages08:02
rogpeppefwereade__: can we have multiple log targets currently?08:02
jamNote that by default, we don't have a log file nor an output to the user08:02
jamso by default all messages are dropped into the nether08:03
fwereade__jam, yeah, I know, and I agree that is bad08:03
rogpeppejam: i think that's ok, but you know that :-)08:04
rogpeppejam: well, except that i think the default log level should be Notice08:04
rogpeppejam: (whatever that implies)08:04
fwereade__rogpeppe, I think the choice of level for particular messages is something that we'll iterate on forever08:05
rogpeppefwereade__: it would be nice to have a guideline though. is a notice an expected event or not, for example?08:05
fwereade__rogpeppe, yes, I think so08:06
rogpeppefwereade__, jam: ok, so as a straw man here are the messages from the CL with some possible debug levels against them: http://paste.ubuntu.com/5669776/08:07
fwereade__rogpeppe, that looks pretty good to me08:08
jamrogpeppe: so the one thing with my patch that we miss going to log, is that it gives incremental messages about copying tools.08:08
jamIt doesn't know how big the thing is until it has downloaded it08:08
jambecause Get() doesn't expose the size08:08
jamI can certainly use multiple lines for it08:08
jambut it was sort of nice to have it all on one line08:09
fwereade__jam, I have a thought there actually08:09
fwereade__jam, we have a couple of places already where we need to download things preferably-just-once, and check hashes, and suchlike08:10
rogpeppeList could provide some metadata08:10
fwereade__jam, it *might* be worth checking for commonalities there08:10
jamrogpeppe: I imagine Get() might have a Content-Length header as well.08:11
jamBut it isn't exposed yet.08:11
jamI had originally thought to just Put(Get)08:11
jamsort of thing08:11
jamrather than buffering anything08:11
jambut Put() requires knowing the content-length08:11
rogpeppejam: unfortunately goamz/s3 throws away the info08:13
rogpeppeafk for 5 mins08:13
fwereade__afk myslf for a bit, sorry08:43
jamrogpeppe: yeah, goamz/s3 also doesn't let you Get anonymously :(08:43
jamBut I already filed that bug.08:43
fwereade__jam, I responded to some of your review points, still thinking about others08:43
fwereade__jam, in https://codereview.appspot.com/818304408:43
jamfwereade__: I think I've addressed all your comments in https://codereview.appspot.com/8051043/ aside from what to do about user feedback.08:48
rogpeppefwereade__: ping08:59
dimiternanybody else having issues with trunk after rev 1089?10:18
dimiternit seems cmd/builddb/main.go no longer compiles, because it imports "state" and is not using it10:19
rogpeppedimitern: i see that. if you want to propose a trivial fix, that would be great!10:19
dimiternrogpeppe: well, I will but this shouldn't happen - somebody didn't run the tests before committing10:20
rogpeppedimitern: agreed. you're welcome to ascribe blame if you want.10:20
mgzthere's a thread on the list about that10:21
dimiternrogpeppe: I think it's gary_poster's branch10:21
rogpeppedimitern: that makes sense. it was a large change.10:21
dimiternand dfc committed after that also without running the tests10:22
dimiternI always do go build ./... && go test ./... in juju-core, that's how I caught it10:22
dimiternmgz, jam: standup?10:29
mgzI'm there10:34
dimiternI just left :) let me rejoin10:34
dimiternthere it is - it's a trivial one-line change to fix trunk: https://codereview.appspot.com/825304310:46
rogpeppefwereade__, jam: FWIW i also support using a temp file for the tools. but maybe the odd 10MB is not anything to care about these days...10:55
dimiternrogpeppe: do you have an idea why UnitStatus consts moved from state to state/api/params?10:58
rogpeppedimitern: because they're visible in the API10:58
dimiternrogpeppe: but in state they're not?10:59
rogpeppedimitern: they're visible in both state and state/api10:59
dimiternrogpeppe: I added state/status.go to manage unified unit and machine status10:59
rogpeppedimitern: and state/api can't import state10:59
dimiternrogpeppe: so I should add state/api/params/status.go just for the constants11:00
rogpeppedimitern: i *think* so. state/api/params gives me discomfort but i haven't figured out a better solution yet (other than duplicating all the types)11:01
rogpeppedimitern: i'm not entirely sure that the recent changes were necessary though11:02
dimiternrogpeppe: ok, so can have operations in state/status.go and status consts in state/api/params/status.go - sound sane?11:02
rogpeppedimitern: that sounds reasonable. actually, you could probably have the status consts in state/status.go too. i can't currently think of a compelling reason why not.11:03
rogpeppedimitern: except... then they can't be seen by state/api Go clients.11:03
dimiternrogpeppe: well, having status related stuff in 2 modules seems wrong, but as a compromise for the api clients I suppose it's ok11:04
rogpeppedimitern: what operations are you adding?11:04
dimiternrogpeppe: getStatus and setStatusOp11:05
rogpeppedimitern: they seem like very state-oriented operations tbh11:05
dimiternrogpeppe: they are11:06
dimiternrogpeppe: that's why they'll remain in state/, while the consts will be in params11:07
rogpeppedimitern: BTW, i think that when the agents all move to talking via the API, we should be able to merge state/api/params into state/api11:07
rogpeppedimitern: cool. i thought you were bothered by that.11:07
dimiternrogpeppe: not especially, fixing merge conflicts now :)11:08
rogpeppedimitern: so unit status is going into its own collection?11:09
dimiternrogpeppe: yes, along with the (new) machine status11:10
rogpeppedimitern: the transaction lists get longer and longer :-)11:12
dimiternrogpeppe: but the code arguably better :)11:12
dimiternrogpeppe: is state/api/params UnitInfo supposed to be almost exactly as state/unit unitDoc? I'm removing 2 fields from there: Status and StatusInfo, now in a separate statuses collection.11:21
dimiternrogpeppe: and megawatcher tests fail11:21
rogpeppedimitern: it is, yes11:22
rogpeppedimitern: as the comment says, it's a subset11:22
dimiternrogpeppe: so I should remove these 2 fields from UnitInfo as well11:22
rogpeppedimitern: this is part of the problem with making new collections - i assumed that all the information for a unit was to be found in the unitDoc11:22
rogpeppedimitern: i guess so. i will need to make the allWatcher indirect (something i thought i could put off until after 13.04)11:23
dimiternrogpeppe: not anymore, for statuses at least11:23
rogpeppedimitern: yeah, i see that11:23
jammgz,dimitern: So I'm still late, but my calendar has the standup ~25min ago, not 1hr 25min ago. I was keeping it the same UTC time (which makes it 1 hour later for you guys). Do you prefer to move it earlier?11:54
jamWe can certainly do whenever while wallyworld is on vacation for 2 weeks.11:54
mgzyeah, the timezone switch make life funner11:55
dimiternrogpeppe: PTAL https://codereview.appspot.com/8256043/ - the stuff around the API especially12:15
rogpeppedimitern: looking12:17
dimiternalso other reviewers are welcome :)12:17
gary_posterdimitern, rogpeppe sorry, I definitely did run tests, but I must have done something insufficiently, obviously12:17
rogpeppegary_poster: i know what the problem was12:17
gary_posterwhat was it?12:17
dimiterngary_poster: np, it happens, but did you run go build ./... && go test ./... in the juju-core dir?12:17
rogpeppegary_poster: go test ./... does not *build* everything. if there's a package with no tests (which builddb is) it will just  be ignored12:18
rogpeppegary_poster: personally i think that's a bug12:18
rogpeppegary_poster: but it's the case12:18
gary_posterrogpeppe, dimitern that's it: I ran go test ./... but not go build ./... .  I did not know if that requirement12:18
dimiternrogpeppe: and I really'd like the equivalent of go build for tests..12:18
rogpeppegary_poster: it's not your fault - i've been bitten by that before12:18
gary_posterVery good to know, thanks for fixing, and sorry for the problem12:19
rogpeppedimitern: http://paste.ubuntu.com/5670234/ (i call it "gotest-c")12:19
rogpeppedimitern: i pushed quite hard for go test -c ./... to work, but failed i'm afraid12:19
dimiternrogpeppe: ah, cool tool12:19
dimiternrogpeppe: hmm.. what was the cited reason not to do it?12:20
gary_posteractually it wasn't even my branch12:20
rogpeppedimitern: too close to go1.112:20
gary_posterI will go spread the news on juju-gui12:20
gary_postercould have been my branch :-)12:20
dimiterngary_poster: oh, sorry then - but you see, you could've caught it with go build before go test ;)12:21
gary_posterdimitern, definitely!  and it was a juju-gui branch, so we should all know about this12:21
dimiterngary_poster: cheers12:22
dimiternfwereade__: ping12:35
fwereade__dimitern, pong12:36
dimiternfwereade__: hey, wanna take a look at machine status CL? https://codereview.appspot.com/8256043/12:36
fwereade__dimitern, ack12:36
jamrogpeppe: btw, your reply seems to have gone directly to me, rather than juju-dev list13:01
rogpeppejam: oh, thanks!13:01
davecheneylads, the build really is broken, http://paste.ubuntu.com/5670353/13:08
dimiterndavecheney: so my fix was for unrelated issue13:09
jamdavecheney: What is confusing is that "state entity name" doesn't exist in the source tree. "not fonud in configuration" is present, but with %s and the only bit passes "state entity tag".13:10
davecheneyjam: lucky(~/src/launchpad.net/juju-core) % bzr st .13:10
davecheneymodified: version/version.go13:10
davecheneyit's not my tree13:10
davecheneyoh, and 1077 isn't that reliable a build either,13:11
jamdavecheney: so with 1091 bootstrap works and brings an instance up, but deploying fails to bring up the unit agent, is that correct/13:12
davecheneyjam: that is correc13:12
jamI'm wondering if the cloudinit on unit agents is accidentaly downloading published tools, rather than --upload-tools13:12
davecheneythis is machine 113:12
jamso it is reverting to 1.9.12 on the non-bootstrap nodes13:12
davecheney2013-04-02 13:06:11 URL:https://s3.amazonaws.com/juju-dist/tools/juju-1.9.12-precise-amd64.tgz?AWSAccessKeyId=AKIAJ4SOKUWG25EDMAOA&Expires=1680440598&Signature=mL1lQJZkuqtjagofN0jbm%2F3hUz4%3D [2142668/2142668] -> "-" [1]13:12
jamdavecheney: can you ssh in and check 'jujud --version' ?13:12
davecheney^ indeed they are13:12
davecheneyjam: good guess13:12
jamdavecheney: at least it make sense, even if it is still broken :)13:13
davecheneyso, it's been broken for how long then ?13:13
davecheneysince last friday ?13:13
jamdavecheney: my guess is downloading the wrong tools has been true for a while13:13
jambut we have'nt broken compatibility in a while13:13
davecheneythat could explain why I can't get the fscker to work at _all_ in hp cloud13:14
rogpeppedavecheney: yes, if you're trying to deploy a precise charm from quantal, the tools logic will fall back to the tools in the public bucket13:16
rogpeppedavecheney: i believe there are plans to change this, but that's how it is currently13:16
rogpeppedavecheney: (i suggested that the error would be more obvious if we actually changed the major version, but nobody else thinks that's a good idea)13:17
davecheneyrogpeppe: oh indeed13:17
davecheneyyou are right13:17
davecheneyso the tools are following the series of the charm ...13:17
davecheneywhich means --upload-tools is useless13:18
rogpeppedavecheney: yes, they have to13:18
davecheneyrogpeppe: i agree they have too, but they never used too13:18
davecheneysee prevoius point about --upload-tools being useless13:18
rogpeppedavecheney: it means that if you want upload-tools to work you have to deploy a charm with the same series as your current machine13:18
jamdavecheney: you do the builds, is the -quantal tool any different from the -precise one? Or is it just changing the name of the tarball? (Maybe you have lp do the actual build, I guess)13:18
rogpeppedavecheney: which actually makes some kind of sense13:18
rogpeppejam: i suspect there's no actually difference at all.13:19
davecheneyjam: the Q tools are built by a Q bot13:19
davecheneybut in practice, it makes no difference13:19
davecheneyrogpeppe: i know it makes sense13:20
TheMuefwereade__: ping13:20
davecheneyit's just impossible to make work13:20
davecheneyie, this cross series lunacy13:20
fwereade__TheMue, pong13:20
davecheneyi have deployed a quantal bootstrap node13:20
davecheneythen I got to deploy a precise mysql node becuase there is no cs:quantal/mysql charm13:20
davecheneyand --upload-tools fails me13:20
davecheneyto be clear13:20
TheMuefwereade__: we still have a decision open regarding the environ config.13:20
davecheneyi understand why it does what it does13:21
rogpeppedavecheney: download the precise mysql charm and rename it to quantal13:21
davecheneyrogpeppe: sure, but I lost the argument about cross series enviroments being a bad thin13:21
TheMuefwereade__: shall i refactor it to an own document with its own collection or stay with the attrs and add uuid?13:21
davecheneyand now I'm having a sook about a place where it has blown up on me in testing13:21
rogpeppedavecheney: it wouldn't be such a problem if the error message was more clear13:21
fwereade__TheMue, add a new document please13:21
davecheneyrogpeppe: true, that would at least let me understand what went wrong13:22
rogpeppedavecheney: exactly. you are by no means the first person to have been bitten by this hard-to-diagnose issue13:22
fwereade__TheMue, there is already a stte.Environment entity, you just need to back it with a doc13:23
davecheneyrogpeppe: without twisting the knife13:23
davecheneythis is exactly the kind of nonsnse that will haunt us too our graves with cross series environments13:23
rogpeppedavecheney: only if we make backwardly incompatible changes without changing the major version number13:24
TheMuefwereade__: ok, will do.13:24
fwereade__rogpeppe, davecheney: I am strongly tempted to bump the FindTools changes up out of the backlog... I think they will make the problem much clearer13:25
rogpeppedavecheney: i *think* that we're seeing this a lot only because we are not doing that. in normal juju use, no-one will use --upload-tools, and if they do, they'll be compatible *or* the major version number will have changed, and in both those cases you won't have this issue.13:25
davecheneynow when i use --upload-tools it doens't respect default-series13:27
fwereade__rogpeppe, davecheney: another thought: if the series really doesn't matter at the moment, why not just hack --upload-tools to fake up quantal,precise,raring copies of the same tarball and upload them all for the appropriate arch?13:27
davecheneyfwereade__: yeah, that might have to be the solution for the moment13:27
davecheneystill doesn't solve my second outburst13:27
fwereade__davecheney, you can always override default-series, unless I'm very confused13:28
davecheney  ap-southeast-1:13:28
davecheney    type: ec213:29
davecheney    default-series: precise13:29
davecheney    region: ap-southeast-113:29
davecheneylucky(~) % ssh ec2-46-137-197-55.ap-southeast-1.compute.amazonaws.com -l ubuntu -- lsb_release -a13:29
fwereade__davecheney, --upload-tools overwrites it, on the basis that if you're uploading tools you want to run them13:29
davecheneyNo LSB modules are available.13:29
davecheneyDistributor ID: Ubuntu13:29
davecheneyDescription:    Ubuntu 12.1013:29
davecheneyRelease:        12.1013:29
davecheneyCodename:       quantal13:29
davecheneyfwereade__: fuck, so now i'm stuck in the position that I cannot test precise charms without a precise host to run juju cli13:29
fwereade__davecheney, but that behaviour would surely be dropped if we uploaded multiple tools13:30
davecheneyfwereade__: hmmm, i don't see how13:30
davecheneyFindBestTools won't consider tools outside the series13:31
fwereade__davecheney, right, but we'd be starting precise machines just fine if we were asking for them13:31
davecheneyfwereade__: so tim and I cannot do that13:32
davecheneyi have a quantal machine, he has raring13:32
fwereade__davecheney, surely if you do explicitly `deploy precise/wordpress` you'll get a precise machine... it just might not have compatible tools13:32
davecheneyfwereade__: yup, that works, and leads to the original problem13:32
davecheneyi guess then if we upload multiple tools13:32
davecheneythen that is a solid workaround13:32
fwereade__davecheney, I think upload-multiple-tools + look-in-one-bucket-only together should make things properly clear13:33
fwereade__davecheney, the other related issue is that the environments are not sophisticated in how they handle tools at all... I think they still pick them at the wrong time anyway13:34
=== wedgwood_away is now known as wedgwood
davecheneyfairy nuf13:35
davecheneyit's late here13:35
davecheneyi'll catch you on the flip side13:35
dimiternrogpeppe: did you manage to review it?13:35
=== wedgwood is now known as Guest6347
rogpeppedimitern: in a call13:36
mrammI'll be out for the day -- but am just doing some home maintenance stuff so I'll be around if needed13:36
mrammI'll try to be at the kanban meeting in 20 min though!13:37
fwereade__mramm, cool13:37
rogpeppefwereade__: +113:59
fwereade__rogpeppe, cheers13:59
rogpeppefwereade__: --fake-tools raring,quantal13:59
rogpeppefwereade__: perhaps13:59
fwereade__rogpeppe, perfect, saves us hardcoding them14:00
fwereade__rogpeppe, other possibility is to get the available series' from the environment, by looking at the available images, but that's not something to do now14:00
jamcould we instead just have FindTools understand an "-any-" series?14:06
=== marco is now known as Guest28583
dimiternfwereade__: how's going?14:27
* rogpeppe gets a bite to eat14:34
=== Guest28583 is now known as marcoceppi
dimiternI still need review of https://codereview.appspot.com/8256043/14:50
dimiternrogpeppe, fwereade__ ^^14:54
fwereade__dimitern, hey, sorry, I was writing one in some detail and got caught up by the meeting15:05
dimiternfwereade__: no worries15:05
dimiternTheMue: thanks for the review!15:13
gary_posterfwereade__, hi.  I have a question about relation errors.  Are they going to be exposed as part of unit status, or somewhere else?15:24
fwereade__gary_poster, at the moment there are no relation errors: any relation error puts the whole unit in an error state15:25
gary_posterfwereade__, and will that be the case for 13.04? (great by me if so)15:25
gary_poster(simply as a matter of integration)15:25
fwereade__gary_poster, I was not wholly in favour of this change when we made it, so it might come back one day, but definitely not by 13.04 :)15:25
gary_posterfwereade__, cool, sounds good. :-) thanks!15:26
gary_posterrogpeppe, fwiw, ^^^ that's off our plate for the time being at least15:27
rogpeppegary_poster: cool15:27
rogpeppedimitern: you have a review15:29
fwereade__dimitern, and another15:33
dimiternrogpeppe, fwereade__: cheers guys15:34
dimiternfwereade__: about juju status discarding errors - it was like that before I changed the unit status not to return error15:37
dimiternfwereade__: how are we supposed to report such errors?15:37
fwereade__dimitern, that doesn't make me any happier to change it back ;p15:37
fwereade__dimitern, there seems to be a checkError() pattern in use in there15:37
fwereade__where things we can't get are represented as a {"status-error": "something happened, oh noes"}15:38
jammgz: all the juju patches, should we be reviewing or is that more a kapil thing?15:59
mgzit's mostly an auditing thing16:00
mgzthe fun part is in the packaging branches anyway really16:01
jamit looks like most of them are already landed16:01
mgzparticular because of bug 98528516:01
_mup_Bug #985285: juju packaging branch fails using merge-upstream from tarball and upstream branch <Ubuntu Distributed Development:New> < https://launchpad.net/bugs/985285 >16:01
jamweird that I get the mp, but not the "merged" emails16:01
mgzis there someway I can get bzr to give me a diff ignoring file-id changes?16:02
mgzoddly --take-other is deleting files that don't get included as part of other... builddeb is struggling for sanity here16:02
jammgz: so why the backports to 0.5?16:41
jamvs just releasing the 0.6/7/whatever?16:41
mgzthey were just in the list for a release16:41
mgzit doesn't hurt and was easy, at least compared to battling builddeb16:41
mgzthe fact the packing branches are completly screwed is more troublesome16:42
rogpeppefwereade__: ping16:49
rogpeppefwereade__, dimitern: fairly trivial: https://codereview.appspot.com/826604317:09
dimiternrogpeppe: reviewed17:21
rogpeppedimitern: ta!17:21
TheMuerogpeppe: and another review17:25
rogpeppeTheMue: thanks17:25
=== deryck is now known as deryck[lunch]
* rogpeppe reaches end of day17:38
rogpeppehere's another CL to review, if anyone fancies it. it's on the critical path for the GUI so reviews appreciated. https://codereview.appspot.com/8269043/17:39
benjirogpeppe: I bet you are about EOD, but I have a review up if you have a minute: https://codereview.appspot.com/827104318:05
rogpeppebenji: no cycles then?18:27
benjirogpeppe: nope; they were only in my head18:28
rogpeppebenji: i really have finished already. but one thing: in params_test.go i'd add some Endpoint info, just so we can see what it'll look like when serialized18:34
=== deryck[lunch] is now known as deryck
benjirogpeppe: thanks for the suggestion, I'll do so18:41
* thumper head desks20:47
thumperfwereade__: ping?21:12
thumperbenji: you are good to merge21:50
benjithumper: thanks!21:50
thumperfwereade__: if you come and look later, I'm pretty sure I know what the issue is with tools and bootstrap...21:52
* thumper may be to blame there...21:52
* thumper goes to make a coffee21:52
* thumper waits for dave23:13
=== Guest6347 is now known as wedgwood_away

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