davecheneyfwereade: ping00:03
fwereadedavecheney, heyhey05:36
fwereadedavecheney, I'm not actually starting work for a little while but I wanted to check in05:36
fwereadedavecheney, ISTM that the ultra-short version of what's indicated by the load tests is "we need the internal api"05:38
fwereadedavecheney, but we should probably be investigating stuff like the presence pings too :/05:38
davecheneyfwereade: lemmie know when you are free for a chat with our vocal cords05:49
davecheneyfwereade: there are some details which aren't captured in your summary, but that is a good first order approximation05:49
davecheneyLooking for a review of https://code.launchpad.net/~dave-cheney/juju-core/120-upstart-add-limit-verb/+merge/161275 and https://code.launchpad.net/~dave-cheney/juju-core/119-fix-mongo-ulimits/+merge/16127605:58
* davecheney waves07:19
davecheneyfwereade: le ping07:27
fwereadedavecheney, la pong07:29
fwereadedavecheney, g+?07:29
fwereadeTheMue, rogpeppe1, heyhey07:29
rogpeppe1davecheney, fwereade, TheMue: yo!07:30
davecheneyfwereade: i'll pop upstairs07:30
TheMuedavecheney, fwereade, rogpeppe1: moin07:32
fwereade_wallyworld_, ping07:56
rogpeppe1davecheney: just out of interest, do you know how big allmachines.log ended up in your scale tests?09:00
davecheneyrogpeppe1: 40-50mb09:00
davecheneyyour changes really helped09:01
davecheneybut in r 1197 i think some debug logging leaked back in09:01
rogpeppe1davecheney: thanks. and that's after 8 hours or so?09:01
davecheneyrogpeppe1: yup09:01
davecheney1200 machines * 3 hook invocations each == not that much09:01
rogpeppe1davecheney: yeah09:01
fwereade_rogpeppe1, davecheney: another thing we could do is to stop logging *all* the hook output and just report what's juju-logged09:12
rogpeppe1fwereade_: actually, i think it's really very useful to see all the hook output09:12
fwereade_rogpeppe1, davecheney: possibly store it, and log it if there's an error, but discard on success09:12
rogpeppe1fwereade_: yeah, that could work09:12
davecheneyrogpeppe1: i like that09:13
davecheneywe don't need to see the hook output in real time09:13
davecheneywell, I don't09:13
davecheneymaybe the debug-log users do need it09:13
davecheneymaybe we need some feedback from the charmers09:13
fwereade_davecheney, I can imagine there are some cases peole would expect it, yeah09:13
fwereade_davecheney, oh, for real log levels and dynamic switching between them...09:14
davecheneyfwereade_: please, don't mention the war09:14
fwereade_davecheney, I think it is a reasonably high priority, but yeah, it's not something I really want to think about *today*09:16
dimiternfwereade_, rogpeppe1: https://codereview.appspot.com/8540050 - PTAL09:54
dimiterndavecheney: looking09:56
davecheneyhttps://codereview.appspot.com/8540050#msg3 << bzzt09:56
dimiterndavecheney: what? they changed the not lgtm color to yellow?09:57
davecheneydimitern: the matcher is really stupid09:59
davecheneyyou can do10:00
davecheney'there is no way in hell I would consider giving this a LGTM'10:00
davecheneyand it will turn green10:00
dimitern:) yeah10:00
dimiterndavecheney: 2 LGTM s from me you have10:01
davecheneydimitern: thanks mate10:01
davecheneymaybe I should just hard code the values we need10:02
davecheneyrather than gold plating it10:02
dimiterndavecheney: it's good they're not hard coded I think - less cryptic imo10:02
davecheneydimitern: yeah, that is what I wanted, constant at the top, impl down the bottom10:03
davecheneyrogpeppe1: fwereade_ dimitern was any decision made on backporting fixes to 1.10.x ?10:06
davecheneyI have been keeping this page https://docs.google.com/a/canonical.com/document/d/1jIxqV-4c06GWIfCpB0pb8nS4frFhKY0k3WwXj5QdytQ/edit10:06
rogpeppe1davecheney: there are a few things that would be worth fixing in 1.10 i think10:06
fwereade_davecheney, excellent, I will start using that10:07
davecheneyrogpeppe1: would you add them to thise page10:07
rogpeppe1davecheney: will do10:07
davecheneyunless there is something that LP will do this for us10:07
rogpeppe1davecheney: what's the significance of 65000 BTW?10:07
davecheneyrogpeppe1: i cargo culted that from an issue that I found on the mongo support forum10:08
davecheneyprobably 40,000 would be enough10:08
rogpeppe1davecheney: you've got two more LGTMs (with minor comments on both)10:11
davecheneyrogpeppe1: ta10:12
rogpeppe1davecheney: you might want to include a link to the support issue so at least we know which cargo cult you subscribe to :-)10:12
davecheneyALL PRAISE GOOGLE10:13
davecheneyrogpeppe1: it's linked from the LP #10:13
rogpeppe1davecheney: i'd prefer it in the source, 'cos that's where the number has ended up10:13
davecheneyrogpeppe1: will do10:13
davecheneycan't be bothered doing LP shit tonight10:13
davecheneyit's late10:13
=== rogpeppe1 is now known as rogpeppe
fwereade__dimitern, reviewed10:45
dimiternfwereade__: cheers10:46
dimiternfwereade__: well, you're basically rewriting the whole thing with your suggestion10:47
dimiternfwereade__: if you know better, why didn't you do it yourself?10:48
fwereade__dimitern, it's not always clear what I know until I have something to contrast it to10:49
dimiternfwereade__: yeah, i understand, but i hope you understand my frustration as well..10:50
fwereade__dimitern, I do :(10:50
fwereade__dimitern, I *think* that what I suggested casts the code more neatly in terms of the problem it's solving, but I am actually open to arguments10:51
fwereade__dimitern, there may well be a case I'm missing that you handle10:51
dimiternfwereade__: what's not clear with my code, apart from having several flags? i tried to simplify it and comment various parts, so it's easier to follow10:52
fwereade__dimitern, it's just that I found it hard to keep track of them all, and there seemed to be more than the problem demanded10:54
dimiternfwereade__: hmm.. ok i'll use your suggested code10:54
fwereade__dimitern, it may be that all the complexity is essential, because I've missed at least one case, and I'm undecided whether or nt it's important10:55
fwereade__dimitern, can we have a G+ before we decide?10:55
dimiternfwereade__: ok, i'll start one10:55
fwereade__dimitern, sorry just started it10:55
wallyworld_fwereade__: i was at soccer earlier, i can ping you after our standup if you like11:33
wallyworld_jam: dimitern: standup?11:35
wallyworld_fwereade__: standup finished if you are around11:51
fwereade__wallyworld_, sgtm, would you start one?11:51
fwereade__wallyworld_, I just posted sketchy incomplete comments on https://codereview.appspot.com/8816045/, they will be relevant, but they representa WIP not final thoughts and are inelegant11:54
dimiternfwereade__: did the changes and all tests still pass :) - https://codereview.appspot.com/854005012:06
fwereade__dimitern, sweet12:20
fwereade__dimitern, sorry, got to pick up laura now though12:21
dimiternfwereade__: np, when you can12:23
* dimitern lunch12:23
davecheneyRoger Peppe (Juju Core Development, CDO) Roger has been doing great work supporting the Go-Juju port from its inception, and his recent work with the GUI team to implement all of the APIs they needed to port from Python to Go showed diligence, responsiveness, and is a great example of cross-team collaboration.12:27
davecheney^ good work rogpeppe12:27
rogpeppedavecheney: thanks. that was a total surprise!12:27
davecheneyyou deserve it12:27
rogpeppedavecheney: ta!12:28
TheMuerogpeppe: +1 from me too, have been happy to read it.12:36
TheMuerogpeppe: btw, these thoughts match to yours about logging and error messages: http://joearms.github.io/2013/04/28/Fail-fast-noisely-and-politely.html12:55
* rogpeppe is back from lunch13:03
rogpeppeTheMue: thanks13:03
mattywrogpeppe, also +1 from me, the api is very easy to work with13:05
rogpeppemattyw: glad to hear it!13:05
dimiternhey guys, fwereade just texted me his internet connection is down currently13:55
mramm2that sucks13:56
mramm2my internet was down last week13:56
mramm2has had no internet in forever13:56
mramm2we are having bad internet luck recently13:56
dimiternmramm2: mine is fine, but both my mic and my camera are playing tricks13:56
dimiternmramm2: so i'll just listen and type13:56
mramm2sounds like it will be a small meeting13:58
mramm2rogpeppe: your internet working yet?13:58
rogpeppemramm2: nope13:58
rogpeppemramm2: i have a possible fix date though13:59
rogpeppemramm2: about 30 hours from now13:59
=== wedgwood_away is now known as wedgwood
mramm2perhaps we should just do the meeting here on IRC13:59
mramm2or skip it for this morning13:59
dimiternmramm2: +1 for both options14:00
mramm2what are folks working?14:01
mramm2I see frank is working on status output.14:02
rogpeppemramm2: i can do G+ through my phone and the expected ghost-like appearance...14:02
dimiternlet's do it here14:02
mramm2yea, but dimitern is not able to G+ and fwreede has no internet, so it would be a small contingent14:02
TheMuemramm2: i moved it just back, because i've got only today and tomorrow. i'm working on the blueprints.14:02
mramm2TheMue: thanks14:03
mramm2so that is the other thing, I'll be contacting you individually but I added your names to some blueprints on the eplic backlog14:03
dimiternmramm2: i'm still on upgrade-charm --switch - will appreciate a review from rogpeppe; had a g+ earlier with william and fixed some things, simplified the  code14:04
mramm2(true for all of you) and will need your help to fill them in with what we know on the subject already14:04
rogpeppedimitern: ah, will review14:04
mramm2dimitern: nice14:04
mramm2rogpeppe: thanks14:04
dimitern(i think that was when g+ broke for me - gtalk plugin crashed and lost sound after restarting)14:04
TheMuemramm2: yes, i've seen mine and i'm pretty fine with them (only right now no clue about the ssh provider)14:05
rogpeppei'm about to propose godeps into juju-utils, which should give us the ability to at least do *something* with our dependency management problems14:05
rogpeppeor actually juju-utils is not the right place14:05
rogpeppeprobably launchpad.net/godeps14:05
mramm2TheMue: that is just a provider that requires that you give ssh keys to an existing machine14:05
mramm2which it will log into and take over14:06
TheMuerogpeppe: if it is multi-purpose for any go-project then lp/godeps14:06
rogpeppeTheMue: it is14:06
mramm2rogpeppe: TheMue: agreed14:06
dimiternrogpeppe: what's godeps?14:06
TheMuemramm2: aha, ook, thx14:07
rogpeppedimitern: here's the usage information for it: http://paste.ubuntu.com/5616028/14:07
dimiternrogpeppe: so this is basically gofix for imports?14:08
rogpeppedimitern: no. it doesn't touch source code.14:08
rogpeppedimitern: the idea is that when releasing you'd do (in juju-core) godeps > juju.deps14:08
dimiternrogpeppe: ah, like pip freeze, nice!14:08
rogpeppedimitern: then when you want to build the release, you'd do: godeps -u juju.deps14:08
rogpeppedimitern: which would update all the dependencies to the expected versions14:09
rogpeppedimitern: i think we discussed something similar in atlanta14:09
dimiternrogpeppe: yeah, and i thought hazmat and mgz did some python tool, but never heard what happened next14:10
rogpeppedimitern: i don't know either.14:10
* TheMue is happy about it. so far I helped myself with a simple little script that wonderful fails if new dependencies are added.14:11
hazmatdimitern, rogpeppe  its very minimal, basically reads a frozen description and updates the tree to it lp:goreq14:11
rogpeppehazmat: how do you get the description?14:12
dimiternhazmat: ah, thanks - will take a look14:12
hazmatrogpeppe, text file, import name space rev per line14:12
rogpeppehazmat: so you'd manually do that?14:13
hazmatrogpeppe, at the moment yes, but you could also generate a freeze14:13
hazmatrogpeppe, ideally you could just spec a date,14:13
hazmatand have tree updated to revs from the date14:14
mgzyou really want it manual14:14
rogpeppehazmat: i'm imagining that we'll bake the rev file into the tree14:14
rogpeppemgz: how so?14:15
mgzwell, some little tool to bump everything and run tests doesn't hurt14:15
hazmatthere's a nicer version of the src tree management in the juju-deployer work, that i want to copy over to goreq or setup as a common dep14:15
mgzbut the point is you want specific revs of the deps versioned in the main project14:15
mramm2yea, requirements.txt is the part of pip that is critical, but pip freeze is *very* nice14:16
rogpeppemgz: i agree14:16
rogpeppemgz: is there a problem with the semantics of the command i outlined above?14:16
mgzI don't completely understand it from that --help, but in short update is hard to do correctly (that shouldn't stop us making a start on this)14:18
rogpeppemgz: why is it hard?14:19
rogpeppemgz: i haven't done it yet, but i'm assuming it's as simple as "check it's clean; bzr update -r revno (or similar for other vcs's)"14:19
mgzwhat does the tool do when I have a different branch checked out in bzr, or a different head in git, or am on a different branch in hg14:20
mgzyou need a vcs specific bits of sanity code14:20
rogpeppemgz: presumably the vcs will error that the particular revision id is not available14:21
mgzthis is mostly a problem where it's trying to do all the deps in one go, you'll generally expect someone to be able to resolve an issue in the branch that's cwd14:21
rogpeppemgz: i was not planning on using revision numbers BTW (except as extra info in the file for user consumption only)14:22
rogpeppemgz: i still don't quite see the issue, i'm afraid14:22
mgzjust knowing the working tree is clean isn't enough14:24
rogpeppemgz: i was planning on doing a cleanliness check in all the deps too14:25
rogpeppemgz: and making sure that they're all updated to the versions as specified in the deps file14:25
mgzit's possible to say, update my feature branch of goose to a new trunk rev, but it's impoilite as it changes the meaning of the branch, and makes it annoying to get back my work14:26
mgzthe point is "cleanliness check" is hard, and hard in different ways for the different vcses14:26
rogpeppemgz: ah. i thought there was an equivalence of "bzr status" for all of them14:27
rogpeppemgz: git certainly has one. and hg too.14:27
mgzthere is, but that only tells you about the working tree state, not about the branch14:28
rogpeppemgz: i take your point about changing the feature branch to something else14:28
rogpeppemgz: i think that's unavoidable unless we want to make a new copy of everything14:28
rogpeppemgz: which is one possible approach14:29
rogpeppemgz: another is: godeps > /tmp/old; godeps -u something.deps; go build; godeps -u /tmp/old14:29
rogpeppemgz: i.e. it makes it easy to save your current state and revert to it14:30
mgzso, a script runnable by devs is reasonable I think, but we also want the export thing (it's basically what my tarball construction did)14:32
rogpeppemgz: yes, the export thing is orthogonal14:33
rogpeppemgz: and useful in any case14:33
rogpeppemgz: i don't think it has to be part of the same command14:34
mgzthere's nothing wrong with starting out dumb and improving it, there are just going to be some gotchas until it grows some vcs smarts14:34
mgzit should consume the same file14:34
rogpeppemgz: possibly. although it could just consume go source. it doesn't really need to know anything about vcs14:34
mgzit wants to know what revs of the deps need to go in the tar14:35
mgzthe deps file has that information14:35
rogpeppemgz: wouldn't this work ok? go deps -u v1.10.0.deps; goexport mypkg14:36
rogpeppemgz: i.e. it would just work with the go source as it finds it14:36
=== andreas__ is now known as ahasenack
mgzsure, so goexport is a thing?14:37
rogpeppemgz: it would still need to know about the dependency graph, but that's trivial with the go build package14:37
mgzthe point is that's hard to implement robustly14:37
rogpeppemgz: that's my provisional name for a non-hacky version of your script14:37
mgzwhereas it's easier to just export rather than update, then copy that14:38
mgzbecause update is not a clean operation14:38
rogpeppemgz: hmm, possibly.14:40
rogpeppemgz: i'd kinda prefer to isolate the vcs smarts to one place though14:41
ahasenackhi guys, is there an ETA for having this bug handled? https://bugs.launchpad.net/juju-core/+bug/112190714:53
_mup_Bug #1121907: deploy --config <cmdline> <juju-core:New> <https://launchpad.net/bugs/1121907>14:53
ahasenackthe option exists, but does nothing14:53
fwereadeahasenack, funnily enough that one just reached the top of my list14:58
ahasenackhm, in pyjuju, relation-list has the -r option:   -r RELATION ID15:02
ahasenackdoes relation-list in juju-core has something similar? I'm looking through the code and docs15:02
ahasenackor is it without the -r?15:02
fwereadeahasenack, it seems as though it accepts it as an (optional) arg, not a flag -- I have no recollection of how this decision came about15:12
ahasenackfwereade: you mean just foo.yaml, not --config foo.yaml?15:12
fwereadeahasenack, ah sorry I'm talking about relation-list15:13
ahasenackfwereade: yeah, I just hacked the charm I was testing to omit -r and it installed now15:13
ahasenackfwereade: but you will need to put -r back if you want to remain compatible with pyjuju15:13
ahasenackfwereade: https://bugs.launchpad.net/juju-core/+bug/117289515:13
_mup_Bug #1172895: relation-list incompatibility with pyjuju: -r <juju-core:New> <https://launchpad.net/bugs/1172895>15:13
fwereadeahasenack, quite so15:14
ahasenackinitially I thought it was something like a short-name and long-name option thing15:14
ahasenacklike -r vs --relation-id, and only the long one was supported15:14
fwereadeahasenack, consider that higher-priority than --config, because at least I can do that quickly and the code won't make me want to set fire to things ;p15:14
ahasenackdo you guys have a go syntax highlighting file for vim by any chance? Raring doesn't come with one it seems15:17
TheMueahasenack: it should be in the misc folder15:20
ahasenackI'm searching the packages I have installed, no luck so far15:21
ahasenackwill grab it from the code repo then15:21
TheMueahasenack: i'm just looking15:22
TheMueahasenack: but i have to admit i've installed go directly ;)15:22
TheMueahasenack: did you also install vim-syntax-go?15:24
ahasenackTheMue: oh, no, there you go15:24
ahasenackTheMue: apt-cache search "go" doesn't help much, that package should be called vim-syntax-golang15:25
ahasenackuh, it wants to install ruby15:25
* ahasenack --no-install-recommends15:25
TheMueahasenack: yes, would be better. the emacs file is named golang-mode, the kate file kate-syntax-go *hmpf*15:26
ahasenackthat package doesn't seem to work...15:28
ahasenackthe vim one15:28
ahasenackgoing back to the one from the source, that worked15:29
ahasenackhttp://go-lang.cat-v.org/text-editors/vim/ with these instructions15:29
=== hatch is now known as eric_f
=== eric_f is now known as hatch
fwereadehttps://codereview.appspot.com/9015043 if anyone's interested15:40
* dimitern nags: https://codereview.appspot.com/8540050/15:40
* fwereade apologises to dimitern, just a couple of last points, just sent15:45
rogpeppedimitern, fwereade: i'm having difficulty persuading myself that this line is correct: if *newURL == *oldURL && !explicitRevision {15:48
fwereaderogpeppe, it's not15:49
rogpeppefwereade: good, it's not just me then15:49
fwereaderogpeppe, explicitRevision shouldn't come in at that point15:49
rogpeppefwereade: oh, interesting, i thought the other way round15:49
rogpeppefwereade: that the urls shouldn't come in at that point15:50
fwereaderogpeppe, I don't think explicitRevision matter except when choosing whether to bump -- because bumping when a specific rev is already specified is clearly insane15:50
rogpeppefwereade: because i think i've persuaded myself that it may be useful to bump the revision even when the new url is different15:50
fwereaderogpeppe, whereas that whole block is all about what happens if it seems there's actually nothing to upgrade to15:50
rogpeppefwereade: "bumping when a specific rev is already specified is clearly insane" - isn't that what the explicitRevision check is checking for?15:51
fwereaderogpeppe, yes, it's meant to stop that happening, in my mind15:51
rogpeppefwereade: yeah. so we need explicitRevision in that test, no?15:52
fwereaderogpeppe, definitely not15:52
fwereaderogpeppe, what about a service running the latest charm from the charm store? *oldURL == *newURL15:52
fwereaderogpeppe, so we want to get in there and hit "already running latest charm"15:52
rogpeppefwereade: hmm, yes, good point15:53
rogpeppefwereade: but the case i'm thinking of is something like this:15:53
rogpeppefwereade: we have a local copy of a charm, deploy it, push it to the charm store, switch to that, then make some changes to the local copy and switch back to that15:54
rogpeppefwereade: in that case, we want the version to be bumped, but the urls are different15:54
rogpeppefwereade: i'm wondering if the local charm test should be at the outer level15:55
fwereaderogpeppe, hmm15:55
rogpeppefwereade: so we always bump version if the charm is local15:56
dimiternrogpeppe: we bump when the target url will be the same as the source one, the repo is local and the charm is a dir15:57
fwereaderogpeppe, I'm pretty sure that causes unwanted behaviour when upgrading to s epcific version15:57
fwereaderogpeppe, hey, you have v33 and v34 in your repo15:57
fwereaderogpeppe, you asked for 33 so I changed it to 3415:57
fwereaderogpeppe, no need to thank me15:57
rogpeppefwereade: ah yes, we should bump version if the version isn't explicitly specified *and* it's local15:57
fwereaderogpeppe, I *think* so yes15:58
dimiternfwereade: that's exactly what this !explicitRevision case is there for15:58
fwereadedimitern, but it breaks the no-newer-version-in-charm-store case, doesn't it?15:58
rogpeppedimitern: see my thought experiment above:15:58
fwereaderogpeppe, dimitern: bumpVersion is crazy broken anyway though15:58
rogpeppefwereade: local charms are crazy broken :-)15:59
fwereaderogpeppe, dimitern: true15:59
dimiternfwereade, rogpeppe: i lean more and more towards having --bump-revision as explicit argument15:59
rogpeppedimitern: as it was originally15:59
rogpeppedimitern: yeah15:59
dimiternand leave all the trickery to user's consent15:59
rogpeppedimitern: i think i agree15:59
fwereadedimitern, rogpeppe: hmm15:59
rogpeppedimitern: don't be tricksy unless i specifically say so16:00
rogpeppethen at least the user is aware that there's subtle magic going on16:00
dimiternrogpeppe: exactly, even "dump" - if --bump-revision is specified, we *always* do it, if possible (local charm + dir)16:00
fwereaderogpeppe, dimitern, if I had to I think I'd come down on the side of --no-bump-revision16:00
rogpeppefwereade: that doesn't really help16:01
rogpeppefwereade: we'd need all the same heuristics we have now16:01
dimiternfwereade: yeah, don't see how this helps16:01
rogpeppefwereade: the nice thing about --bump-revision is that we can ditch all of 'em16:01
fwereaderogpeppe, dimitern: it solves the use case, which --bump-revision doesn't really16:01
rogpeppefwereade: depends if you think that the magic is really worth it16:02
dimiternfwereade: --bump-revision doesn't claim to solve anything - it's just an explicit request from the user16:02
fwereadedimitern, then it's a regression16:02
rogpeppefwereade: with --bump-revision, the model is very clear16:02
rogpeppefwereade: so less surprises to the user, i think16:03
dimiternyeah, my point exactly16:03
rogpeppefwereade: i agree that the user will have to type a bit more though16:03
rogpeppefwereade: but if they don't, they'll get an error message16:03
fwereaderogpeppe, dimitern: and it breaks compatibility, doesn't it?16:04
rogpeppefwereade: really? did py juju do auto bump?16:04
fwereaderogpeppe, yes16:04
fwereaderogpeppe, it's hugely popular16:04
rogpeppeaw shucks16:04
dimiternfwereade: in a good way - compatibility shouldn't be absolute if it forces us to twist things like that16:04
rogpeppeok then, we have to do it. but let's get it right at least. (whatever that means :-])16:04
dimiternfwereade: how can you tell that?16:05
fwereadedimitern, in a "we no longer solve a big and expensive problem for users" way, really16:05
fwereadedimitern, because they asked for it, and we gave it to them, and there was great rejoicing16:05
dimiternfwereade: the users are not as dumb as we think they are perhaps16:05
fwereadedimitern, because nobody spent 20 mins with N machines on the clock trying to figure out why their fixes didn't work any more16:05
dimiternfwereade: getting a meaningful error when you go wrong is helpful, not getting an error and subtly screwing up in hard to determine ways is, imho16:06
dimiternfwereade: so i'm asking again - do you want to take that one over and do it how you think it will be ok?16:07
fwereadedimitern, I'm not regressing this unless we can determine a better story for charmers than the one we have16:08
dimiternfwereade: i feel more and more out of my league here - doing things I'm not getting completely all the repercussions16:09
fwereadedimitern, the user expectation is that, when upgrading from a local repo, a new charm will be bundled with a new revision16:09
fwereadedimitern, I *think* that an explicit request for some other rev should probably override this though16:10
dimiternfwereade: how about --revision # or --switch=blah-# ?16:10
rogpeppefwereade: s/a new charm/the charm/ ?16:10
* fwereade knows the feeling16:10
dimiternfwereade: ok, so I think I covered that, didn't i?16:10
fwereadedimitern, those are I think explicit revisions, but you do the test in the wrong place16:10
rogpeppedimitern: i don't think your code covers this scenario:16:11
rogpeppe[16:54:14] <rogpeppe> fwereade: we have a local copy of a charm, deploy it, push it to the charm store, switch to that, then make some changes to the local copy and switch back to that16:11
dimiternfwereade: where should the test be then?16:11
fwereadedimitern, the whole `if *newURL != *oldURL` block is about eliminating situations that imply we can't bump16:11
dimiternfwereade: or bump it if needed16:12
fwereadedimitern, I'm just suggesting another check in that bails out with "already running that charm" if the rev is specified explicitly16:12
dimiternfwereade: actually it's exactly when to bump, by default we never bump16:12
dimiternfwereade: when? as a last check or first?16:13
* fwereade shrugs -- first maybe?16:13
dimiternfwereade: so basically would "bumpRevision = !explicitRevision" do that in the last block?16:13
fwereadedimitern, doing it first of all seems neater -- we can have an message tailored to its explicitness16:14
dimiternfwereade: ah, you want an error as well, ok so it looks to me it's likely to be the last check before setting bumpRevision to true16:14
rogpeppedimitern: bump-revision = charm is local and revision is not explicit16:14
rogpeppedimitern: ?16:15
fwereadedimitern, if we don't hit that, the existing "already running latest" bit makes more sense16:15
dimiternfwereade: if it's first, we won't handle the case when we cannot bump anyway - be it cs: url or a bundle16:15
fwereadedimitern, if it's first we give the best error message for the situation, I think16:15
dimiternfwereade: so "already running latest charm cs:blah-12" is a better error?16:16
fwereadedimitern, well "latest" is a problem if it's an explicit revision16:16
fwereadedimitern, it only becomes appropriate once we've eliminated the explicit case, at which point we can be sure the new url is the latest one16:16
dimiternfwereade: then (and i though that before as well) these 3 error cases should be different16:17
dimiternfwereade: having the same msg 3 times seems confusing16:17
fwereadedimitern, could very well be, it's always a good thing to improve the error reporting16:17
dimiternfwereade: how about "already running latest  charm X: - explanation" and the explanation will be different in each cas16:18
fwereadedimitern, "latest" doesn't always apply16:18
fwereadedimitern, "already running specified charm" and "already running latest charm" seem to cover reasonably well, but a 3rd "cannot bump revision of local charm bundle" might be reasonable16:19
dimiternfwereade: ok then "cannot upgrade to charm X: - [explicit revision matches latest|not a local repository|not a directory]" >16:20
fwereadedimitern, the "latest" and "explicit" cases are different16:20
fwereadedimitern, we never even check latest when there's an explicit revision16:20
dimiternfwereade: ok, agreed - but i still think the 2 cases for latest could be reported differently16:22
fwereadedimitern, "already running latest charm" is way more important then "not local" or "not dir" -- the local bumping is a special case that we only get out when we;ve eliminated reasons not to even try16:22
fwereadedimitern, I would be fine differentiating them16:22
rogpeppefwereade: those error messages sound good to me16:22
dimiternfwereade: ok, so with these changes it should be good to land then?16:22
fwereaderogpeppe, dimitern: the "charm X" is particularly a problem in a wanted-to-bump-revision context16:23
fwereaderogpeppe, dimitern: that's kinda a side effect of PutCharm's revision-changing16:23
dimiternfwereade: i'm not following you there i'm afraid16:24
rogpeppedimitern: +116:24
dimiternfwereade: you mean the wording or the logic?16:24
fwereaderogpeppe, dimitern: "cannot upgrade to charm X" when we wouldn't actually be upgrading to that revision16:24
fwereaderogpeppe, dimitern: I'm fine changing them but I would like them to be more accurate not less16:24
dimiternfwereade: totally agree on that16:25
fwereadedimitern, I think we're reasonably clear on the logic regardless16:26
rogpeppemgz: stupid question: what's the accepted way of creating the initial branch for a project?16:26
rogpeppemgz: i've created lp:godeps, but i've tried bzr push lp:godeps/trunk; bzr push lp:~rogpeppe/godeps/trunk; bzr branch lp:~rogpeppe/godeps/trunk and others16:27
fwereadedimitern, so with that fixed I'd gladly LGTM with maybe a suggestion for different messages16:27
rogpeppeniemeyer: ^16:27
mgzyou push it to a n normal location, then set that as the trunk in launchpad16:28
mgzso, eg, lp:~juju/godeps/trunk or lp:~gophers/godeps/trunk or something16:29
mgzrogpeppe: ^16:29
rogpeppe% bzr push lp:~rogpeppe/godeps/trunk16:29
rogpeppebzr: ERROR: At lp:~rogpeppe/godeps/trunk you have a valid .bzr control directory, but not a branch or repository. This is an unsupported configuration. Please move the target directory out of the way and try again.16:29
rogpeppemgz: how do i move the target directory out of the way when it's on a remote system?16:29
mgzheh, what have you been doing...16:29
rogpeppemgz: i've no idea :-)16:30
dimiternfwereade, rogpeppe: ok, it's done, please take one last look (added a test for the case we discussed) - https://codereview.appspot.com/854005016:30
fwereadedimitern, on reflection I'd be fine with passing a local bundle into PutCharm with bumpRevision set and relying on the interior error handling16:30
* rogpeppe has never heard of sftp before16:30
* fwereade looks16:30
mgz...as in, as a thing, or as a mechanism for doing stuff with launchpad? :)16:31
rogpeppemgz: both16:31
rogpeppemgz: i presume the interface is similar to good ol' ftp16:31
mgzyup, just connect to bazaar.launchpad.net as your launchpad user name16:31
dimiternfwereade: let's not do that - it's better to be explicit and report a better error i think16:32
mgzlaunchpad provides a pretty locked down environment16:32
rogpeppemgz: http://paste.ubuntu.com/5616423/16:33
rogpeppemgz: is it not possible to see what's there?16:33
mgzyou just need to go to the right place16:34
rogpeppemgz: ah. which is?16:34
fwereadedimitern, "cannot increment revision of charm blah: not a directory seems pretty good to me actually"16:34
fwereadedimitern, s/directory/directory"/16:35
dimiternfwereade: that's only for the last error msg?16:35
fwereadedimitern, but, as you wish, LGTM16:35
fwereadedimitern, yeah16:35
mgzlooking to see if anyone has written up a guide...16:35
fwereadedimitern, just so we don't bother .(*charm.Dir)ing twice16:35
dimiternfwereade: ok, cheers, will do16:35
mgzrogpeppe: can't find one16:36
mgzrogpeppe: basically, `cd ~YOURUSERNAME/PROJECT/BRANCHNAME16:36
rogpeppemgz: is there really no other way to get lp's knickers out of this twist?16:36
mgzthen inspect the .bzr dir16:37
mgzonce you're in a location, you can poke around16:37
mgzthere's just no root filesystem16:37
fwereadedimitern, rogpeppe: if either of you have a moment for https://codereview.appspot.com/9015043 I would appreciate it16:37
rogpeppemgz: so "cd ~rogpeppe" doesn't work but "cd ~rogpeppe/godeps/trunk" does. wonderful.16:37
dimiternfwereade: i started looking at it, but got distracted - i'll take a look shortly16:38
rogpeppemgz: any way of doing an rm -r ?16:38
rogpeppemgz: other than manually recursing16:38
rogpeppemgz: 's'ok - it's done16:39
mgzyou can use bang16:39
rogpeppemgz: as in rm! ?16:40
mgzhm, no, but there is some mv mechanism16:40
rogpeppeha, better and better16:41
mgzyou can also just delete the branch via the launchpad website if you don't care *why* it went wrong, generally16:41
rogpeppe%  bzr push --use-existing-dir lp:~rogpeppe/godeps/trunk16:41
rogpeppebzr: ERROR: Server sent an unexpected error: ('error', 'xmlrpclib.Fault', "<Fault -1: 'OOPS-5682d217c06be19eecf72b1b1b0eb6a4'>")16:41
rogpeppemgz: hmm, i'll try that16:42
rogpeppemgz: i seem to be digging deeper and deeper here when i just wanna push a branch16:43
* fwereade sighs at the --config bug with mild despair16:43
fwereadeok, I'll be back much later to talk to wallyworld_, but I'm off for now16:44
rogpeppemgz: success, finally.16:46
rogpeppemgz: note to self: always create branch *before* creating project.16:47
mgzrogpeppe: that oops:16:51
mgz17:50 < wgrant> mgz: Looks like random long response times16:51
mgz17:50 < wgrant> Possible network/machine glitch.16:51
mgz17:50 < wgrant> eg. a SELECT * FROM Person WHERE id = foo; took 7s...16:51
rogpeppemgz: hmm.16:51
rogpeppemgz: it left me with the same situation i had before (.bzr dir but no branch)16:51
mgz...what are you doing.... you have a local branch with committed changes as cwd, right?16:53
mgzany other oddness like cobzr involved?16:53
mgzlooks like a valid branch with zero revisions to me16:54
mgzcommit a readme or something16:54
rogpeppemgz: no i was trying to push an initial branch with no commits16:56
rogpeppemgz: which i now find is not possible16:56
mgzwell, it's possible but not useful16:56
rogpeppemgz: you can't diff against it16:57
mgzalso makes certain things uselsss16:57
mgzright, can't merge or diff with it16:57
rogpeppemgz: i want the initial codereview CL to be everything i initially add16:57
rogpeppemgz: why is no commits a special case?16:57
rogpeppemgz: i guess i can commit --force16:57
mgzor you can just commit a readme16:58
rogpeppemgz: or add an empty file or something16:58
mgzor a license, which you need to host on launchpad anyway16:58
rogpeppemgz: i've already selected a licence16:58
rogpeppemgz: but perhaps i need it in the repo too16:58
* rogpeppe could get quite frustrated16:59
mgzyou can also do a cl with whatever16:59
* rogpeppe has reached end of day and has to go and build more raised vegetable beds.17:04
mgzbed well.17:04
rogpeppemgz: will do. if you want to have a look at this, it needs more tests and more code, but this is the biggest part, i think: https://codereview.appspot.com/901604317:05
rogpeppemgz: ta17:06
rogpeppeg'night all17:06
andrewsmedinaniemeyer: hi17:18
niemeyerandrewsmedina: Heya17:18
andrewsmedinaniemeyer: congrats for the pure go goyaml version :)17:19
niemeyerandrewsmedina: Just saw your mail, thanks for the tests there, and glad everything is working fine17:19
andrewsmedinaniemeyer: it works fine on go 1.1, but it brokens on go 1.017:19
andrewsmedinaniemeyer: https://drone.io/github.com/globocom/config/1 :(17:19
niemeyerandrewsmedina: Oho17:20
niemeyerandrewsmedina: Let me fix that right now, hold on17:20
andrewsmedinaniemeyer: thanks :)17:20
fssniemeyer: panic("unreachable") all the things17:21
niemeyerGood timing17:35
niemeyerandrewsmedina: Sorry, network was off right then17:35
niemeyerNow using the 3G backup17:35
niemeyerandrewsmedina: Fixes were pushed. Can you please pull and try again?17:36
=== deryck is now known as deryck[lunch]
andrewsmedinaniemeyer: it works!17:44
andrewsmedinaniemeyer: thank you!17:45
niemeyerandrewsmedina: Woohay!17:45
niemeyerandrewsmedina: np, thanks for the note17:45
andrewsmedinaniemeyer: what are the next steps? can I help you?17:47
niemeyerandrewsmedina: You're already helping in the most important way. There are lots of small things we could do, but the only critical thing right now is testing.17:49
niemeyerandrewsmedina: Everything else can be done in small increments over time17:49
=== deryck[lunch] is now known as deryck
=== _thumper_ is now known as thumper
=== robbiew is now known as robbiew-afk
=== wedgwood is now known as wedgwood_away

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