[02:05] niemeyer: thanks for the review [02:05] davecheney: np! [02:05] i have in the back of my mind the request to rename those packages [02:06] worker/agent/etc sound like good solutions, but I'd liek to give it a little more thought [02:06] maybe go for a walk and a sit before proposing anything [02:11] davecheney: "worker" seems the best option so far [02:12] davecheney: We already use agent nowadays with a different meaning [02:12] niemeyer: yeah, all the good options are taken [02:12] niemeyer: lbox has just started to panic on me [02:12] pls hold for the paste [02:13] http://paste.ubuntu.com/1074143/ [02:13] is this related to the issue you raised in the mailing list ? [02:15] davecheney: Can you please update it? [02:15] davecheney: It is related indeed [02:15] davecheney: I've backported it from tip to stable for now, though, so we can continue moving forward while Brad fixes it [02:19] niemeyer: will do [02:25] Alright, bed time here [06:57] davecheney, since you have been doing Provisioner lately, I was wondering whether you had wisdom to impart re handling of environ configs [06:57] fwereade_: possibly, what are you trying to do ? [06:58] davecheney, because I'm getting very uncomfortable with the usage of naked ConfigNodes [07:00] davecheney, I'm not *quite* sure yet what I'm aiming for -- I'm working on getting Initialize to set up the environment node [07:01] davecheney, and it seems to me that Initialize alone should be responsible for "name" and "type", which should otherwise be unsettable [07:03] fwereade_: i see your concern [07:04] for the moment we've solved it via contract, by saying the environs should refuse to update those keys [07:04] davecheney, yeah, I just can't really articulate it further in a useful way [07:04] once set [07:05] from my point of view, i'm happy with ConfigNode providing a very simple interface [07:05] but, i'm not the architect of this project :) [07:07] davecheney, ah, sorry, totally missed your important point -- what is it that enforces those non-changes? [07:08] a loose agreement inside the environ itself [07:08] backed entirely by a comment [07:08] davecheney, ok, gotcha [07:09] environs/ec2/ec2.go#SetConfig [07:09] davecheney, the trouble is that EnvironConfig is acessible to any numpty with a State ;) [07:09] i would be less concerned with people changeing the name of the environ than pinching the secrets which are stored in the same key [07:09] davecheney, sure, that too ;p [07:13] fwereade_: are you protecting against a back actor, or a well meaning, but misguided mistake ? [07:13] davecheney, well-meaning mistakes are my primary concern really [07:14] davecheney, I am just generally concerned that which-environ-to-use is a subtler problem than it may at first appear [07:14] davecheney, this is mainly on the client side [07:14] fwereade_: i concur [07:14] fwereade_: but I have a plan to un fuck it a bit [07:15] davecheney, I would like a clean way to express the stuff we need to do on first access to an env [07:15] i'm going to figure out, in cloudinit, what the real internal IP of machine/0 is, so we can write it into the state then and there [07:16] fwereade_: on a related note, how does jujutest come up with the dnsname for the first machine as i-3.example.com ? [07:16] davecheney, er, not sure I'm afraid [07:16] davecheney, continuing above I feel that it should be obvious and easy to use a juju.Conn in such a way that: [07:17] davecheney, on bootstrap, we use the environments.yaml config exclusively [07:18] davecheney, on subsequent operations, we push the missing keys from environments.yaml into state, and subsequently use only the config from state [07:18] fwereade_: gotta fly -- tonight is my night to help out at the bowls club [07:18] davecheney, np, have fun, take care :) [07:18] catch you on the other side [08:27] heya TheMue [08:32] fwereade_: Hi [08:34] fwereade_: Successfully get your branch in? ;) [08:41] TheMue, yeah, thanks :) [08:41] TheMue, hope the merge doesn't hurt too much :) [08:42] fwereade_: So far my new code is totally outside, it only uses state. So it should be no problem when merging it into my branch. [09:55] morning juju dev's [09:55] is anyone able to help me diagnose why one of the charms in launchpad is not accessible in the charm store? [10:01] jamespage, you know about http://jujucharms.com/tools/store-missing ? [10:01] james_w, no I did not - thanks [10:01] but unless you're asking about shelr.tv that's probably not going to be very useful [10:02] james_w, no - my query is with reference to the 'ubuntu' charm [10:02] ah [10:02] indeed, not very useful [10:03] I've no more ideas, sorry, I'll return you to waiting for a dev [10:09] Hey there! [10:26] Heya niemeyer [10:37] niemeyer, heyhey [10:54] hi niemeyer [10:55] jamespage, has a question about why ubuntu isn't in the charm store: http://jujucharms.com/tools/store-missing [11:06] james_w: In a meeting, will be with you on a sec [11:33] hey all. [11:33] Aram: Heya [11:51] james_w: Okay, so how can I help? [11:51] is anyone able to help me diagnose why one of the charms in launchpad is not accessible in the charm store? [11:51] james_w, no - my query is with reference to the 'ubuntu' charm [11:53] james_w: Which branch is that? [11:54] lp:charms/ubuntu [12:04] james_w: We've debugged this problem before, actually [12:04] james_w: Clint asked me about it back in May [12:04] james_w: This was the issue: https://pastebin.canonical.com/66332/ [12:04] hah [12:05] niemeyer, where did you find that output? [12:05] james_w: From Tom [12:05] it would be great to have it on http://jujucharms.com/tools/store-missing [12:05] james_w: This is supposed to be integrated in the charm-store proper [12:05] james_w: In the API [12:05] niemeyer, I suspect that's a bug in the bzr freshness check for package branches [12:05] james_w: So anyone can query it and put wherever [12:05] niemeyer, aside from fixing the bug you can disable that check [12:06] james_w: How do you mean? [12:07] niemeyer, I assume it's the MISSING line that is throwing it off? [12:08] james_w: It's the fact it's outputting an error, yeah [12:08] niemeyer, so anything on stderr causes the import to bail? [12:09] james_w: No, but this certainly does: [12:09] % bzr checkout --lightweight lp:~charmers/charms/precise/ubuntu/trunk [12:09] Most recent Ubuntu version: MISSING [12:09] Most recent Ubuntu version: MISSING [12:09] Most recent Ubuntu version: MISSING [12:09] james_w: Well, or maybe I'm lying [12:09] james_w: Let me check reality [12:11] james_w: The command is really failing [12:11] non-zero exit code? [12:12] james_w: No, I'm lying again, sorry.. I did something silly that resulted in echo $? == 1 [12:12] [niemeyer@gopher ~/trunk]% bzr revision-info [12:12] Most recent Ubuntu version: MISSING [12:12] Most recent Ubuntu version: MISSING [12:12] 2 clint@ubuntu.com-20120522222745-k46xvcynebiva0xd [12:12] [niemeyer@gopher ~/trunk]% echo $? [12:12] 0 [12:12] * niemeyer checks implementation [12:12] ok [12:13] james_w: It's getting the combined output [12:13] james_w: I'll fix that and invite Tom to redeploy [12:14] niemeyer, fix it to do what? [12:14] james_w: To get stdout [12:14] ok [12:14] we can also make the message go away [12:14] james_w: It's slightly worse for debugging [12:14] james_w: But I'd rather have it working instead ;-) [12:14] james_w: That's certainly a better option overall for bzr [12:15] james_w: Having every command spitting out an arbitrary number of irrelevant messages sounds bad [12:15] right, bzr shouldn't activate the check for that url [12:15] but we can also have the charm importer tell bzr to just never even bother thinking of doing the check [12:15] james_w: How do we do that? [12:15] I'm looking [12:15] james_w: Cheers [12:19] bazaar.conf: launchpad.packaging_verbosity = off [12:20] there may be a way to set it on the command-line, but I don't think so [12:27] and you can escalate https://bugs.launchpad.net/bzr/+bug/1020935 if you like [12:30] ah, https://bugs.launchpad.net/bzr/+bug/888615/comments/4 [12:30] that's presumably better than the config file [12:34] james_w: I'll probably just pick stdout [12:34] niemeyer, that harms debugging? [12:34] and let it complain [12:34] can you capture stderr and include it if the command fails or something so that you can have both? [12:35] james_w: It could, because interleaving stderr/stdout means errors are in context, but in practice this seems to have made more harm than good, so I'm happy to adapt to reality [12:35] yeah [12:35] I've always found doing both to be tricky, I wish more libraries allowed for getting at both individually and an interleaved stream [12:42] james_w: Yeah, it's seldomly done because one can't actually do it perfectly unless it's done at the kernel level due to buffering [12:43] james_w: The correct way to interleave is to use a single fd, and then the individual streams are gone [12:57] niemeyer, yeah, agreed it's not easy [12:57] I still want it though :-) [13:09] james_w: +1 :) [16:01] Lunch time [20:22] Quiet day