[07:41] fwereade: mornin' [08:04] Good morning, Go-ers. [08:25] TheMue: hey! [08:26] TheMue: i seem to have problems branching the new juju-core project... is there anything i should know? [08:26] wrtp: Ah, here he is. HAd a nice time with the Queen? [08:26] TheMue: she was lovely thanks. she sends fond regards. [08:27] wrtp: Oh, thank you. Send her my best wishes when you're next time in for a cup of tea. *lol* [08:27] % bzr branch lp:juju-core/trunk juju-core [08:27] bzr: ERROR: Permission denied: "Cannot create 'trunk'. Only Bazaar branches are allowed." [08:27] wtf? [08:28] wrtp: Did not tried it yet, just started and updated the VM. [08:28] wrtp: Will try now and see what I get. [08:28] TheMue: cool, thanks [08:33] wrtp: Simple solution, just remove /trunk. [08:33] TheMue: remove /trunk from where? [08:33] wrtp: It's bzr branch lp:juju-core <> [08:33] TheMue: ah. that's odd, because every other project uses /trunk... [08:34] wrtp: ;) [08:35] wrtp: Even with bzr? Trunk as a dir I know from svn. But e.g. not in Mercurial based projects. [08:35] TheMue: yeah. for example goamz and gozk [08:35] TheMue: ha ha. it doesn't work with cobzr! [08:37] wrtp: I'm using plain bzr and switch/rename directories [08:38] TheMue: yeah. tbh, i think it's perhaps an oversight that niemeyer's not using lp:juju-core/trunk [08:38] TheMue: hmm, he *is* using /trunk: https://code.launchpad.net/~gophers/juju-core/trunk [08:41] TheMue: hmm, this worked ok: bzr branch https://code.launchpad.net/~gophers/juju-core/trunk juju-core [08:41] TheMue: which is all i needed [08:42] wrtp: I think the command above leads to the same result. [08:42] wrtp: See "Get this branch:" on the web site. [08:42] TheMue: evidently it doesn't, because bzr branch lp:juju-core/trunk failed... [08:43] wrtp: There's written "bzr branch lp:juju-core" [08:43] wrtp: Nothing about a "/trunk". [08:44] TheMue: yeah, but that *should* be the same as bzr branch lp:juju-core/trunk [08:44] TheMue: which is what i've been using for all the other projects. [08:44] TheMue: (including juju itself) [08:44] (the python version) [08:45] wrtp: Maybe, here I'm not deep enough in the bazaar conventions. [08:46] TheMue: neither me :-) [08:46] wrtp: I even don't see a reason for appending trunk. [08:46] TheMue: it's just what gustavo told me to do ages ago... [08:46] wrtp: What would it be good for? [08:46] TheMue: all launchpad branches are of the form lp:project/branch [08:51] wrtp: OK, so the URI maybe may contain a branch but when no branch is defined the trunk is taken. [08:51] TheMue: yup [10:21] Oh, family forces me to a second breakfast on the veranda. Brb. [10:57] TheMue: i feel your pain :-) [11:16] wrtp: The pain starts when returning back to the computer. [11:24] morning. [11:28] Hi Aram [11:28] wrtp, bzr branch lp:juju-core [11:29] hazmat: why doesn't bzr branch lp:juju-core/trunk work like it does for other projects? [11:29] hazmat: seems a bit odd [11:29] Aram: hiya [11:32] wrtp, because there is no 'trunk' series defined [11:32] wrtp, it looks like gustavo named it 'juju' [11:33] which is odd [11:33] so instead of 'trunk' you have bzr branch lp:juju-core/juju [11:34] hazmat: i agree that's odd. it's also odd, given that, that this link works: https://code.launchpad.net/~gophers/juju-core/trunk [11:34] wrtp, right.. the actual branch is trunk (off the gophers group).. but the lp alias derives off the series [11:35] changing the name of the series would fix that [11:35] at https://launchpad.net/juju-core/juju [11:35] i'll wait to niemeyer is around though [11:35] hazmat: yeah, he usually has a good reason for this kind of thing [11:37] hazmat: 'juju-core juju series [...] The "trunk" series represents [...] ' [11:42] wrtp, i rather doubt there's a reason to it [11:42] well perhaps to hold the series as separate project containers [11:58] wrtp, the reason niemeyer rejected the proposals is so people could create new ones against the juju-core project [11:58] hazmat: i have no problem with that [11:58] https://www.windowsazure.com/en-us/manage/linux/ [11:59] wrtp, just noticed you had put an existing back into 'wip' [11:59] hazmat: oh, that was unintentional - i tried to do lbox propose -for lp:juju-core, but it found the old proposal [12:00] wrtp, no worries.. try the bzr merge --remember lp:juju-core thing first [12:00] hazmat: the WIP was so that i didn't make an actual proposal, but had the side effect, i see, of unrejecting it [12:00] hazmat: i'm branching from trunk then merging back into that, then proposing that [12:00] wrtp, lbox inspects the bzr info command to determine the submit/push branch [12:01] hazmat: which i hope should work [12:05] hazmat: new proposal https://codereview.appspot.com/6300060 (which is quite a nice number) [12:31] wrtp: First impression is good, but it's a deeper change and I've got to see where other parts of the still to port state code has to adopt those changes. [12:34] TheMue: submitted, i'm afraid. consensus has it that there shouldn't be a particular problem with it... [12:35] wrtp: Thought it's a proposal. [12:35] TheMue: it was proposed a week ago, and LGTM'd by gustavo [12:36] TheMue: see https://codereview.appspot.com/6247066/ [12:36] wrtp: OK, only wondered because you wrote "new proposal". [12:36] TheMue: it's only new because it had to be created anew for juju-core [12:36] wrtp: Ah, understand. [12:38] today is a national holiday here, I think I'll be around mostly, though. [12:52] Aram: seems fairly quiet today... [12:53] In Germany some of the federal states have public holiday too, we don't. So they drive into our towns to go shopping. ;) [12:54] yeah, when it's a public holiday it's terrible, everything is closed. [12:54] we have one single generic shop opened in a 2M people city. [12:54] and even that shop is not non stop. [12:55] back in Romania I had 3 non-stop shops on my street, heh. [13:00] btw, did you guys see the transit of venus yesterday? [13:03] Aram: No, too early, will look at it next time. *lol* [13:04] lol. [13:09] hazmat: does remove-unit ever terminate a machine? [13:09] wrtp, no [13:09] wrtp, the machine is still allocated, and can be used for new units [13:10] wrtp, its a big bogus atm though [13:10] because we don't isolate the units from the root fs [13:10] hazmat: i was thinking about dave cheney's problem with the provisioning agent. [13:10] so they'll have pre-existing state on them [13:10] hazmat: i see [13:10] terminate-machine will kill an unused machine [13:10] * hazmat checks for dave's email [13:11] hazmat: i'm wondering if it might be best if terminate-machine merely marks the machine as "terminated" and only the provisioning agent actually removes it from the state, once the machine has been really terminated. [13:11] hazmat: then there's no need to be able to list all machines in the environment, i *think*. [13:12] wrtp, it removes the machine state [13:12] hazmat: currently, yeah. [13:12] wrtp, the provisioning agent marks machine its creates in some fashion [13:12] so it can identify them [13:12] in ec2 it uses security groups [13:12] hazmat: that's true. [13:12] and then it deltas between state and provider instances [13:12] and removes those with the mark but no state [13:12] hazmat: i was wondering if it's actually necessary to be able to do that [13:12] * hazmat doesn't understand the question [13:13] wrtp, as opposed to synchronous rpc to the provisioning agent? [13:13] you can also mark the state as deleted and have the provisioning agent subscribe not just to children but also to contents.. [13:13] hazmat: i don't think the provisioning agent subscribes to children [13:14] the firewall component of the provisioning agent has some nested watches for exposed port management [13:14] hazmat: i think it subscribes to topology [13:14] wrtp, oh.. yeah.. right [13:14] same principle though, you could mark the deletion in the topology [13:14] wrtp, what's your alternative that your thinking about? [13:14] hazmat: yeah, that's what i'm suggesting [13:14] wrtp, yes you should go down that road [13:15] wrtp, see the stop protocol proposal.. as a background [13:15] hazmat: rather than simply deleting the machine from the topology and letting the provisioning agent do the delta. [13:15] hazmat: link? [13:16] http://bazaar.launchpad.net/~hazmat/juju/unit-stop/view/head:/source/drafts/stopping-units.rst [13:16] wrtp, it would be nice if go juju had some proposals... [13:17] ie. document architecture choices [13:17] this is one thing we were really good at during the beginning of juju dev [13:17] hazmat: i guess atm our proposals are all "do what py juju does" :-) [13:17] that we fell off at, it would be good to resurrect [13:17] wrtp, except when its not [13:17] hazmat: true. [13:18] pretty much everything different is undocumented [13:18] the zk interaction etc. [13:19] hazmat: that's true. i'd definitely like to see more docs on that. although in the code would be fine for me too. [13:20] wrtp, in the code sort of defeats the purpose of a proposal's intent, unless its extractable prose [13:20] api docs are not really architecture documentation [13:20] hazmat: isn't a "proposal" about something that might be, rather than something that is? [13:21] hazmat: BTW i like the intent of the stop proposal, but i'm of two minds. [13:21] wrtp, its prose documentation about the impl [13:21] and architecture [13:21] we did typically do it in advance, but the value is the historical as well [13:21] hazmat: as an operator i'd like to be able to do terminate-machine and have it just stop, not potentially hang waiting for buggy stop hooks to complete. [13:22] because niemeyer wanted to agree on architecture before impl for most bits as a coordination/go-slow point [13:22] wrtp, that's covered in the proposal [13:22] wrtp, the supervision tree is still in effect [13:22] it just gives a chance/notification and wait period for the buggy stop hook [13:23] as opposed to ruthless termination which precludes any form of child cleanup/activity [13:23] oh yeah, i see [13:23] * wrtp hates timeouts in general though :-) [13:23] although i know they're unavoidable in general [13:23] wrtp, your alternative suggestion is eagerly awaited ;-) [13:24] coffee break, bbiam [13:24] hazmat: just kill the machine. any system should be able to cope with that as a matter of course anyway... [13:26] wrtp, right.. that's what we do now [13:26] parent's kill children [13:26] hazmat: what's the parent of a machine node? [13:26] wrtp, the provisioning agent [13:26] the environment from a state perspective [13:26] but the point is that's problematic for a coordination system to not coordinate :-) [13:28] for example the switch to contained unit states in the service is something that should get documented as part of the zk tree layout docs we have. [13:28] hazmat: agreed. [13:29] i'd suggest bringing in juju/docs into the goport tree or into juju-core as a separate series [13:29] and updating it there [13:30] hazmat: good idea. [13:31] hazmat: i think that and the (as yet unused?) presence node stuff are the only major deviations so far [13:31] hazmat: but TheMue might know of more [13:32] wrtp, well pinger nodes for ephemeral nodes as well [13:32] wrtp, and the zk session expiration tomb behavior [13:32] hazmat: that's what i meant by "presence node stuff" [13:33] hazmat: is that a change visible in zk? [13:33] (the session expiration behaviour, that is) [13:33] wrtp, its an architecture detail thats worth documenting [13:33] considering it was given as one of the main reasons to port to go.. [13:33] that might be nice [13:34] we have lots of non zk state things documented [13:34] wrtp: Seen my nick. Where do I know more? [13:34] TheMue, pinger presence nodes [13:34] as something to be documented [13:34] TheMue: deviations of go juju state implementation from py juju state implementation [13:36] hazmat: some of this stuff could definitely do with some more documentation, but i feel that the session expiration behaviour, in particular, is an implementation detail that would read well in the code, but isn't inevitable from the architecture of the system. [13:37] hazmat, wrtp: Just took a look for orientation. I've never touched them, sorry. [13:37] hazmat: although some internal implementation overview docs might be good too, i guess. [13:38] hazmat: most of the stuff in docs/source/internals seems to be about higher-level and zk stuff, rather than how stuff is actually done in the python itself [13:41] hazmat: is there a place that i can see all the proposals like your stop proposal? (just the mailing list archive?) [13:43] wrtp, agreed and the session expiration handling is also a higher level detail [13:44] hazmat: i guess so [13:44] wrtp, their published as branches under code.launchpad.net/juju [13:44] hazmat: hmm, useful :-) [13:45] their isn't a good index of just the branches [13:45] that are docs [13:45] i've also got rest-api, security, environment-settings proposals extant there [13:46] hazmat: might be useful if the branches were named xxx-proposal [13:46] true [14:22] * Aram is using Go linear time regular expressions to validate PCRE regular expressions so that I can be sure they are also linear time. [14:22] this seems... weird. [14:40] the nodejs package manager is really quite nice [14:42] I heard the same about it as well. [14:43] IMO node.js is a terrible way of doing things, but I actually like the guys because they are bold enough to try something different. [14:43] people are afraid to try new things these days. [14:57] Aram: Not only these days. Leaving well known paths hurts many people. [14:58] yeah, I was using "these days" in a very loose sense, more likely "since the dawn of humanity" :). [14:59] Aram: OK, this timespan matches. [15:16] Aram: doesn't it depend very much on the input text? [15:20] Aram, agreed, client/server language unification is nice, but via callback hell.. ick.. [15:20] Aram, their tooling and underlying event reactor usage (libev) is quite nice though [15:53] wrtp: yes, depends on the input text, that's what I am using for the first Go regexp, to validate it before sending it to PCRE> [15:54] Anyone interested in a small proposal: https://codereview.appspot.com/6305067 ? [15:54] s/for/with/ [16:18] TheMue: LGTM [16:19] TheMue: although i don't seem to be getting proposal emails any more. [16:19] wrtp: Thx [16:19] TheMue: i saw my own reply, but not your original proposal [16:19] wrtp: Maybe due to the URI I used. [16:20] TheMue: which URI was that? [16:21] wrtp: First bzr push --remember lp:~themue/juju-core/go-state-relation-endpoint-verification and then lbox propose -cr -for lp:juju-core [16:21] wrtp: Both times I used juju-core. [16:22] TheMue: it should've worked, i think [16:22] wrtp: I would expect it too. [16:22] wrtp: Your proposal using juju popped up instead. [17:03] "launchpad.net/juju-core/juju/state" [17:03] what an ugly import [17:04] can we do better? [17:16] my bzr foo is lacking, why bzr branch lp:juju-core puts everything in juju-core as oposed to juju-core/juju as should be for the import paths to work? [17:16] * Aram is confused. [17:45] Aram: There's a mail by Gustavo on juju-dev about the naming. [17:46] I've seen it. still confused about bzr branch dehavior though [17:46] behavior [17:47] Aram: I'm coming more from svn and hg, so I'm sometime confused too. [17:47] likewise. === davechen1y is now known as davecheney