| wrtp | fwereade: mornin' | 07:41 |
|---|---|---|
| TheMue | Good morning, Go-ers. | 08:04 |
| wrtp | TheMue: hey! | 08:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:33 |
| TheMue | wrtp: ;) | 08:34 |
| 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:35 |
| TheMue | wrtp: I'm using plain bzr and switch/rename directories | 08:37 |
| 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:38 |
| 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:41 |
| 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:42 |
| TheMue | wrtp: There's written "bzr branch lp:juju-core" | 08:43 |
| TheMue | wrtp: Nothing about a "/trunk". | 08:43 |
| 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:44 |
| TheMue | wrtp: Maybe, here I'm not deep enough in the bazaar conventions. | 08:45 |
| 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:46 |
| 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 | 08:51 |
| TheMue | Oh, family forces me to a second breakfast on the veranda. Brb. | 10:21 |
| wrtp | TheMue: i feel your pain :-) | 10:57 |
| TheMue | wrtp: The pain starts when returning back to the computer. | 11:16 |
| Aram | morning. | 11:24 |
| TheMue | Hi Aram | 11:28 |
| hazmat | wrtp, bzr branch lp:juju-core | 11:28 |
| 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:29 |
| hazmat | wrtp, because there is no 'trunk' series defined | 11:32 |
| hazmat | wrtp, it looks like gustavo named it 'juju' | 11:32 |
| hazmat | which is odd | 11:33 |
| hazmat | so instead of 'trunk' you have bzr branch lp:juju-core/juju | 11:33 |
| 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:34 |
| 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:35 |
| wrtp | hazmat: 'juju-core juju series [...] The "trunk" series represents [...] ' | 11:37 |
| 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:42 |
| 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:58 |
| 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 | 11:59 |
| 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:00 |
| wrtp | hazmat: which i hope should work | 12:01 |
| wrtp | hazmat: new proposal https://codereview.appspot.com/6300060 (which is quite a nice number) | 12:05 |
| 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:31 |
| wrtp | TheMue: submitted, i'm afraid. consensus has it that there shouldn't be a particular problem with it... | 12:34 |
| TheMue | wrtp: Thought it's a proposal. | 12:35 |
| wrtp | TheMue: it was proposed a week ago, and LGTM'd by gustavo | 12:35 |
| 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:36 |
| Aram | today is a national holiday here, I think I'll be around mostly, though. | 12:38 |
| wrtp | Aram: seems fairly quiet today... | 12:52 |
| 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:53 |
| 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:54 |
| Aram | back in Romania I had 3 non-stop shops on my street, heh. | 12:55 |
| Aram | btw, did you guys see the transit of venus yesterday? | 13:00 |
| TheMue | Aram: No, too early, will look at it next time. *lol* | 13:03 |
| Aram | lol. | 13:04 |
| 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:09 |
| 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:10 | |
| 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:11 |
| 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:12 | |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| hazmat | pretty much everything different is undocumented | 13:18 |
| hazmat | the zk interaction etc. | 13:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:26 |
| 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:28 |
| 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:29 |
| wrtp | hazmat: good idea. | 13:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:36 |
| 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:37 |
| 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:38 |
| wrtp | hazmat: is there a place that i can see all the proposals like your stop proposal? (just the mailing list archive?) | 13:41 |
| hazmat | wrtp, agreed and the session expiration handling is also a higher level detail | 13:43 |
| 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:44 |
| 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:45 |
| wrtp | hazmat: might be useful if the branches were named xxx-proposal | 13:46 |
| hazmat | true | 13: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 | |
| Aram | this seems... weird. | 14:22 |
| hazmat | the nodejs package manager is really quite nice | 14:40 |
| Aram | I heard the same about it as well. | 14:42 |
| 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:43 |
| TheMue | Aram: Not only these days. Leaving well known paths hurts many people. | 14:57 |
| Aram | yeah, I was using "these days" in a very loose sense, more likely "since the dawn of humanity" :). | 14:58 |
| TheMue | Aram: OK, this timespan matches. | 14:59 |
| wrtp | Aram: doesn't it depend very much on the input text? | 15:16 |
| 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:20 |
| 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:53 |
| TheMue | Anyone interested in a small proposal: https://codereview.appspot.com/6305067 ? | 15:54 |
| Aram | s/for/with/ | 15:54 |
| wrtp | TheMue: LGTM | 16:18 |
| 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:19 |
| wrtp | TheMue: which URI was that? | 16:20 |
| 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:21 |
| 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. | 16:22 |
| Aram | "launchpad.net/juju-core/juju/state" | 17:03 |
| Aram | what an ugly import | 17:03 |
| Aram | can we do better? | 17:04 |
| 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:16 | |
| TheMue | Aram: There's a mail by Gustavo on juju-dev about the naming. | 17:45 |
| Aram | I've seen it. still confused about bzr branch dehavior though | 17:46 |
| Aram | behavior | 17:46 |
| TheMue | Aram: I'm coming more from svn and hg, so I'm sometime confused too. | 17:47 |
| Aram | likewise. | 17:47 |
| === davechen1y is now known as davecheney | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!