wrtpfwereade: mornin'07:41
TheMueGood morning, Go-ers.08:04
wrtpTheMue: hey!08:25
wrtpTheMue: i seem to have problems branching the new juju-core project... is there anything i should know?08:26
TheMuewrtp: Ah, here he is. HAd a nice time with the Queen?08:26
wrtpTheMue: she was lovely thanks. she sends fond regards.08:26
TheMuewrtp: Oh, thank you. Send her my best wishes when you're next time in for a cup of tea. *lol*08:27
wrtp% bzr branch lp:juju-core/trunk juju-core08:27
wrtpbzr: ERROR: Permission denied: "Cannot create 'trunk'. Only Bazaar branches are allowed."08:27
TheMuewrtp: Did not tried it yet, just started and updated the VM.08:28
TheMuewrtp: Will try now and see what I get.08:28
wrtpTheMue: cool, thanks08:28
TheMuewrtp: Simple solution, just remove /trunk.08:33
wrtpTheMue: remove /trunk from where?08:33
TheMuewrtp: It's bzr branch lp:juju-core <<your dir name>>08:33
wrtpTheMue: ah. that's odd, because every other project uses /trunk...08:33
TheMuewrtp: ;)08:34
TheMuewrtp: Even with bzr? Trunk as a dir I know from svn. But e.g. not in Mercurial based projects.08:35
wrtpTheMue: yeah. for example goamz and gozk08:35
wrtpTheMue: ha ha. it doesn't work with cobzr!08:35
TheMuewrtp: I'm using plain bzr and switch/rename directories08:37
wrtpTheMue: yeah. tbh, i think it's perhaps an oversight that niemeyer's not using lp:juju-core/trunk08:38
wrtpTheMue: hmm, he *is* using /trunk: https://code.launchpad.net/~gophers/juju-core/trunk08:38
wrtpTheMue: hmm, this worked ok: bzr  branch https://code.launchpad.net/~gophers/juju-core/trunk juju-core08:41
wrtpTheMue: which is all i needed08:41
TheMuewrtp: I think the command above leads to the same result.08:42
TheMuewrtp: See "Get this branch:" on the web site.08:42
wrtpTheMue: evidently it doesn't, because bzr branch lp:juju-core/trunk failed...08:42
TheMuewrtp: There's written "bzr branch lp:juju-core"08:43
TheMuewrtp: Nothing about a "/trunk".08:43
wrtpTheMue: yeah, but that *should* be the same as bzr branch lp:juju-core/trunk08:44
wrtpTheMue: which is what i've been using for all the other projects.08:44
wrtpTheMue: (including juju itself)08:44
wrtp(the python version)08:44
TheMuewrtp: Maybe, here I'm not deep enough in the bazaar conventions.08:45
wrtpTheMue: neither me :-)08:46
TheMuewrtp: I even don't see a reason for appending trunk.08:46
wrtpTheMue: it's just what gustavo told me to do ages ago...08:46
TheMuewrtp: What would it be good for?08:46
wrtpTheMue: all launchpad branches are of the form lp:project/branch08:46
TheMuewrtp: OK, so the URI maybe may contain a branch but when no branch is defined the trunk is taken.08:51
wrtpTheMue: yup08:51
TheMueOh, family forces me to a second breakfast on the veranda. Brb.10:21
wrtpTheMue: i feel your pain :-)10:57
TheMuewrtp: The pain starts when returning back to the computer.11:16
TheMueHi Aram11:28
hazmatwrtp, bzr branch lp:juju-core11:28
wrtphazmat: why doesn't bzr branch lp:juju-core/trunk work like it does for other projects?11:29
wrtphazmat: seems a bit odd11:29
wrtpAram: hiya11:29
hazmatwrtp, because there is no 'trunk' series defined11:32
hazmatwrtp, it looks like gustavo named it 'juju'11:32
hazmatwhich is odd11:33
hazmatso instead of 'trunk' you have bzr branch lp:juju-core/juju11:33
wrtphazmat: i agree that's odd. it's also odd, given that,  that this link works: https://code.launchpad.net/~gophers/juju-core/trunk11:34
hazmatwrtp, right.. the actual branch is trunk (off the gophers group).. but the lp alias derives off  the series11:34
hazmatchanging the name of the series would fix that11:35
hazmatat https://launchpad.net/juju-core/juju11:35
hazmati'll wait to niemeyer is around though11:35
wrtphazmat: yeah, he usually has a good reason for this kind of thing11:35
wrtphazmat: 'juju-core juju series [...] The "trunk" series represents [...] '11:37
hazmatwrtp, i rather doubt there's a reason to it11:42
hazmatwell perhaps to hold the series as separate project containers11:42
hazmatwrtp, the reason niemeyer rejected the proposals is so people could create new ones against the juju-core project11:58
wrtphazmat: i have no problem with that11:58
hazmatwrtp, just noticed you had put an existing back into 'wip'11:59
wrtphazmat: oh, that was unintentional - i tried to do lbox propose -for lp:juju-core, but it found the old proposal11:59
hazmatwrtp, no worries.. try the bzr merge --remember lp:juju-core thing first12:00
wrtphazmat: the WIP was so that i didn't make an actual proposal, but had the side effect, i see, of unrejecting it12:00
wrtphazmat: i'm branching from trunk then merging back into that, then proposing that12:00
hazmatwrtp, lbox inspects the bzr info command to determine the submit/push branch12:00
wrtphazmat: which i hope should work12:01
wrtphazmat: new proposal https://codereview.appspot.com/6300060 (which is quite a nice number)12:05
TheMuewrtp: 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:31
wrtpTheMue: submitted, i'm afraid. consensus has it that there shouldn't be a particular problem with it...12:34
TheMuewrtp: Thought it's a proposal.12:35
wrtpTheMue: it was proposed a week ago, and LGTM'd by gustavo12:35
wrtpTheMue: see https://codereview.appspot.com/6247066/12:36
TheMuewrtp: OK, only wondered because you wrote "new proposal".12:36
wrtpTheMue: it's only new because it had to be created anew for juju-core12:36
TheMuewrtp: Ah, understand.12:36
Aramtoday is a national holiday here, I think I'll be around mostly, though.12:38
wrtpAram: seems fairly quiet today...12:52
TheMueIn Germany some of the federal states have public holiday too, we don't. So they drive into our towns to go shopping. ;)12:53
Aramyeah, when it's a public holiday it's terrible, everything is closed.12:54
Aramwe have one single generic shop opened in a 2M people city.12:54
Aramand even that shop is not non stop.12:54
Aramback in Romania I had 3 non-stop shops on my street, heh.12:55
Arambtw, did you guys see the transit of venus yesterday?13:00
TheMueAram: No, too early, will look at it next time. *lol*13:03
wrtphazmat: does remove-unit ever terminate a machine?13:09
hazmatwrtp, no13:09
hazmatwrtp, the machine is still allocated, and can be used for new units13:09
hazmatwrtp, its a big bogus atm though13:10
hazmatbecause we don't isolate the units from the root fs13:10
wrtphazmat: i was thinking about dave cheney's problem with the provisioning agent.13:10
hazmatso they'll have pre-existing state on them13:10
wrtphazmat: i see13:10
hazmatterminate-machine will kill an unused machine13:10
* hazmat checks for dave's email13:10
wrtphazmat: 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
wrtphazmat: then there's no need to be able to list all machines in the environment, i *think*.13:11
hazmatwrtp, it removes the machine state13:12
wrtphazmat: currently, yeah.13:12
hazmatwrtp, the provisioning agent marks machine its creates in some fashion13:12
hazmatso it can identify them13:12
hazmatin ec2 it uses security groups13:12
wrtphazmat: that's true.13:12
hazmatand then it deltas between state and provider instances13:12
hazmatand removes those with the mark but no state13:12
wrtphazmat: i was wondering if it's actually necessary to be able to do that13:12
* hazmat doesn't understand the question13:12
hazmatwrtp, as opposed to synchronous rpc to the provisioning agent?13:13
hazmatyou can also mark the state as deleted and have the provisioning agent subscribe not just to children but  also to contents..13:13
wrtphazmat: i don't think the provisioning agent subscribes to children13:13
hazmatthe firewall component of the provisioning agent has some nested watches for exposed port management13:14
wrtphazmat: i think it subscribes to topology13:14
hazmatwrtp, oh.. yeah.. right13:14
hazmatsame principle though, you could mark the deletion in the topology13:14
hazmatwrtp, what's your alternative that your thinking about?13:14
wrtphazmat: yeah, that's what i'm suggesting13:14
hazmatwrtp, yes you should go down that road13:14
hazmatwrtp, see the stop protocol proposal.. as a background13:15
wrtphazmat: rather than simply deleting the machine from the topology and letting the provisioning agent do the delta.13:15
wrtphazmat: link?13:15
hazmatwrtp, it would be nice if go juju had some proposals...13:16
hazmatie. document architecture choices13:17
hazmatthis is one thing we were really good at during the beginning of juju dev13:17
wrtphazmat: i guess atm our proposals are all "do what py juju does" :-)13:17
hazmatthat we fell off at, it would be good to resurrect13:17
hazmatwrtp, except when its not13:17
wrtphazmat: true.13:17
hazmatpretty much everything different is undocumented13:18
hazmatthe zk interaction etc.13:18
wrtphazmat: that's true. i'd definitely like to see more docs on that. although in the code would be fine for me too.13:19
hazmatwrtp, in the code sort of defeats the purpose of a proposal's intent, unless its extractable prose13:20
hazmatapi docs are not really architecture documentation13:20
wrtphazmat: isn't a "proposal" about something that might be, rather than something that is?13:20
wrtphazmat: BTW i like the intent of the stop proposal, but i'm of two minds.13:21
hazmatwrtp, its prose documentation about the impl13:21
hazmatand architecture13:21
hazmatwe did typically do it in advance, but the value is the historical as well13:21
wrtphazmat: 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:21
hazmatbecause niemeyer wanted to agree on architecture before impl for most bits as a coordination/go-slow point13:22
hazmatwrtp, that's covered in the proposal13:22
hazmatwrtp, the supervision tree is still in effect13:22
hazmatit just gives a chance/notification and wait period for the buggy stop hook13:22
hazmatas opposed to ruthless termination which precludes any form of child cleanup/activity13:23
wrtpoh yeah, i see13:23
* wrtp hates timeouts in general though :-)13:23
wrtpalthough i know they're unavoidable in general13:23
hazmatwrtp, your alternative suggestion is eagerly awaited ;-)13:23
hazmatcoffee break, bbiam13:24
wrtphazmat: just kill the machine. any system should be able to cope with that as a matter of course anyway...13:24
hazmatwrtp, right.. that's what we do now13:26
hazmatparent's kill children13:26
wrtphazmat: what's the parent of a machine node?13:26
hazmatwrtp, the provisioning agent13:26
hazmatthe environment from a state perspective13:26
hazmatbut the point is that's problematic for a coordination system to not coordinate :-)13:26
hazmatfor 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
wrtphazmat: agreed.13:28
hazmati'd suggest bringing in juju/docs into the goport tree or into juju-core as a separate series13:29
hazmatand updating it there13:29
wrtphazmat: good idea.13:30
wrtphazmat: i think that and the (as yet unused?) presence node stuff are the only major deviations so far13:31
wrtphazmat: but TheMue might know of more13:31
hazmatwrtp, well pinger nodes for ephemeral nodes as well13:32
hazmatwrtp, and the zk session expiration tomb behavior13:32
wrtphazmat: that's what i meant by "presence node stuff"13:32
wrtphazmat: is that a change visible in zk?13:33
wrtp(the session expiration behaviour, that is)13:33
hazmatwrtp, its an architecture detail thats worth documenting13:33
hazmatconsidering it was given as one of the main reasons to port to go..13:33
hazmatthat might be nice13:33
hazmatwe have lots of non zk state things documented13:34
TheMuewrtp: Seen my nick. Where do I know more?13:34
hazmatTheMue, pinger presence nodes13:34
hazmatas something to be documented13:34
wrtpTheMue: deviations of go juju state implementation from py juju state implementation13:34
wrtphazmat: 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:36
TheMuehazmat, wrtp: Just took a look for orientation. I've never touched them, sorry.13:37
wrtphazmat: although some internal implementation overview docs might be good too, i guess.13:37
wrtphazmat: 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 itself13:38
wrtphazmat: is there a place that i can see all the proposals like your stop proposal? (just the mailing list archive?)13:41
hazmatwrtp, agreed and the session expiration handling is also a higher level detail13:43
wrtphazmat: i guess so13:44
hazmatwrtp, their published as branches under code.launchpad.net/juju13:44
wrtphazmat: hmm, useful :-)13:44
hazmattheir isn't a good index of just the branches13:45
hazmatthat are docs13:45
hazmati've also got rest-api, security, environment-settings proposals extant there13:45
wrtphazmat: might be useful if the branches were named xxx-proposal13:46
* 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
Aramthis seems... weird.14:22
hazmatthe nodejs package manager is really quite nice14:40
AramI heard the same about it as well.14:42
AramIMO 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
Arampeople are afraid to try new things these days.14:43
TheMueAram: Not only these days. Leaving well known paths hurts many people.14:57
Aramyeah, I was using "these days" in a very loose sense, more likely "since the dawn of humanity" :).14:58
TheMueAram: OK, this timespan matches.14:59
wrtpAram: doesn't it depend very much on the input text?15:16
hazmatAram, agreed, client/server language unification is nice, but via callback hell.. ick..15:20
hazmatAram, their tooling and underlying event reactor usage (libev) is quite nice though15:20
Aramwrtp: 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:53
TheMueAnyone interested in a small proposal: https://codereview.appspot.com/6305067 ?15:54
wrtpTheMue: LGTM16:18
wrtpTheMue: although i don't seem to be getting proposal emails any more.16:19
TheMuewrtp: Thx16:19
wrtpTheMue: i saw my own reply, but not your original proposal16:19
TheMuewrtp: Maybe due to the URI I used.16:19
wrtpTheMue: which URI was that?16:20
TheMuewrtp: First bzr push --remember lp:~themue/juju-core/go-state-relation-endpoint-verification and then lbox propose -cr -for lp:juju-core16:21
TheMuewrtp: Both times I used juju-core.16:21
wrtpTheMue: it should've worked, i think16:22
TheMuewrtp: I would expect it too.16:22
TheMuewrtp: Your proposal using juju popped up instead.16:22
Aramwhat an ugly import17:03
Aramcan we do better?17:04
Arammy 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:16
TheMueAram: There's a mail by Gustavo on juju-dev about the naming.17:45
AramI've seen it. still confused about bzr branch dehavior though17:46
TheMueAram: I'm coming more from svn and hg, so I'm sometime confused too.17:47
=== davechen1y is now known as davecheney

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