| thumper | hi davecheney | 01:44 |
|---|---|---|
| davecheney | thumper: hi mate | 01:49 |
| davecheney | just about to get on a plane back to syd | 01:49 |
| davecheney | got 10 mins to talk | 01:49 |
| thumper | oh, ok | 01:50 |
| davecheney | thanks for your CL that hard codes precise | 01:50 |
| thumper | davecheney: the ec2 screwage was due to the series changes I did some time ago | 01:50 |
| davecheney | that will probably solve the problem | 01:50 |
| thumper | davecheney: it does (at least for me) | 01:50 |
| davecheney | that whole debarcale made me so angry last night | 01:50 |
| thumper | davecheney: I was broke, made the change, and it worked and deployed something | 01:50 |
| thumper | sorry about that | 01:50 |
| thumper | I've been learning a lot about tools recently | 01:51 |
| davecheney | nah, not your fault | 01:51 |
| thumper | I also have some man page chagnes | 01:51 |
| davecheney | I have half a mind to demand that everyone takes one for the team and upgrades off precise so they can see what it's like | 01:51 |
| davecheney | this shit just works if your laptop runs precise | 01:51 |
| thumper | davecheney: no-one should be using precise | 01:51 |
| thumper | davecheney: company policy says you should be using the latest | 01:51 |
| thumper | davecheney: and upgrade to the new version at beta time | 01:51 |
| * davecheney agrees with thumper | 01:51 | |
| davecheney | well, i dunno about raring | 01:52 |
| thumper | those are the rules | 01:52 |
| thumper | the whole company should upgrade to raring at raring beta time | 01:52 |
| thumper | always has been therule | 01:52 |
| davecheney | i think it isn't well communicated to new starters | 01:52 |
| thumper | heh | 01:52 |
| davecheney | not that much is | 01:52 |
| thumper | davecheney: so I want to run ./scripts/generate-docs.py man -o - | gzip > /usr/share/man/man1/juju.1.gz | 01:53 |
| thumper | but I need a sudo somewhere | 01:53 |
| thumper | how to I make that work? | 01:53 |
| davecheney | thumper: no idea, never used that before | 01:53 |
| thumper | :) | 01:53 |
| davecheney | is that from the older python juju ? | 01:53 |
| thumper | no, something I've just made | 01:53 |
| thumper | about to propose it | 01:53 |
| thumper | but we need some install magic... | 01:53 |
| thumper | for the deb | 01:54 |
| davecheney | ohhhhhhhhh, i see the problem | 01:54 |
| thumper | right :) | 01:54 |
| thumper | I wrote it in python because it was a lot faster for me | 01:54 |
| davecheney | this is normally done in a postinstall | 01:54 |
| davecheney | right ? | 01:54 |
| thumper | right | 01:54 |
| davecheney | that runs as root correct ? | 01:54 |
| thumper | probably | 01:54 |
| davecheney | doesn't fakeroot make it work enough for testing ? | 01:54 |
| thumper | but I don't know how to test it | 01:54 |
| thumper | well, locally I just go: ./generate-docs.py man | 01:54 |
| thumper | man ./juju.1 | 01:55 |
| thumper | and it works | 01:55 |
| davecheney | can you test by making the path relative ? | 01:55 |
| davecheney | ie | 01:55 |
| davecheney | gzip > usr/share/.... | 01:55 |
| thumper | I'll ask someone who knows packages :) | 01:55 |
| thumper | where do we store our packaging info? | 01:55 |
| thumper | and is there a way I can test it? | 01:56 |
| davecheney | package info ? | 01:56 |
| davecheney | the debian/ overlay ? | 01:56 |
| davecheney | have a look at the build recipes from the juju-core page | 01:57 |
| thumper | ok, ta | 01:57 |
| davecheney | the overlay repo is owned by me | 01:57 |
| * thumper nods | 01:57 | |
| davecheney | no good reason for that | 01:57 |
| davecheney | it just is | 01:57 |
| davecheney | sorry, i have tiny internet, so it'll be faster for you to find it than me | 01:57 |
| * thumper nods | 01:58 | |
| thumper | that's fine | 01:58 |
| * thumper has munchies | 02:36 | |
| === gary_poster is now known as gary_poster|away | ||
| * thumper goes to make dinner, back later to talk with fwereade__ | 03:28 | |
| === thumper is now known as thumper-afk | ||
| TheMue | morning | 06:06 |
| === thumper-afk is now known as thumper | ||
| bigjools | fwereade__: hi, around? | 07:47 |
| fwereade__ | bigjools, heyhey, in a hangout so responding slowly, but yes | 07:47 |
| bigjools | fwereade__: ah ok, I'd like to do a quick hangout with you, can you let me know when you're free please | 07:47 |
| === lynxman_ is now known as lynxman | ||
| jam | fwereade__: 2 things I need to discuss with you, though I'm about to head to lunch. (1) What have we decided about fmt.Fprintf vs log.Infof? I'd like to land something, that is the last bit remaining. (At this point, I've stopped caring, just looking for an answer so I can land). (2) You wanted to talk about --public. | 07:51 |
| jam | I should be back in 1-2 hrs. I'll ping you when I'm back | 07:51 |
| rogpeppe | morning all | 07:52 |
| davecheney | evenin' | 07:54 |
| dimitern | jam: Fprintf, as I recall, because log output from commands is discarded | 07:54 |
| fwereade__ | jam, cheers | 07:58 |
| === andrewdeane is now known as awd | ||
| rogpeppe | jam: i would prefer a two stage solution - first crank up the default logging level to "Notice" and add a way to set the logging level. then use log.Infof and log.Noticef as appropriate. | 08:06 |
| rogpeppe | jam: the fact that all log output from commands is discarded, even errors, is i think wrong. | 08:06 |
| fwereade__ | bigjools, heyhey | 08:19 |
| fwereade__ | bigjools, available in 3 minutes or so, would you start a hangout please? | 08:20 |
| bigjools | fwereade__: hi, yes, let me find you on g+ | 08:20 |
| bigjools | fwereade__: invited you | 08:23 |
| dimitern | rogpeppe: when I was doing upgrade-charm cmd, I added logging and was wondering why virtually no other cmds use it (except the bootstrap I think) and fwereade__ suggested that I should remove it, because the output gets ignored | 08:34 |
| rogpeppe | dimitern: this is something we need to sort out | 08:34 |
| rogpeppe | dimitern: i've made my views clear; i suspect i won't win the argument though. | 08:35 |
| dimitern | rogpeppe: yeah it's a little worrying | 08:35 |
| rogpeppe | dimitern: thanks for your review this morning, BTW | 08:35 |
| dimitern | rogpeppe: sure thing | 08:36 |
| dimitern | rogpeppe: so is this a step towards indirect watching | 08:36 |
| rogpeppe | dimitern: yup | 08:36 |
| fwereade__ | dimitern, rogpeppe: it is true that we need to sort out logging/feedback; I'm still not so sure it's something we should be committing to fixing for 13.04 | 08:37 |
| dimitern | rogpeppe: cool, how is it going to work for status, i'm curious? | 08:37 |
| rogpeppe | dimitern: the backing is now free to make whatever changes it likes to the allInfo in response to a mongo change | 08:37 |
| rogpeppe | dimitern: when the allWatcher backing sees a status change, it will look up the object that the status is referring to in the allInfo and update the status on that | 08:38 |
| rogpeppe | dimitern: i'm not yet sure if we're guaranteed to see the status change before we see the object itself being created | 08:39 |
| rogpeppe | dimitern: i think we are, as the status change happens in a separate transaction | 08:40 |
| fwereade__ | .me afk a bit | 08:41 |
| dimitern | rogpeppe: cool stuff! well for one, unit/machine status won't change on u/m creation, only afterwards (it defaults to pending) | 08:43 |
| rogpeppe | dimitern: yeah. i'll have to do this for other stuff too, like service config and constraints | 08:43 |
| * rogpeppe has a look at the txn source. | 08:44 | |
| dimitern | rogpeppe: yeah, sgtm | 08:44 |
| * rogpeppe just noticed that txn.Runner.Run isn't entirely thread safe | 08:55 | |
| rogpeppe | but perhaps i'm missing something | 08:55 |
| davecheney | rogpeppe: eeeeeeeeeeeek | 09:03 |
| rogpeppe | davecheney: it's nothing too bad | 09:03 |
| rogpeppe | davecheney: just that bson.NewObjectId does a non-thread-safe lazy initialization of the machine id | 09:03 |
| rogpeppe | davecheney: i'm about to propose a fix | 09:04 |
| davecheney | rogpeppe: +1 | 09:04 |
| * rogpeppe strays off the lbox beaten track and gets bitten by a panic in the undergrowth | 09:16 | |
| * TheMue dcc's rogpeppe a plaster | 09:20 | |
| * davecheney visits instantrimshot.com | 09:20 | |
| dimitern | fwereade__: I realised I didn't include removeStatusOp :) good thing to write better tests | 09:26 |
| fwereade__ | dimitern, cheers | 09:26 |
| dimitern | fwereade__: I think it came along nicely, will propose it in a bit - you wanted to see it, right? | 09:27 |
| fwereade__ | dimitern, please, yeah | 09:27 |
| rogpeppe | mgz: ping | 09:33 |
| mgz | hey rogpeppe | 09:34 |
| rogpeppe | mgz: i'm just trying to diagnose an lbox problem - it's saying no common ancestor between two branches. how can i see the revisions leading up to a particular revision id? (in this case, gustavo@niemeyer.net-20120622195450-4kpn1az3v9nnld2c) | 09:35 |
| mgz | `bzr log -n0 -rrevid:^THAT` | 09:36 |
| rogpeppe | mgz: ha! i've just worked it out, no probs | 09:36 |
| rogpeppe | mgz: i did bzr log -r ..gustavo@niemeyer.net-20120622195450-4kpn1az3v9nnld2c | 09:36 |
| mgz | right, -r is smart by default, if something looks like a revid rather than a revno it can work it out | 09:37 |
| rogpeppe | mgz: interestingly yours only printed a single log message | 09:38 |
| mgz | yea, you want the leading .. for the history to that point | 09:39 |
| dimitern | fwereade__: there it is - https://codereview.appspot.com/8256043/ | 09:39 |
| fwereade__ | dimitern, cheers, I'm just writing an essay on it atm, I'll look atthe changes soon | 09:39 |
| dimitern | fwereade__: wow, an essay, why? | 09:40 |
| fwereade__ | dimitern, well, not really | 09:40 |
| dimitern | fwereade__: to explain why the approach is better than having status in the docs? | 09:40 |
| fwereade__ | dimitern, I'm just trying to add a concise response to rogpeppe and TheMue's concerns re doc-splitting | 09:40 |
| dimitern | fwereade__: :) thought so, cheers - I tried to the best of my knowledge to reply, but I'd appreciate yours as well | 09:41 |
| dimitern | fwereade__: following on status stuff, there are 3 cards on the kanban board which are related. i think i can pick up the one about MA setting status next | 09:52 |
| rogpeppe | davecheney: https://codereview.appspot.com/8306043 | 09:55 |
| * davecheney looks | 09:55 | |
| rogpeppe | mgz: i think something must have been sticky. i started again with a fresh branch and it all worked. | 09:57 |
| rogpeppe | davecheney: i can't really see any down sides to the change to use an array rather than a slice. it's about the same number of lines of source, and it has the additional advantage that the indexes are checked at compile time. if there was any additional complexity involved, i'd agree. | 10:09 |
| rogpeppe | s/lines of source/number of bytes of source/ | 10:09 |
| mgz | rogpeppe: lbox does do some very voodoo things and its assumptions when creating new branches and merging don't seem solid to me | 10:10 |
| rogpeppe | mgz: yeah, i've got that impression | 10:11 |
| rogpeppe | mgz: it doesn't help that the error messages often don't include the stderr from the bzr command that failed | 10:11 |
| rogpeppe | mgz: i only found out what was going on by delving in and changing the source | 10:11 |
| dimitern | jam: standup? | 10:30 |
| rogpeppe | fwereade__: ping | 10:41 |
| rogpeppe | dimitern: ping | 10:42 |
| dimitern | rogpeppe: pong | 10:43 |
| rogpeppe | dimitern: i was just wondering why a Unit doesn't have a charm url set by default. | 10:43 |
| rogpeppe | dimitern: perhaps you could explain? | 10:43 |
| dimitern | rogpeppe: because it needs to be deployed first | 10:44 |
| dimitern | rogpeppe: and there are sanity checks to perform in SetCharm as well | 10:45 |
| dimitern | rogpeppe: makes sense? | 10:45 |
| * dimitern lunch, bbiab | 10:46 | |
| rogpeppe | dimitern: so you'll always get a charm url set when a unit starts running? | 10:46 |
| dimitern | rogpeppe: I think so, yes - when it's in the started state the charm's already deployed | 10:47 |
| rogpeppe | dimitern: cool | 10:47 |
| jam | dimitern, mgz: the standup time is still now rather than 1hr ago, though we haven't actually had a chance to discuss moving it. | 11:22 |
| mgz | right, we were just checking | 11:22 |
| dimitern | back | 11:29 |
| dimitern | mgz: ping | 11:31 |
| jam | mgz: you coming to mumble? | 11:31 |
| jam | fwereade__: I'm back around, though we have our standup for about 15 min. Thanks for commenting on the CL. now just to chat about --public | 11:36 |
| fwereade__ | jam, sure, I'll be around | 11:36 |
| fwereade__ | rogpeppe, hell, sorry, I didn't see that | 11:36 |
| fwereade__ | rogpeppe, what can I do for you? | 11:36 |
| rogpeppe | fwereade__: np. i got an answer from dimitern | 11:39 |
| dimitern | fwereade__: so basically LGTM from you? | 11:40 |
| fwereade__ | rogpeppe, ah, yes -- to be specific, the unit sets its charm URL once it knows what charm it's going to use | 11:40 |
| fwereade__ | dimitern, I have a lot of comments that I'm still making -- we should talk, and figure out which of them should be addressed and when, and that will then segue into an LGTM when we agree :) | 11:41 |
| dimitern | fwereade__: sure, thanks | 11:42 |
| fwereade__ | dimitern, just reviewed, maybe read over it after the standup while I talk to jam? | 11:42 |
| dimitern | fwereade__: cheers, sgtm | 11:43 |
| dimitern | fwereade__: ping me when you have 10m for a g+ please | 11:49 |
| jam | fwereade__: so you had some concern about --public vs local tools | 11:49 |
| jam | I believe without --public it is roughly equivalent to '--upload-tools' except we are using the public tools. | 11:49 |
| TheMue | fwereade__: thx for your response regarding the multi docs | 11:54 |
| fwereade__ | TheMue, yw, hope it made some sense | 11:54 |
| fwereade__ | jam, really quick g+? | 11:54 |
| jam | fwereade__: sure | 11:55 |
| TheMue | fwereade__: yes, so far i can live with it. only my concerns about transactions done by the accessing software and not the dbms itself still remain. but i'm fine if i'm wrong here. ;) | 11:57 |
| mgz | oh lord i think this is actually working... | 12:02 |
| rogpeppe | mgz: always a worrying moment | 12:02 |
| jam | mgz: you got it? | 12:03 |
| jam | yay | 12:03 |
| jam | I wonder if you could have avoided the intermediate commit with "rm -rf *; bzr merge --force -r 0..-1 ..." | 12:04 |
| jam | but if the commit helps, great. | 12:04 |
| === wedgwood_away is now known as wedgwood | ||
| rogpeppe | fwereade__: have you got time for a v quick G+ chat? | 12:04 |
| === wedgwood is now known as Guest65596 | ||
| fwereade__ | rogpeppe, not just now, I think... about to talk to dimiter and will really need some lunch after that I think | 12:05 |
| rogpeppe | fwereade__: ok, np. i need to resolve some issues around the allWatcher and split documents. | 12:06 |
| rogpeppe | fwereade__: i *think* i understand the issues, but i just want to make sure | 12:06 |
| fwereade__ | rogpeppe, ah, ok: was my suggestion that it should be directly analogous to annotation watching sensible? | 12:07 |
| rogpeppe | fwereade__: not really. we don't want the allWatcher client to be aware of every split. | 12:07 |
| fwereade__ | rogpeppe, ok, so I guess you want status and presence watches feeding into the unit and machine infos | 12:10 |
| rogpeppe | fwereade__: yup | 12:10 |
| rogpeppe | fwereade__: and it's the issues around doing that that i need to resolve | 12:10 |
| rogpeppe | fwereade__: in particular the txn log ordering | 12:10 |
| rogpeppe | fwereade__: for instance, if the status doc is created in the same transaction as its unit, i don't think there's any guarantee that i'll see the unit before i see its status. | 12:11 |
| rogpeppe | fwereade__: which means, i think, that i'll need a side-stash where we store items that we've been told about but that we don't yet know the parent docs for. | 12:13 |
| rogpeppe | fwereade__: because we don't want to be telling a client about a unit status without any other info about that unit. | 12:13 |
| fwereade__ | rogpeppe, or you could drop events for unrecognised statuses on the floor, and when first constructing an X doc grab the status explicitly that one time | 12:14 |
| fwereade__ | rogpeppe, for future changes, just update the fields you need to in the info doc and reorder as appropriate | 12:15 |
| fwereade__ | rogpeppe, (whether those changes are to the object or to its status) | 12:15 |
| * rogpeppe tries to work out if that's guaranteed to work | 12:15 | |
| jam | interesting, if you start 'lbox submit', and it starts checking your tree, and then you 'bzr switch' while it is still thinking about uploading | 12:16 |
| jam | it will end up submitting the new branch | 12:16 |
| jam | even though it tested the old | 12:16 |
| rogpeppe | jam: ha. "don't do that" :-) | 12:16 |
| jam | rogpeppe: fortunately both were meant to be submitted eventually | 12:17 |
| jam | I switched in order to clean up the second for submit | 12:17 |
| jam | so I just ended up pulling that back into the first | 12:17 |
| rogpeppe | jam: i've done a similar thing before. | 12:17 |
| rogpeppe | fwereade__: yes, i think that'll work ok. we'll be doing more work than strictly necessary, but that's true all round anyway | 12:19 |
| fwereade__ | rogpeppe, cool | 12:19 |
| * fwereade__ has a relieved :) | 12:19 | |
| === wedgwood is now known as Guest36969 | ||
| jam | mgz: is everything looking good? | 12:49 |
| mgz | think so, doing recipe builds now to see | 12:50 |
| mgz | got some local prpv | 12:50 |
| mgz | ....provider test failures, under packing build/test environment that didn't appear when run in branch, but that's not related to any changes in branch so far as I can see | 12:50 |
| jam | mgz: care to walk me through how to make a bucket public and what its URL would then be? | 13:00 |
| mgz | on what cloud? | 13:01 |
| jam | mgz: in this case, canonistack | 13:02 |
| jam | I think I can 'swift post juju-dist -r ???' | 13:02 |
| mgz | ".r:*,.rlistings" | 13:04 |
| jam | mgz: then how do I translate that into a public url? | 13:07 |
| jam | manually hack the auth info? | 13:07 |
| jam | looks like if I do a manual auth request I can just grab the publicURL for the swift endpoint. | 13:13 |
| jam | yay, looks like it worked | 13:14 |
| jam | we now have a public bucket for canonistack | 13:14 |
| dimitern | fwereade__: ping | 13:22 |
| fwereade__ | dimitern, pong | 13:34 |
| dimitern | fwereade__: forgot to ask about moving status docs where they're used, but I figured you meant moving them in unit/machine.go respectively | 13:35 |
| fwereade__ | dimitern, yeah, sorry | 13:36 |
| dimitern | fwereade__: np, so re lazy creation of status docs - now it's explicit in addUnit/MachineOps | 13:37 |
| fwereade__ | dimitern, sweet | 13:38 |
| * dimitern started to feel at home in the state package :) | 13:38 | |
| dimitern | fwereade__: something's fishy about removeUnitOps - when there's one unit only it returns s.removeOps | 13:48 |
| fwereade__ | dimitern, always? | 13:50 |
| fwereade__ | dimitern, or when there's one unit *and* the service is Dying? | 13:50 |
| dimitern | fwereade__: when it's dying, RC=0, UC=1 | 13:51 |
| fwereade__ | dimitern, yep -- removal of the last unit should also remove the service | 13:51 |
| fwereade__ | dimitern, (of a Dying service) | 13:51 |
| dimitern | fwereade__: the thing is, this is not enough I think - we should also remove the status there, right? | 13:52 |
| fwereade__ | dimitern, if removeUnitOps is failing to remove the unit, or any of its associated data, that should be rectified | 13:53 |
| dimitern | fwereade__: re https://codereview.appspot.com/8256043/diff/11001/state/service.go#newcode611 | 13:53 |
| dimitern | fwereade__: I think I'm correct in putting removeStatusOp there, because it'll be included in the case above | 13:53 |
| fwereade__ | dimitern, hm, ok | 13:54 |
| dimitern | fwereade__: if I move removeStatusOp at the end we'll miss the case when svc is dying | 13:54 |
| fwereade__ | dimitern, you've found two bugs in unit removal, I suspect | 13:54 |
| fwereade__ | dimitern, one is that the annotation removal is only done at the end, and is missed in the final-unit-of-dying-service case | 13:55 |
| dimitern | fwereade__: not quite sure what I found yet, but moving it at the end causes a lot of tests to fail | 13:55 |
| dimitern | fwereade__: right! | 13:55 |
| fwereade__ | dimitern, another is that the constraints removal op is done too early | 13:55 |
| dimitern | fwereade__: so all these 3 should go after Remove: true of the unit: constraints, status, annotations | 13:56 |
| fwereade__ | dimitern, yep: your mission is to find the right way to code that nicely :) | 13:56 |
| dimitern | fwereade__: well, just adding them in the append call that adds the removal of the unit doc seems fine? | 13:57 |
| fwereade__ | dimitern, and on general principles it's probably best to do the service removal ops last, once you've sorted out the unit | 13:57 |
| fwereade__ | dimitern, yeah, I'm just whining about having to keep track of the constraint removal op | 13:57 |
| fwereade__ | dimitern, hey, I have an evil idea | 13:58 |
| dimitern | fwereade__: yeah? | 13:58 |
| fwereade__ | dimitern, drop the Assert from removeConstraintsOp and use it unconditionally | 13:58 |
| fwereade__ | dimitern, mgo/txn will ignore a remove of a doc that doesn't exist | 13:58 |
| dimitern | fwereade__: yeah, I did that for removeStatusOp as well | 13:59 |
| fwereade__ | dimitern, I noticed -- I think it's a good practice in general | 13:59 |
| fwereade__ | dimitern, for that sort of data anyway | 13:59 |
| fwereade__ | dimitern, excellent | 13:59 |
| dimitern | fwereade__: sweet! now tests pass :) | 14:00 |
| fwereade__ | dimitern, that'll let you lose a level of indentation in the else clause at the top of the method too | 14:00 |
| dimitern | fwereade__: where? | 14:01 |
| dimitern | fwereade__: u.doc.MachineId != "" ? | 14:01 |
| fwereade__ | dimitern, yeah, that becomes `else if ... {` not `else { if ... {` | 14:02 |
| dimitern | fwereade__: done, only one thing remains | 14:02 |
| dimitern | fwereade__: in the unit/machine get/set status test when dying | 14:03 |
| dimitern | fwereade__: Status() always returns successfully, even when the thing is removed | 14:03 |
| fwereade__ | dimitern, yeah, fix that -- now the docs are guaranteed, there's no justification for that missing=pending nonsense | 14:04 |
| dimitern | fwereade__: that's because of the Pending default case | 14:04 |
| fwereade__ | dimitern, and for that matter there's no justification for Pending being "", either | 14:04 |
| dimitern | fwereade__: sure, will do | 14:05 |
| dimitern | jam: now I see the sync-tools cmd's filenames are with underscore, I think this needs to change to conform to the other commands. it's not just bitching, but underscores are usually for test modules :) | 14:17 |
| rogpeppe | fwereade__: you might be pleased to know that i just saw TestBootstrapAndDeploy pass. | 14:29 |
| * fwereade__ cheers wildly and flings lacy unmentionables | 14:29 | |
| dimitern | fwereade__: wanna last glance at https://codereview.appspot.com/8256043 before I throw it in trunk? | 14:30 |
| fwereade__ | dimitern, sure, cheers | 14:30 |
| * rogpeppe is now trying for a clean run of all live tests | 14:30 | |
| dimitern | rogpeppe: with the API? | 14:30 |
| rogpeppe | dimitern: i'm not sure what you mean | 14:31 |
| dimitern | rogpeppe: was it not passing before? | 14:31 |
| rogpeppe | dimitern: it's been the reason the live tests haven't been passing for a month or so | 14:31 |
| dimitern | rogpeppe: whoa, I totally missed that :) good to hear they pass now | 14:32 |
| rogpeppe | dimitern: you should run the live tests some time :-) | 14:33 |
| dimitern | rogpeppe: yeah, with openstack I did, but never with ec2 | 14:34 |
| dimitern | niemeyer: ping | 14:36 |
| rogpeppe | fwereade__: dear mr on-call reviewer; here's a review for you :-) https://codereview.appspot.com/8318043 | 14:37 |
| fwereade__ | rogpeppe, cheers | 14:37 |
| rogpeppe | hey, we're on revision 12 | 14:37 |
| rogpeppe | in binary | 14:37 |
| rogpeppe | 1100 | 14:37 |
| dimitern | rogpeppe: not for long :) | 14:38 |
| rogpeppe | dimitern: 13 next | 14:38 |
| rogpeppe | dimitern: then NaN | 14:38 |
| dimitern | or NaB | 14:38 |
| rogpeppe | TheMue: ping | 14:43 |
| fwereade__ | rogpeppe, LGTM | 14:45 |
| rogpeppe | fwereade__: thanks | 14:45 |
| fwereade__ | rogpeppe, I think that's probably a trivial tbh, given that I infer you've run the live tests :) | 14:46 |
| rogpeppe | fwereade__: you looked at the juju home stuff in more detail than me, ISTR. perhaps you could suggest a solution to a related panic i'm seeing in the live tests. | 14:47 |
| fwereade__ | rogpeppe, blarg | 14:47 |
| fwereade__ | rogpeppe, paste it? | 14:47 |
| dimitern | niemeyer: when you see this, can you please remove the flag from the channel that doesn't allow topic changes? we discussed to start using it to convey information through it, like the on call reviewer, possibly bug counts, etc. | 14:47 |
| rogpeppe | fwereade__: http://paste.ubuntu.com/5673777/ | 14:48 |
| rogpeppe | fwereade__: i'm not sure when juju home is supposed to be initialized | 14:48 |
| fwereade__ | rogpeppe, before any test that needs to use it | 14:49 |
| fwereade__ | rogpeppe, and at the beginning of cmd/juju.Main | 14:49 |
| rogpeppe | fwereade__: i can't see how the live tests work at all then | 14:51 |
| rogpeppe | fwereade__: because AFAICS they don't initialise juju home | 14:51 |
| fwereade__ | rogpeppe, it is possible that they do not: I did not think to verify that in the review | 14:51 |
| rogpeppe | fwereade__: they do work, apart from that one test | 14:52 |
| rogpeppe | fwereade__: so there's something odd going on | 14:52 |
| rogpeppe | fwereade__: ah, i see! | 14:53 |
| rogpeppe | fwereade__: the authorized-key field doesn't look at JUJU_HOME | 14:53 |
| rogpeppe | fwereade__: right, i know how to fix it now | 14:54 |
| fwereade__ | rogpeppe, wait, ISTM that we're running a weird test with just the dummy provider mixed in among all the live tests | 14:54 |
| fwereade__ | rogpeppe, why are we creating a totally fresh config in a test that has a config available already? | 14:54 |
| rogpeppe | fwereade__: actually we're just leveraging the dummy provider there, not using it | 14:54 |
| rogpeppe | fwereade__: we use it to put the tools into, then fake 'em up into the actual environment | 14:55 |
| fwereade__ | rogpeppe, hmm, ok, I see | 14:55 |
| fwereade__ | rogpeppe, not sure I entirely approve but that's the least of my worries :) | 14:55 |
| fwereade__ | rogpeppe, anyway, thanks | 14:56 |
| rogpeppe | fwereade__: np | 14:56 |
| niemeyer | dimitern: I believe anyone can change the topic | 14:59 |
| niemeyer | dimitern: Via chanserv | 14:59 |
| dimitern | niemeyer: do you know how of hand, or I should try google? :) | 15:00 |
| niemeyer | dimitern: Hold on | 15:00 |
| niemeyer | dimitern: /msg chanserv topic #juju-dev I am a new topic. | 15:01 |
| niemeyer | dimitern: This is handy too, for future uses: /msg chanserv help | 15:01 |
| === ChanServ changed the topic of #juju-dev to: On call reviewer: fwereade | ||
| dimitern | niemeyer: cheers! | 15:02 |
| fwereade__ | need to think for a bit, going for a walk, be back later | 15:02 |
| === wedgwood is now known as wedgwood_away | ||
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: fwereade | Bugs: 3 Critical, 54 High - https://bugs.launchpad.net/juju-core/ | ||
| === wedgwood_away is now known as wedgwood | ||
| mattyw | anyone know what this means (juju-core bootstrap --upload-tools on aws) 2013/04/03 15:17:02 ERROR JUJU:jujud:bootstrap-state jujud bootstrap-state command failed: state entity tag not found in configuration | 15:20 |
| mgz | mattyw: see the "Cannot bootstrap instances in ec2" thread on the juju-dev list | 15:21 |
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: fwereade | Bugs: 2 Critical, 53 High - https://bugs.launchpad.net/juju-core/ | ||
| rogpeppe | fwereade__: another review for you (this one actually fixes the live tests) https://codereview.appspot.com/8321043 | 15:38 |
| dimitern | rogpeppe: the diff is screwed | 15:39 |
| rogpeppe | dimitern: thanks; will try again | 15:39 |
| rogpeppe | dimitern: PTAL | 15:40 |
| fwereade__ | rogpeppe, awesome, LGTM | 15:40 |
| rogpeppe | fwereade__: ta! | 15:41 |
| rogpeppe | dimitern: i'm not sure how to run the openstack live tests. | 15:42 |
| rogpeppe | dimitern: do i need an account on canonistack or something? | 15:43 |
| dimitern | rogpeppe: you need creds yeah, there's a wiki page about it, let me find it | 15:43 |
| rogpeppe | dimitern: i'll submit anyway if that's ok - it must be better than the old one, and it's not tickling anything provider-specific | 15:44 |
| dimitern | rogpeppe: well jujutest is used in both, but yeah, I agree it's good to land | 15:45 |
| dimitern | rogpeppe: if openstack live tests fail (which is not uncommon on canonistack) we'll fix them | 15:46 |
| rogpeppe | dimitern: yeah; but the logic we're actually testing here is all state-based. | 15:46 |
| dimitern | rogpeppe: https://wiki.canonical.com/InformationInfrastructure/IS/CanonicalOpenstack?action=show&redirect=CanoniStack | 15:46 |
| * rogpeppe looks for his 2-factor keyring | 15:48 | |
| * dimitern thinks provisioner tests are kinda crap - no testing is done for errors while starting a machine | 15:54 | |
| dimitern | does it sound sane to add some way to cause StartInstance to fail in the dummy provider for testing sake? | 15:56 |
| === flaviami_ is now known as flaviamissi_ | ||
| === flaviamissi_ is now known as flaviamissi | ||
| TheMue | so, time to leave. one final review for today: https://codereview.appspot.com/8322043 | 16:47 |
| TheMue | n8 all | 16:48 |
| rogpeppe | fwereade__: if you're around, another CL for your delight and delectation: https://codereview.appspot.com/8328043/ | 17:43 |
| dimitern | rogpeppe: I can take a look | 17:46 |
| dimitern | rogpeppe: meanwhile - https://codereview.appspot.com/8330043/ ? | 17:46 |
| === deryck is now known as deryck[lunch] | ||
| === wedgwood is now known as wedgwood_away | ||
| === deryck[lunch] is now known as deryck | ||
| === wedgwood_away is now known as wedgwood | ||
| === bac_ is now known as bac | ||
| thumper | morning | 20:05 |
| fwereade__ | thumper, heyhey | 20:07 |
| thumper | hi fwereade__ | 20:08 |
| fwereade__ | thumper, do you have any clue why upgrade-juju is using version.Current? | 20:08 |
| thumper | fwereade__: in which place? | 20:08 |
| fwereade__ | thumper, I think it just uses it once, in bumpedVersion | 20:08 |
| thumper | fwereade__: that is (IMO) used only for developers to force a new version | 20:09 |
| thumper | fwereade__: which I'd love to find a different way around | 20:09 |
| fwereade__ | thumper, sure, but I don;t think it's correct, is it? | 20:09 |
| thumper | um... | 20:09 |
| * thumper looks | 20:09 | |
| fwereade__ | thumper, the agent-version is relevant, and the version of the tools we *built* is relevant | 20:09 |
| fwereade__ | thumper, or at least the above two might be | 20:10 |
| fwereade__ | thumper, but I don;t see what the current client version has to do with it | 20:10 |
| thumper | fwereade__: I think the expectation there is that the client version will be equal or greater than any existing tools | 20:11 |
| fwereade__ | thumper, seems like a bit of an assumption to me, but I guess it's a derail anyway | 20:11 |
| thumper | fwereade__: yes, I agree that the whole method is wrong | 20:12 |
| thumper | fwereade__: could be easily fixed | 20:12 |
| === _mup__ is now known as _mup_ | ||
| * thumper does a few drive by boy-scout branches to feel like something is improving | 20:28 | |
| * fwereade__ heartily endorses thumper's behaviour | 20:51 | |
| fwereade__ | thumper, btw, do you know offhand what's a valid launchpad id? | 20:51 |
| thumper | fwereade__: where are you looking? | 20:52 |
| thumper | and id for what? | 20:52 |
| fwereade__ | thumper, I'm peering suspiciously at the charm.validUser regexp | 20:52 |
| fwereade__ | thumper, user id | 20:52 |
| fwereade__ | thumper, in charm/url.go | 20:53 |
| thumper | hmm... | 20:53 |
| thumper | I'd have to look it up | 20:53 |
| thumper | what is the regex? | 20:53 |
| fwereade__ | thumper, https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CDsQFjAB&url=https%3A%2F%2Fhelp.launchpad.net%2FYourAccount%2FNewAccount&ei=nZVcUcjSO8GS7AaHnIDwCA&usg=AFQjCNE_bzVarX3yyWj40q2JeFnCtuT-hw&sig2=UjM0ZR4vv8kZOCr3nVeAzQ&cad=rja | 20:53 |
| fwereade__ | er, not that, whatever it is | 20:53 |
| fwereade__ | thumper, regexp.MustCompile("^[a-z0-9][a-zA-Z0-9+.-]+$") | 20:54 |
| thumper | hmm.. not sure we can have capitals | 20:54 |
| thumper | A short unique name, beginning with a lower-case letter or number, and containing only letters, numbers, dots, hyphens, or plus signs. | 20:54 |
| thumper | so perhaps... | 20:55 |
| thumper | that regex matches what LP says | 20:55 |
| thumper | though I'm not sure that uppercase is valid there | 20:55 |
| fwereade__ | thumper, ok, excellent, I just couldn't find where it was specified | 20:55 |
| thumper | but I would have to read the LP source | 20:55 |
| fwereade__ | thumper, seems like it might be covered, so let's go with it | 20:56 |
| fwereade__ | thumper, they'll all come from LP anyway | 20:56 |
| fwereade__ | thumper, thanks | 20:56 |
| thumper | kk | 20:56 |
| * thumper goes to grap his boxing wraps to have something to do while the tests run | 21:00 | |
| * thumper rages a little | 22:15 | |
| bigjools | thumper: against a machine? | 22:20 |
| thumper | bigjools: against our shitty package dependency chains | 22:20 |
| thumper | and circular deps | 22:20 |
| thumper | especially in testing | 22:20 |
| bigjools | ruh roh | 22:20 |
| * thumper made another package | 22:22 | |
| thumper | hmm... | 22:26 |
| thumper | my refactoring got just a little out of hand... | 22:26 |
| * thumper stops refactoring | 22:26 | |
| thumper | davecheney: I have a branch that is more paletable with "precise" in it, has many of the fixes I wanted for removing version.Current without actually removing it yet | 22:27 |
| thumper | simple refactoring grew past 800 line diff, so I've stopped | 22:28 |
| thumper | tests all still pass \o/ | 22:28 |
| davecheney | thumper: SUBMIT!! | 22:28 |
| thumper | davecheney: well, proposing first :0 | 22:28 |
| davecheney | seriouslu, i'm blocked at the moment | 22:28 |
| davecheney | ok, i shall review in anger | 22:29 |
| fwereade__ | thumper, this might very *very* well with what I'm about to propose, I just realised I was about to start replacing version.Current with "precise" everywhere :) | 22:34 |
| thumper | fwereade__: wait... | 22:34 |
| thumper | review incoming | 22:35 |
| thumper | https://code.launchpad.net/~thumper/juju-core/mongo-driveby/+merge/156992 | 22:35 |
| thumper | other one coming... | 22:35 |
| thumper | davecheney: fwereade__: Rietveld: https://codereview.appspot.com/8348043 | 22:36 |
| davecheney | thumper: ta | 22:37 |
| * thumper goes to get gym kit on | 22:38 | |
| thumper | fwereade__: I hope this doesn't clash with what you've been doing | 22:42 |
| fwereade__ | thumper, nope, not at all so far, it *might* be a disturbingly perfect matchup | 22:43 |
| thumper | fwereade__: that that would be fortuitous | 22:45 |
| thumper | I'm about to head off to the gym shortly | 22:48 |
| thumper | hmm... I just spotted a copy and paste error | 22:50 |
| fwereade__ | thumper, you have a preliminary review | 22:56 |
| fwereade__ | thumper, lots of questions I'm afraid | 22:56 |
| thumper | :( | 22:56 |
| thumper | ok | 22:56 |
| fwereade__ | thumper, take heart, I'm +1 on the fundamentals, mostly just quibbling about the details, only really unsure in a couple of places | 22:57 |
| * thumper nods | 22:58 | |
| thumper | I'll look after the gym | 22:58 |
| === thumper is now known as thumper-gym | ||
| === wedgwood is now known as wedgwood_away | ||
| fwereade__ | thumper-gym, davecheney: PTAL at https://codereview.appspot.com/8352043 | 23:40 |
| fwereade__ | thumper-gym, davecheney, it's a minimal bootstrap --fake-tools; I have verified that I can use cross-series envs fine, so long as I fake up all required series at bootstrap time | 23:42 |
| fwereade__ | thumper-gym, davecheney: adding it to upgrade-juju is harder because I get distracted and want to fix things, so I think it's best left for now | 23:42 |
| fwereade__ | thumper-gym, davecheney: it's not a complete fix but it hopefully gives davecheney in particular a useful way forward | 23:43 |
| davecheney | fwereade__: tahnks | 23:45 |
| fwereade__ | davecheney, if you get a mo, please try it out, in case I've done something stupid | 23:45 |
| fwereade__ | davecheney, juju bootstrap --upload-tools --fake-series precise | 23:46 |
| fwereade__ | davecheney, I think covers your use case | 23:46 |
| fwereade__ | davecheney, you might want precise,quantal if you're on raring and need quantal charms | 23:46 |
| * fwereade__ -> bed | 23:47 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!