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