| === wedgwoodz is now known as wedgwood_away | ||
| === bigjools_ is now known as bigjools | ||
| davecheney | can anyone else bootstrap and deploy atm ? | 06:29 |
|---|---|---|
| davecheney | I think rev 1078 broke everything | 06:29 |
| rogpeppe | mornin' all | 07:04 |
| rogpeppe | davecheney: i'll give it a try | 07:05 |
| fwereade__ | rogpeppe, I cannot repro that | 07:23 |
| fwereade__ | rogpeppe, any luck? | 07:23 |
| rogpeppe | fwereade__: 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 ok | 07:24 |
| rogpeppe | fwereade__: trying again | 07:24 |
| rogpeppe | fwereade__: good | 07:24 |
| rogpeppe | fwereade__: 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 mind | 07:25 |
| rogpeppe | fwereade__: 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 |
| rogpeppe | fwereade__: i'd be happier if those messages were printed given a -v flag. | 07:33 |
| fwereade__ | rogpeppe, hmm, maybe | 07:35 |
| jam | rogpeppe: Consider it an exploration into, "juju doesn't sit there telling me nothing for 2 minutes" | 07:35 |
| jam | I know whenever I use juju I have to run "--debug" because otherwise it just appears to hang. | 07:35 |
| jam | I'd like to find a middle ground | 07:35 |
| jam | but 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 trap | 07:36 |
| rogpeppe | jam: 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 place | 07:36 |
| rogpeppe | fwereade__: i think --debug is too much | 07:36 |
| jam | rogpeppe: I would guess 'juju' is more of a user binary than a script one, so we should bias towards that. | 07:36 |
| rogpeppe | fwereade__: but -v should be just right | 07:36 |
| fwereade__ | rogpeppe, agreed, I think it's awful | 07:36 |
| rogpeppe | jam: i think that's the way we're using it now, but i don't see that as its role in the future necessarily | 07:37 |
| fwereade__ | rogpeppe, IMO the somewhat forbidding user experience is a Really Bad Thing and anything that works against that is good | 07:38 |
| jam | rogpeppe: 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 |
| rogpeppe | fwereade__: i don't think the unix tradition is a Really Bad Thing | 07:38 |
| jam | Because we already have feedback from the rest of us (non-scriptors) | 07:38 |
| jam | that want more feedback | 07:38 |
| rogpeppe | jam: i'd like to make -v work well | 07:38 |
| rogpeppe | jam: and keep commands quiet by default | 07:39 |
| jam | rogpeppe: I would argue that things that get written into a script can do '-q' more easily than users can do '-v' | 07:39 |
| rogpeppe | jam: oh please no. i really don't want us to have a -q flag | 07:39 |
| rogpeppe | jam: next we'll be printing vt100 escape sequences | 07:40 |
| jam | rogpeppe: 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-term | 07:40 |
| fwereade__ | rogpeppe, what is your objection to "-q"? | 07:40 |
| rogpeppe | fwereade__: in general users follow the instructions they're given, which will probably have a -v flag | 07: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 base | 07:41 |
| rogpeppe | fwereade__: it's just one more piece of complexity. we are already (probably) going to have --verbose, --debug, --info, --error and maybe more logging related options | 07:42 |
| fwereade__ | rogpeppe, whoa, why would we have those things? | 07:42 |
| fwereade__ | rogpeppe, log-level maybe | 07:42 |
| rogpeppe | fwereade__: we want to be able to set the level of debugging at run time, no? | 07:42 |
| rogpeppe | fwereade__: ok, so --verbose, --debug, --log-level and now --quiet too | 07:43 |
| fwereade__ | rogpeppe, well, honestly, --debug and --verbose *are* plainly nonsense | 07:44 |
| rogpeppe | fwereade__: i think we should have --verbose and --log-level only probably | 07:44 |
| rogpeppe | fwereade__: with maybe --debug grandfathered in | 07: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 useful | 07:44 |
| rogpeppe | fwereade__: 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't | 07:45 |
| rogpeppe | fwereade__: we don't need to tell the user every time we make an RPC | 07:45 |
| fwereade__ | rogpeppe, I don;t think I was suggesting we should | 07:45 |
| rogpeppe | fwereade__: from the CL "Mostly because those are the bits that sit waiting on RPC" | 07:46 |
| rogpeppe | fwereade__: at the least we should have a public discussion about this | 07: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 shit | 07:48 |
| fwereade__ | rogpeppe, my user knowledge is, I freely admit, second-hand | 07:48 |
| fwereade__ | rogpeppe, there was not necessarily agreement about what the final answer should look like | 07: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 package | 07:50 |
| rogpeppe | fwereade__: 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 CL | 07:50 |
| rogpeppe | fwereade__: i agree; i don't think --verbose should affect the log level | 07:50 |
| fwereade__ | rogpeppe, ok, I didn't actually think that approach was deliberate at all | 07:51 |
| rogpeppe | fwereade__: although... given that we've got lots of log levels now, perhaps --verbose should be equivalent to --log-level info | 07:51 |
| fwereade__ | rogpeppe, maybe... I am still trying to figure out whether user output and logging are the same thing or not | 07:52 |
| rogpeppe | fwereade__: 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, etc | 07:53 |
| rogpeppe | fwereade__: 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, etc | 07:54 |
| fwereade__ | rogpeppe, yeah | 07:54 |
| rogpeppe | fwereade__: that sounds ok to me actualy | 07:55 |
| rogpeppe | lly | 07:55 |
| rogpeppe | fwereade__: a notice wants to be seen | 07:55 |
| fwereade__ | rogpeppe, yeah | 07:55 |
| rogpeppe | fwereade__: the question becomes then: what justifies a notice? | 07:56 |
| jam | rogpeppe: 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 user | 07:56 |
| fwereade__ | jam, they're shown on plain juju help iirc | 07:57 |
| jam | fwereade__: that tells you to init bootstrap etc | 07:57 |
| jam | no flag help | 07:57 |
| rogpeppe | jam: juju help global-options | 07:57 |
| fwereade__ | jam, tim didn't like polluting all the individual command helps with global flags | 07:57 |
| rogpeppe | jam: i argued against the approach of leaving out global flags from individual commands but failed to convince | 07:58 |
| jam | rogpeppe, fwereade__: so if a user does "juju help" then "juju help topics" then "juju help global-options" he can then see them | 07:58 |
| rogpeppe | jam: yeah :-| | 07:58 |
| jam | IOW, they will never see them | 07:58 |
| rogpeppe | jam: yeah | 07:58 |
| jam | except for someone that has a perversity for reading docs | 07:58 |
| jam | or is really struggling with something so goes to each help topic they can find | 07:59 |
| rogpeppe | jam: i agree | 07:59 |
| jam | anyway, the help for it says "log additional messages" | 07:59 |
| jam | which certainly doesn't sound like give me more feedback. | 07:59 |
| rogpeppe | jam: and i don't think we have enough flags to justify the "cleanliness" argument | 07:59 |
| === racedo` is now known as racedo | ||
| jam | rogpeppe: 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 default | 08:00 |
| fwereade__ | rogpeppe, do you know what the situation is wrt multiple log targets with different badging behaviour? | 08:00 |
| jam | fwereade__: 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 |
| jam | having it in Log certainly made it undiscoverable | 08:00 |
| jam | both to users, and to me as a dev. | 08:00 |
| fwereade__ | jam, +1 | 08:01 |
| jam | I'm still not sure how I get access to that flag (ctx.?) | 08:01 |
| fwereade__ | jam, you shouldn't need it | 08:01 |
| fwereade__ | jam, as a suggestion | 08:01 |
| rogpeppe | fwereade__: i suspect you can only have one level of log line taggin | 08:01 |
| rogpeppe | g | 08: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 that | 08:02 |
| jam | fwereade__: so "-v" appears to just add stderr as a place to write log messages | 08:02 |
| rogpeppe | fwereade__: can we have multiple log targets currently? | 08:02 |
| jam | Note that by default, we don't have a log file nor an output to the user | 08:02 |
| jam | so by default all messages are dropped into the nether | 08:03 |
| fwereade__ | jam, yeah, I know, and I agree that is bad | 08:03 |
| rogpeppe | jam: i think that's ok, but you know that :-) | 08:04 |
| rogpeppe | jam: well, except that i think the default log level should be Notice | 08:04 |
| rogpeppe | jam: (whatever that implies) | 08:04 |
| fwereade__ | rogpeppe, I think the choice of level for particular messages is something that we'll iterate on forever | 08:05 |
| rogpeppe | fwereade__: 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 so | 08:06 |
| rogpeppe | fwereade__, 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 me | 08:08 |
| jam | rogpeppe: so the one thing with my patch that we miss going to log, is that it gives incremental messages about copying tools. | 08:08 |
| jam | It doesn't know how big the thing is until it has downloaded it | 08:08 |
| jam | because Get() doesn't expose the size | 08:08 |
| jam | I can certainly use multiple lines for it | 08:08 |
| jam | but it was sort of nice to have it all on one line | 08:09 |
| fwereade__ | jam, I have a thought there actually | 08:09 |
| fwereade__ | jam, we have a couple of places already where we need to download things preferably-just-once, and check hashes, and suchlike | 08:10 |
| rogpeppe | List could provide some metadata | 08:10 |
| fwereade__ | jam, it *might* be worth checking for commonalities there | 08:10 |
| jam | rogpeppe: I imagine Get() might have a Content-Length header as well. | 08:11 |
| jam | But it isn't exposed yet. | 08:11 |
| jam | I had originally thought to just Put(Get) | 08:11 |
| jam | sort of thing | 08:11 |
| jam | rather than buffering anything | 08:11 |
| jam | but Put() requires knowing the content-length | 08:11 |
| rogpeppe | jam: unfortunately goamz/s3 throws away the info | 08:13 |
| rogpeppe | afk for 5 mins | 08:13 |
| rogpeppe | back | 08:27 |
| fwereade__ | afk myslf for a bit, sorry | 08:43 |
| jam | rogpeppe: yeah, goamz/s3 also doesn't let you Get anonymously :( | 08:43 |
| jam | But I already filed that bug. | 08:43 |
| fwereade__ | jam, I responded to some of your review points, still thinking about others | 08:43 |
| fwereade__ | jam, in https://codereview.appspot.com/8183044 | 08:43 |
| jam | fwereade__: I think I've addressed all your comments in https://codereview.appspot.com/8051043/ aside from what to do about user feedback. | 08:48 |
| rogpeppe | fwereade__: ping | 08:59 |
| dimitern | anybody else having issues with trunk after rev 1089? | 10:18 |
| dimitern | it seems cmd/builddb/main.go no longer compiles, because it imports "state" and is not using it | 10:19 |
| rogpeppe | dimitern: i see that. if you want to propose a trivial fix, that would be great! | 10:19 |
| dimitern | rogpeppe: well, I will but this shouldn't happen - somebody didn't run the tests before committing | 10:20 |
| rogpeppe | dimitern: agreed. you're welcome to ascribe blame if you want. | 10:20 |
| rogpeppe | :-) | 10:21 |
| mgz | there's a thread on the list about that | 10:21 |
| dimitern | rogpeppe: I think it's gary_poster's branch | 10:21 |
| rogpeppe | dimitern: that makes sense. it was a large change. | 10:21 |
| dimitern | and dfc committed after that also without running the tests | 10:22 |
| dimitern | I always do go build ./... && go test ./... in juju-core, that's how I caught it | 10:22 |
| dimitern | mgz, jam: standup? | 10:29 |
| mgz | I'm there | 10:34 |
| dimitern | I just left :) let me rejoin | 10:34 |
| dimitern | there it is - it's a trivial one-line change to fix trunk: https://codereview.appspot.com/8253043 | 10:46 |
| rogpeppe | fwereade__, 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 |
| dimitern | rogpeppe: do you have an idea why UnitStatus consts moved from state to state/api/params? | 10:58 |
| rogpeppe | dimitern: because they're visible in the API | 10:58 |
| dimitern | rogpeppe: but in state they're not? | 10:59 |
| rogpeppe | dimitern: they're visible in both state and state/api | 10:59 |
| dimitern | rogpeppe: I added state/status.go to manage unified unit and machine status | 10:59 |
| rogpeppe | dimitern: and state/api can't import state | 10:59 |
| dimitern | rogpeppe: so I should add state/api/params/status.go just for the constants | 11:00 |
| rogpeppe | dimitern: 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 |
| rogpeppe | dimitern: i'm not entirely sure that the recent changes were necessary though | 11:02 |
| dimitern | rogpeppe: ok, so can have operations in state/status.go and status consts in state/api/params/status.go - sound sane? | 11:02 |
| rogpeppe | dimitern: 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 |
| rogpeppe | dimitern: except... then they can't be seen by state/api Go clients. | 11:03 |
| dimitern | rogpeppe: well, having status related stuff in 2 modules seems wrong, but as a compromise for the api clients I suppose it's ok | 11:04 |
| rogpeppe | dimitern: what operations are you adding? | 11:04 |
| dimitern | rogpeppe: getStatus and setStatusOp | 11:05 |
| rogpeppe | dimitern: they seem like very state-oriented operations tbh | 11:05 |
| dimitern | rogpeppe: they are | 11:06 |
| dimitern | rogpeppe: that's why they'll remain in state/, while the consts will be in params | 11:07 |
| rogpeppe | dimitern: 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/api | 11:07 |
| rogpeppe | dimitern: cool. i thought you were bothered by that. | 11:07 |
| dimitern | rogpeppe: not especially, fixing merge conflicts now :) | 11:08 |
| rogpeppe | dimitern: so unit status is going into its own collection? | 11:09 |
| dimitern | rogpeppe: yes, along with the (new) machine status | 11:10 |
| rogpeppe | dimitern: the transaction lists get longer and longer :-) | 11:12 |
| dimitern | rogpeppe: but the code arguably better :) | 11:12 |
| dimitern | rogpeppe: 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 |
| dimitern | rogpeppe: and megawatcher tests fail | 11:21 |
| rogpeppe | dimitern: it is, yes | 11:22 |
| rogpeppe | dimitern: as the comment says, it's a subset | 11:22 |
| dimitern | rogpeppe: so I should remove these 2 fields from UnitInfo as well | 11:22 |
| rogpeppe | dimitern: 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 unitDoc | 11:22 |
| rogpeppe | dimitern: i guess so. i will need to make the allWatcher indirect (something i thought i could put off until after 13.04) | 11:23 |
| dimitern | rogpeppe: not anymore, for statuses at least | 11:23 |
| rogpeppe | dimitern: yeah, i see that | 11:23 |
| jam | mgz,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 |
| jam | We can certainly do whenever while wallyworld is on vacation for 2 weeks. | 11:54 |
| mgz | yeah, the timezone switch make life funner | 11:55 |
| dimitern | rogpeppe: PTAL https://codereview.appspot.com/8256043/ - the stuff around the API especially | 12:15 |
| rogpeppe | dimitern: looking | 12:17 |
| dimitern | also other reviewers are welcome :) | 12:17 |
| gary_poster | dimitern, rogpeppe sorry, I definitely did run tests, but I must have done something insufficiently, obviously | 12:17 |
| rogpeppe | gary_poster: i know what the problem was | 12:17 |
| gary_poster | what was it? | 12:17 |
| dimitern | gary_poster: np, it happens, but did you run go build ./... && go test ./... in the juju-core dir? | 12:17 |
| rogpeppe | gary_poster: go test ./... does not *build* everything. if there's a package with no tests (which builddb is) it will just be ignored | 12:18 |
| rogpeppe | gary_poster: personally i think that's a bug | 12:18 |
| rogpeppe | gary_poster: but it's the case | 12:18 |
| gary_poster | rogpeppe, dimitern that's it: I ran go test ./... but not go build ./... . I did not know if that requirement | 12:18 |
| gary_poster | of | 12:18 |
| dimitern | rogpeppe: and I really'd like the equivalent of go build for tests.. | 12:18 |
| rogpeppe | gary_poster: it's not your fault - i've been bitten by that before | 12:18 |
| gary_poster | Very good to know, thanks for fixing, and sorry for the problem | 12:19 |
| rogpeppe | dimitern: http://paste.ubuntu.com/5670234/ (i call it "gotest-c") | 12:19 |
| rogpeppe | dimitern: i pushed quite hard for go test -c ./... to work, but failed i'm afraid | 12:19 |
| dimitern | rogpeppe: ah, cool tool | 12:19 |
| dimitern | rogpeppe: hmm.. what was the cited reason not to do it? | 12:20 |
| gary_poster | actually it wasn't even my branch | 12:20 |
| rogpeppe | dimitern: too close to go1.1 | 12:20 |
| gary_poster | I will go spread the news on juju-gui | 12:20 |
| gary_poster | could have been my branch :-) | 12:20 |
| dimitern | gary_poster: oh, sorry then - but you see, you could've caught it with go build before go test ;) | 12:21 |
| gary_poster | dimitern, definitely! and it was a juju-gui branch, so we should all know about this | 12:21 |
| dimitern | gary_poster: cheers | 12:22 |
| dimitern | fwereade__: ping | 12:35 |
| fwereade__ | dimitern, pong | 12:36 |
| dimitern | fwereade__: hey, wanna take a look at machine status CL? https://codereview.appspot.com/8256043/ | 12:36 |
| fwereade__ | dimitern, ack | 12:36 |
| jam | rogpeppe: btw, your reply seems to have gone directly to me, rather than juju-dev list | 13:01 |
| rogpeppe | jam: oh, thanks! | 13:01 |
| davecheney | lads, the build really is broken, http://paste.ubuntu.com/5670353/ | 13:08 |
| dimitern | davecheney: so my fix was for unrelated issue | 13:09 |
| jam | davecheney: 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 |
| davecheney | jam: lucky(~/src/launchpad.net/juju-core) % bzr st . | 13:10 |
| davecheney | modified: version/version.go | 13:10 |
| davecheney | it's not my tree | 13:10 |
| davecheney | oh, and 1077 isn't that reliable a build either, | 13:11 |
| davecheney | http://paste.ubuntu.com/5670359/ | 13:11 |
| jam | davecheney: so with 1091 bootstrap works and brings an instance up, but deploying fails to bring up the unit agent, is that correct/ | 13:12 |
| jam | ? | 13:12 |
| davecheney | jam: that is correc | 13:12 |
| jam | I'm wondering if the cloudinit on unit agents is accidentaly downloading published tools, rather than --upload-tools | 13:12 |
| davecheney | correct | 13:12 |
| davecheney | this is machine 1 | 13:12 |
| jam | so it is reverting to 1.9.12 on the non-bootstrap nodes | 13:12 |
| davecheney | ha! | 13:12 |
| davecheney | 2013-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 |
| jam | davecheney: can you ssh in and check 'jujud --version' ? | 13:12 |
| davecheney | ^ indeed they are | 13:12 |
| davecheney | jam: good guess | 13:12 |
| jam | davecheney: at least it make sense, even if it is still broken :) | 13:13 |
| davecheney | so, it's been broken for how long then ? | 13:13 |
| davecheney | since last friday ? | 13:13 |
| jam | davecheney: my guess is downloading the wrong tools has been true for a while | 13:13 |
| jam | but we have'nt broken compatibility in a while | 13:13 |
| davecheney | interesting | 13:13 |
| davecheney | that could explain why I can't get the fscker to work at _all_ in hp cloud | 13:14 |
| rogpeppe | davecheney: yes, if you're trying to deploy a precise charm from quantal, the tools logic will fall back to the tools in the public bucket | 13:16 |
| rogpeppe | davecheney: i believe there are plans to change this, but that's how it is currently | 13:16 |
| rogpeppe | davecheney: (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 |
| davecheney | rogpeppe: oh indeed | 13:17 |
| davecheney | you are right | 13:17 |
| davecheney | so the tools are following the series of the charm ... | 13:17 |
| davecheney | which means --upload-tools is useless | 13:18 |
| rogpeppe | davecheney: yes, they have to | 13:18 |
| davecheney | rogpeppe: i agree they have too, but they never used too | 13:18 |
| davecheney | see prevoius point about --upload-tools being useless | 13:18 |
| rogpeppe | davecheney: it means that if you want upload-tools to work you have to deploy a charm with the same series as your current machine | 13:18 |
| jam | davecheney: 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 |
| rogpeppe | davecheney: which actually makes some kind of sense | 13:18 |
| rogpeppe | jam: i suspect there's no actually difference at all. | 13:19 |
| davecheney | jam: the Q tools are built by a Q bot | 13:19 |
| davecheney | but in practice, it makes no difference | 13:19 |
| davecheney | rogpeppe: i know it makes sense | 13:20 |
| TheMue | fwereade__: ping | 13:20 |
| davecheney | it's just impossible to make work | 13:20 |
| davecheney | ie, this cross series lunacy | 13:20 |
| fwereade__ | TheMue, pong | 13:20 |
| davecheney | i have deployed a quantal bootstrap node | 13:20 |
| davecheney | then I got to deploy a precise mysql node becuase there is no cs:quantal/mysql charm | 13:20 |
| davecheney | and --upload-tools fails me | 13:20 |
| davecheney | to be clear | 13:20 |
| TheMue | fwereade__: we still have a decision open regarding the environ config. | 13:20 |
| davecheney | i understand why it does what it does | 13:21 |
| rogpeppe | davecheney: download the precise mysql charm and rename it to quantal | 13:21 |
| davecheney | rogpeppe: sure, but I lost the argument about cross series enviroments being a bad thin | 13:21 |
| TheMue | fwereade__: shall i refactor it to an own document with its own collection or stay with the attrs and add uuid? | 13:21 |
| davecheney | and now I'm having a sook about a place where it has blown up on me in testing | 13:21 |
| rogpeppe | davecheney: it wouldn't be such a problem if the error message was more clear | 13:21 |
| fwereade__ | TheMue, add a new document please | 13:21 |
| davecheney | rogpeppe: true, that would at least let me understand what went wrong | 13:22 |
| rogpeppe | davecheney: exactly. you are by no means the first person to have been bitten by this hard-to-diagnose issue | 13:22 |
| fwereade__ | TheMue, there is already a stte.Environment entity, you just need to back it with a doc | 13:23 |
| davecheney | rogpeppe: without twisting the knife | 13:23 |
| davecheney | this is exactly the kind of nonsnse that will haunt us too our graves with cross series environments | 13:23 |
| rogpeppe | davecheney: only if we make backwardly incompatible changes without changing the major version number | 13:24 |
| TheMue | fwereade__: 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 clearer | 13:25 |
| rogpeppe | davecheney: 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 |
| davecheney | FUCK | 13:26 |
| davecheney | now when i use --upload-tools it doens't respect default-series | 13: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 |
| davecheney | fwereade__: yeah, that might have to be the solution for the moment | 13:27 |
| davecheney | still doesn't solve my second outburst | 13:27 |
| fwereade__ | davecheney, you can always override default-series, unless I'm very confused | 13:28 |
| davecheney | ap-southeast-1: | 13:28 |
| davecheney | type: ec2 | 13:29 |
| davecheney | default-series: precise | 13:29 |
| davecheney | region: ap-southeast-1 | 13:29 |
| davecheney | lucky(~) % ssh ec2-46-137-197-55.ap-southeast-1.compute.amazonaws.com -l ubuntu -- lsb_release -a | 13:29 |
| fwereade__ | davecheney, --upload-tools overwrites it, on the basis that if you're uploading tools you want to run them | 13:29 |
| davecheney | No LSB modules are available. | 13:29 |
| davecheney | Distributor ID: Ubuntu | 13:29 |
| davecheney | Description: Ubuntu 12.10 | 13:29 |
| davecheney | Release: 12.10 | 13:29 |
| davecheney | Codename: quantal | 13:29 |
| davecheney | fwereade__: fuck, so now i'm stuck in the position that I cannot test precise charms without a precise host to run juju cli | 13:29 |
| fwereade__ | davecheney, but that behaviour would surely be dropped if we uploaded multiple tools | 13:30 |
| davecheney | fwereade__: hmmm, i don't see how | 13:30 |
| davecheney | FindBestTools won't consider tools outside the series | 13:31 |
| fwereade__ | davecheney, right, but we'd be starting precise machines just fine if we were asking for them | 13:31 |
| davecheney | fwereade__: so tim and I cannot do that | 13:32 |
| davecheney | i have a quantal machine, he has raring | 13:32 |
| fwereade__ | davecheney, surely if you do explicitly `deploy precise/wordpress` you'll get a precise machine... it just might not have compatible tools | 13:32 |
| davecheney | fwereade__: yup, that works, and leads to the original problem | 13:32 |
| davecheney | i guess then if we upload multiple tools | 13:32 |
| davecheney | then that is a solid workaround | 13:32 |
| fwereade__ | davecheney, I think upload-multiple-tools + look-in-one-bucket-only together should make things properly clear | 13: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 anyway | 13:34 |
| === wedgwood_away is now known as wedgwood | ||
| davecheney | fairy nuf | 13:35 |
| davecheney | it's late here | 13:35 |
| davecheney | i'll catch you on the flip side | 13:35 |
| dimitern | rogpeppe: did you manage to review it? | 13:35 |
| === wedgwood is now known as Guest6347 | ||
| rogpeppe | dimitern: in a call | 13:36 |
| mramm | I'll be out for the day -- but am just doing some home maintenance stuff so I'll be around if needed | 13:36 |
| mramm | I'll try to be at the kanban meeting in 20 min though! | 13:37 |
| fwereade__ | mramm, cool | 13:37 |
| rogpeppe | fwereade__: +1 | 13:59 |
| fwereade__ | rogpeppe, cheers | 13:59 |
| rogpeppe | fwereade__: --fake-tools raring,quantal | 13:59 |
| rogpeppe | fwereade__: perhaps | 13:59 |
| fwereade__ | rogpeppe, perfect, saves us hardcoding them | 14: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 now | 14:00 |
| jam | could we instead just have FindTools understand an "-any-" series? | 14:06 |
| === marco is now known as Guest28583 | ||
| dimitern | fwereade__: how's going? | 14:27 |
| * rogpeppe gets a bite to eat | 14:34 | |
| === Guest28583 is now known as marcoceppi | ||
| dimitern | I still need review of https://codereview.appspot.com/8256043/ | 14:50 |
| dimitern | rogpeppe, fwereade__ ^^ | 14:54 |
| fwereade__ | dimitern, hey, sorry, I was writing one in some detail and got caught up by the meeting | 15:05 |
| dimitern | fwereade__: no worries | 15:05 |
| dimitern | TheMue: thanks for the review! | 15:13 |
| gary_poster | fwereade__, 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 state | 15:25 |
| gary_poster | fwereade__, 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_poster | fwereade__, cool, sounds good. :-) thanks! | 15:26 |
| gary_poster | rogpeppe, fwiw, ^^^ that's off our plate for the time being at least | 15:27 |
| rogpeppe | gary_poster: cool | 15:27 |
| rogpeppe | dimitern: you have a review | 15:29 |
| fwereade__ | dimitern, and another | 15:33 |
| dimitern | rogpeppe, fwereade__: cheers guys | 15:34 |
| dimitern | fwereade__: about juju status discarding errors - it was like that before I changed the unit status not to return error | 15:37 |
| dimitern | fwereade__: how are we supposed to report such errors? | 15:37 |
| fwereade__ | dimitern, that doesn't make me any happier to change it back ;p | 15:37 |
| fwereade__ | dimitern, there seems to be a checkError() pattern in use in there | 15:37 |
| fwereade__ | where things we can't get are represented as a {"status-error": "something happened, oh noes"} | 15:38 |
| jam | mgz: all the juju patches, should we be reviewing or is that more a kapil thing? | 15:59 |
| mgz | it's mostly an auditing thing | 16:00 |
| mgz | the fun part is in the packaging branches anyway really | 16:01 |
| jam | it looks like most of them are already landed | 16:01 |
| mgz | particular because of bug 985285 | 16: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 |
| jam | weird that I get the mp, but not the "merged" emails | 16:01 |
| mgz | is there someway I can get bzr to give me a diff ignoring file-id changes? | 16:02 |
| mgz | oddly --take-other is deleting files that don't get included as part of other... builddeb is struggling for sanity here | 16:02 |
| jam | mgz: so why the backports to 0.5? | 16:41 |
| jam | vs just releasing the 0.6/7/whatever? | 16:41 |
| mgz | they were just in the list for a release | 16:41 |
| mgz | it doesn't hurt and was easy, at least compared to battling builddeb | 16:41 |
| mgz | the fact the packing branches are completly screwed is more troublesome | 16:42 |
| rogpeppe | fwereade__: ping | 16:49 |
| rogpeppe | fwereade__, dimitern: fairly trivial: https://codereview.appspot.com/8266043 | 17:09 |
| dimitern | rogpeppe: reviewed | 17:21 |
| rogpeppe | dimitern: ta! | 17:21 |
| TheMue | rogpeppe: and another review | 17:25 |
| rogpeppe | TheMue: thanks | 17:25 |
| === deryck is now known as deryck[lunch] | ||
| * rogpeppe reaches end of day | 17:38 | |
| rogpeppe | here'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 |
| benji | rogpeppe: I bet you are about EOD, but I have a review up if you have a minute: https://codereview.appspot.com/8271043 | 18:05 |
| rogpeppe | benji: no cycles then? | 18:27 |
| benji | rogpeppe: nope; they were only in my head | 18:28 |
| rogpeppe | benji: 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 serialized | 18:34 |
| === deryck[lunch] is now known as deryck | ||
| benji | rogpeppe: thanks for the suggestion, I'll do so | 18:41 |
| thumper | morning | 20:11 |
| * thumper head desks | 20:47 | |
| thumper | fwereade__: ping? | 21:12 |
| thumper | benji: you are good to merge | 21:50 |
| benji | thumper: thanks! | 21:50 |
| thumper | fwereade__: 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 coffee | 21:52 | |
| * thumper waits for dave | 23:13 | |
| === Guest6347 is now known as wedgwood_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!