[01:14] m_3, in lxc its in /var/log/juju/ [01:14] we need to unify that, i pushed it there because really it should be there for both.. [01:14] bad examples becomes precedents :-( [05:56] https://bugs.launchpad.net/charm/+bug/891749 [05:56] <_mup_> Bug #891749: [charm-needed] ThinkUp < https://launchpad.net/bugs/891749 > [05:56] It appears we have no SMTP charm? [06:17] george_e: nothing yet no [06:17] george_e: should be a fun one to write.. :) [06:17] Would it be hard? [06:17] george_e: yes.. I don't think there are any smtp servers that don't have 100's of options [06:17] (...and would Postfix be a good choice?) [06:18] yeah since is the default in Ubuntu [06:18] Hmmm... well, it would definitely be a challenge. [06:28] Luckily debconf helps you in that case [06:42] Yeah. [08:17] hazmat, m_3 : I just renamed my charm (adding the hyphens back) and retried... it seems the fix is only switching the first hyphen: [08:17] 2011-11-22 08:14:18,542 unit:postgresql/7: hook.output ERROR: ERROR: syntax error at or near "-" [08:17] LINE 1: grant all privileges on database apache_django-wsgi to apach... [08:19] fwiw, there are a bunch of other errors being reported by the hook, but I've not checked if they're just fall-out: http://paste.ubuntu.com/745665/ [08:20] * hazmat yawns [08:21] noodles775, huh.. it looks like the bash replace only hit the first string occurence [08:22] Yep. [08:23] I've removed the hyphens from the charm name, so there's no rush... enjoy your normal morning :-) [08:27] <_mup_> Bug #893480 was filed: subordinate services need status support < https://launchpad.net/bugs/893480 > [08:28] crikey, hazmat, I presume you're still up rather than already up? [08:28] fwereade, aborted sleep attempt [08:29] heh, bad luck :( [08:29] hazmat: you give up to easily if you're jumping back on irc :P [08:30] noodles775, just rallying for another attempt ;-) [08:30] hazmat, quick opinion: UpstartService has .install, .start, .destroy [08:31] fwereade, +is_running, else sounds reasonable [08:31] i can't think of a scenario atm where we'd stop and not destroy [08:31] hazmat, appropriate to do everything via deferToThread(subprocess.[whatever_]call), even when there are more convenient ways to do it in python, so that I can always stick a sudo in there (so we get interactive password for local lxc-futzing) [08:31] ? [08:33] hazmat, there's an is_running too, but that one has no issues :) [08:33] fwereade, indeed we need defertothread to maintain the illusion of concurrency in twisted.. the local provider plays this game. and the sudo grab works through the defer to thread [08:33] fwereade, hazmat: mornin' [08:33] hazmat, I thought it was the subprocess functions? [08:33] heya rog [08:33] not often i see any chat at this hour... [08:33] hazmat, well, both, I guess [08:33] ie it does subprocess functions in a defer to thread.. see local/agent.py [08:34] rog g'morning [08:34] hazmat, indeed, that's what I'm suggesting, that we always use that approach [08:34] fwereade, sounds good [08:34] hazmat, it just gives me a little twinge to shell out to do an os.remove, needed confirmation that it's not totally insane :p [08:35] cheers [08:35] fwereade, not insane given the need for sudo in some cases [08:35] hazmat, good-o [08:36] understandable twinge.. but of what ? ;-) [08:40] hazmat, any reason not to use twisted process support? [08:41] therve, because its not needed since the signal problems with subprocess where fixed? [08:41] afaicr the only delta is some additional closing out of parent fds in the fork [08:42] which afacir the subprocess module does as well [08:42] therve, short answer.. less twisted, more python [08:43] ok. deferToThread makes me cry a little, that's all :) [08:43] therve, longer answer we started with spawnprocess for most of our subprocess usage, but it turns one line calls into whole pages of code. [08:43] hum, weird [08:44] we could abstract our process protocol for this to make it easier, but else we where doing a separate one per interaction [08:47] therve, re crying is it just the use of a separate thread that concerns, or the whole approach of a pipe writer back into the reactor? [08:48] hazmat, yeah using a thread, also if stock process support was easier, you wouldn't even think about it. [08:49] getProcessOutputAndValue generally works OK, but I don't know the particular problems here. [08:49] therve, oh.. i don't think i knew about that one [08:49] * hazmat wonders if it works with a sudo console grab [08:50] I guess you need a tty for sudo [08:50] ah.. its in utils [08:50] so maybe not :) [08:52] therve, it's the tty, I had had it just using getProcessOutput and I was happy :) [10:00] hazmat: btw, ${VAR/-/_} swaps first instance, ${VAR//-/_} swaps _all_ instances [10:09] noodles775: that change is pushed [10:11] Thanks m_3 [10:15] noodles775: are the other hook errors (http://paste.ubuntu.com/745665/) there even when you used a name w/o '-'s? [10:16] m_3: yes, they are - although the database connection works. Let me paste the current log. [10:16] hmmmm [10:17] m_3: here's the current log (without the '-' errors): http://paste.ubuntu.com/745749/ , but as above, it seems to be working fine. [10:19] I'm guessing those're just psql warnings on stderr... lemme see if I can reproduce [10:22] noodles775: btw, are you good with the pg-v9 builtin replication scheme? or were you using one of the other pre-9 options? [10:22] * noodles775 hasn't specified any options. I'm just deploying then relating postgresql:db to my app server. [10:25] ok, there's no repl in the current charm. I was going to add in the builtin repl now that we're on 9... just checking what would be most useful for you atm [10:30] m_3: ah, atm I'm just doing a proof-of-concept charm. But thanks for the thought! [11:57] anyone who's around... is there any continuing benefit to using pidfiles, if we're using upstart to manage everything anyway? [12:02] fwereade: not a question i can easily answer, i'm afraid [12:03] rog, not to worry, I needn't touch them really; they won't do any harm :) [14:11] hazmat: Did you notice https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-juju-roadmap isn't yet drafted? === wrtp is now known as rog [14:15] Daviey, we're still learning the ropes of blueprints as regards the dev process.. we've got a few other blueprints for the individual items in that set, the only actionable thing related to the roadmap is to just publish the roadmap [14:15] hazmat: oh groovy.. have you seen the How To? [14:16] (the syntax is parsed by http://status.ubuntu.com to track progress through the cycle) [14:16] Daviey, i haven't.. i've seen the status tracker, but not so much a how to on the blueprint process as regards the distro usage [14:17] ah.. there's a link there of course [14:17] Daviey, thanks [14:18] https://wiki.ubuntu.com/WorkItemsHowto [14:18] superb [14:22] fwereade, no benefit to pid files with upstart [14:25] Daviey, wrt to pre install on machines, if we do it client side, its pretty straightforward however the user will need to match numbers against the available machines.. which seems a little suspect vs just plugging in and selecting the juju orchestra when setting up the machine.. i'm game for it either way [14:26] hazmat: I wonder if 'both' makes sense? [14:29] Daviey, possibly.. standby to juju means powered on, and ready to deploy units to, ie latency on the order of seconds instead of minutes, which would deliver the most benefit, the pre install is bit more helpful without the standby allocation but its useful in either case to cut the allocation time. [14:30] i could see a scenario where trying to allocate 10 machines in response to load suddenly hammers the network with the image transfer [14:31] which pre-install would avoid [14:58] doh [15:09] we've got some things marked new-charm that need looking into [15:09] https://bugs.launchpad.net/charm/+bug/886362 [15:09] <_mup_> Bug #886362: New charm proposal: txstatsd < https://launchpad.net/bugs/886362 > [15:10] https://bugs.launchpad.net/charm/+bug/886362 [15:10] <_mup_> Bug #886362: New charm proposal: txstatsd < https://launchpad.net/bugs/886362 > [15:10] https://bugs.launchpad.net/charm/+bug/886365 [15:10] <_mup_> Bug #886365: New charm proposal: graphite < https://launchpad.net/bugs/886365 > [15:10] and https://bugs.launchpad.net/charm/+bug/891749 [15:10] <_mup_> Bug #891749: [charm-needed] ThinkUp < https://launchpad.net/bugs/891749 > [15:22] apparently william has a power cut [15:28] rog, ah.. good to know, thanks [15:44] rog: speaking of that, has your internet connectivity problem been solved? [15:45] mpl: i just got a message from my phone provider saying "your problem has been fixed". we will see - the phone line has been up and down all day. [15:47] it was fortunate you already knew how use your mobile phone as an alternative. it might have been painfull to figure it all out without connectivity. [15:47] *how to use [15:49] mpl: yeah, mobile hotspot functionality on android is a godsend [16:17] jimbaker, ping [16:25] marcoceppi, nice blog post [16:26] hazmat: thanks! [16:28] * rog always finds it hard to maintain momentum when suddenly... all tests pass. [16:29] do i take out the log messages for tidiness or add more tests and do that later? [16:39] hazmat, hi [16:45] * hazmat wonders why the charm browser isn't showing noodles775 noodle's django charm [16:47] noodles775, your missing a file in that charm [16:47] hazmat: Originally I just committed what I had and pushed where i could, so I may not have the correct layout. [16:47] noodles775, there's no metadata.yaml [16:47] at least not pushed, which means juju and the charm browser don't detect it as a charm [16:47] noodles775, ah [16:47] * hazmat checks the repo [16:48] Yeah, it's there: http://bazaar.launchpad.net/~michael.nelson/charm/oneiric/apache-django-wsgi/trunk/view/head:/oneiric/apache-django-wsgi/metadata.yaml [16:48] * noodles775 checks the charm instructions now. [16:48] noodles775, you've got two extraneous sub-directories there. [16:48] That would do it. [16:49] noodles775, neither oneiric or apache-django-wsgi should be in the actual branch, their implied by the repo name and location [16:49] k, I'll remove them and re-push. [16:51] noodles775, awesome, thanks [16:52] question: [16:54] is it safe to assume that the juju instance (regardless of if it's ec2) is the only thing running, and you won't have multiple things on the same server? [16:55] (example: having three redmine/phpbb instances on the same juju "guest") [17:00] jrgifford: the default is one unit per machine, you'd have to do something explicit to get other behavior and the hooks to do that are quite limited right now. In the future there will be more control over that. [17:00] jrgifford: we talk about that feature in terms of 'placement' [17:01] so, right now, i only need to think in terms of "there is *one* thing that can run on that guest/unit." [17:01] correct bcsaller? [17:02] jrgifford: yes, though in the future even when that changes it will only be as a result of having lxc everywhere to provide some isolation between units [17:02] bcsaller: ok, thanks. [17:03] that makes this super simple. [17:05] even with lxc everywhere, it will appear as though a charm owns the entire machine, except for the case of subordinate/co-located charms which are a little different in usage target [17:07] ok. guess i don't need to go this super convoluted route i was thinking about going... [17:07] (it involved compiling a bunch of stuff to make sure it was flexible) [17:07] jimbaker, bcsaller invites out [17:08] * hazmat looks for a stop watch program [17:09] hazmat: The branch has been updated, but maybe the directory polls/caches? I don't yet see it, but will check back after dinner. [17:16] jrgifford: the unit agent makes sure the hooks for a charm are executed serially too, so there's even less to worry about [17:16] hazmat: still there? [17:17] bcsaller, indeed, new invite out to you [17:17] jrgifford: idempotency is the only real issue you gotta worry about [17:18] m_3: gotcha. [17:19] https://juju.ubuntu.com/CharmSchool/2December11 [17:19] I still need 2 volunteer instructors for next Friday's Charm school [17:20] jcastro: tentatively, i'm in. [17:20] need to finish this charm first though. [17:21] since otherwise, i won't have anything to teach on. :) [17:21] I was going to go with an experienced charmer for the first one to teach [17:21] ok, that makes more sense. [17:21] basically I want this one to prep you guys up with what you need. [17:22] kind of solidify a core base [17:22] then grow from there [17:27] SpamapS: m_3: still need 2 volunteer instructors for the first charm school next friday *cough* *cough* [17:27] I'll run the thing, just need people to answer questions [17:30] jcastro: I'll be there... just thought you wanted newer charm authors to lead off [17:30] for this first one let's just concentrate on getting everyone in the right place at the right time [17:30] we'll do introductions [17:30] talk about the new charms people are working on [17:31] and then like, they can just Q+A you for a bit [17:31] by next friday these guys should be pretty comfortable, that will just leave us with nagging hard questions. [17:31] jrgifford: and then I'll put you on the hook to run the next one? [17:32] jcastro: sounds greate [17:32] s/e// [17:33] ok, m_3 alright so it'll be me and you next friday, and anyone else on juju core who happens to be around in IRC and talks will get automatically roped in. :) [17:45] jcastro: is that in #ubuntu-classroom or #juju? [17:45] jcastro: nevermind, you said #juju in email [17:45] I think we should do it here [17:46] it will bring people into the channel [17:46] yup [17:46] and hopefully encourage them to idle [18:06] i've been sporadically trying to resubmit a merge proposal (to change its target) but keep on getting timeouts from launchpad. is it something i'm doing, or is it launchpad flakiness currently? [18:13] rog, I have a vague recollection that there is a timeout bug for that case on occaision [18:13] if there's nothing of interest in the one you are trying to resubmit then you could delete and re-propose [18:13] james_w: there are a few comments that i don't want to lose [18:15] rog, I was thinking of a timeout on registering [18:15] rog, do you have an oops id from your timeouts? [18:16] james_w: yeah: OOPS-c942fd1ba80db6e59400b027d15aa31c) [18:16] rog, though are you trying to resubmit against a branch that isn't the "development focus"? [18:16] james_w: what does that mean? [18:17] a development focus branch is anything that has a "short name" [18:17] like lp:juju lp:juju/something [18:17] if you are trying to propose against lp:~someone/juju/something-else then it may be the bug I was thinking of [18:17] james_w: the branch target was not originally against the development focus [18:17] james_w: that's why i'm resubmitting [18:18] then it may be https://bugs.launchpad.net/launchpad/+bug/793830 [18:18] <_mup_> Bug #793830: Branch:+register-merge time out due to substring matching many tables < https://launchpad.net/bugs/793830 > [18:19] my mouse pointer is jiggling - anyone else get that? [18:19] oh well, i'll delete and create again [18:20] do deleted merge requests remain around so i can point a URL at one (so the old comments aren't lost) [18:20] ? [18:20] I don't think so [18:20] oh well. [18:20] if you wait a couple more minutes we should be able to see the OOPS and that may give a clue as to a workaround [18:21] james_w: where do OOPSs end up? [18:21] https://lp-oops.canonical.com/?oopsid=c942fd1ba80db6e59400b027d15aa31c [18:22] one mo, need to suspend to stop my mouse wiggling [18:23] james_w: how long does it usually take? [18:23] (that oops was probably an hour ago) [18:23] oh, ok [18:23] seems it has disappeared then [18:24] I think it's up to 10 minutes usually [18:24] james_w: thanks for your help. i've got to leave now. will try again tomorrow. [18:25] ok [18:25] see y'all tomorrow [18:25] ttfn [18:33] mcclurmc, greetings.. how goes the xen provider? [18:33] er. xcp [18:33] hi hazmat [18:33] it goes [18:33] it's currently my spare-spare time project, unfortunately [18:34] i created a spec though, and i think i made you the approver [18:34] is this okay? [18:34] mcclurmc, sounds good, if you have any questions.. this is the place to ask.. [18:36] i've got a few questions, but they're not fully formed [18:37] i'm going to try to find some time tonight to work on the filestorage implementation, so i might be back here [18:45] mcclurmc, sounds good [19:08] jcastro: sounds good. [19:25] hazmat, is there any point at all in specifying pidfiles for upstart services? [19:26] fwereade, none [19:26] fwereade, welcome back.. i think you disconnected on the answer earlier [19:26] hazmat, good-o, we can delete some code :) [19:26] fwereade, lots ;-) [19:26] hazmat, probably did, sorry about that [19:26] fwereade, no worries, rog mentioned you had power issues [19:27] hazmat, yeah, it happens every now and then [20:19] so SpamapS [20:55] so jcastro ;-) [20:56] * hazmat wants for some more packaging automation [20:57] we haz the power [21:01] what do you mean? [21:01] actually I was just going to mail the list about charm snippets, we haz the power [21:02] hazmat: what's on your mind? [21:02] jcastro, just ruminating over the power of a simple site that you upload a tarball or a url + tarball of deb and it packages it for you [21:03] I believe james_w is working on exactly that sort of thing [21:03] i wantz it [21:04] we are [21:04] james_w, awesome [21:04] james_w, url ? ;-) [21:04] http://developer.ubuntu.com/2011/11/automatic-packaging-progress/ [21:05] * m_3 loves it when a plan comes together [21:05] hmm. pkgme is for simple CMMI (configure/make/make install) style single source single pkg systems, aka the 95%.. which is indeed awesome [21:06] i have single source multi-package tarball with existing deb dir [21:06] anyone interested ? ;-) http://labs.omniti.com/labs/reconnoiter [21:07] its already packaged.. i was just thinking it would be nice if it could auto ppa for me.. http://labs.omniti.com/labs/reconnoiter/browser/pkg/debian [21:07] er.. not upstream but the packaging work is done [21:07] it's pretty easy to automate packaging something with a deb dir :-) [21:08] james_w, true that [21:08] does that packaged code live in a VCS somewhere public? [21:08] james_w, indeed its a public svn [21:08] ah, sorry, looked at the link now [21:08] then you want recipes [21:08] er.. git [21:08] git clone git://github.com/omniti-labs/reconnoiter.git [21:09] import reconnoiter to LP bzr [21:09] and import than git repo too [21:09] then combine them with a recipe and set it to build every day [21:09] then you'll have a fresh PPA package every day (if there is new code to package) [21:10] ic.. so basically follow on https://help.launchpad.net/Packaging/SourceBuilds/Recipes [21:10] yeah, with a bit of https://help.launchpad.net/Code/Imports thrown in to get the code in to Launchpad [21:11] recipes are easier than the length of that page would suggest [21:11] james_w, if that src pkg namespace (ie. upstream) is already owned on lp, i guess i need to email the current owner to give access? [21:12] shouldn't do [21:13] https://code.launchpad.net/~thombot/reconnoiter/trunk is an import of the main code so that takes care of that part [21:13] hmm.. already a src import [21:13] so just need a recipe that skips nest for mv [21:14] nest-part will do that [21:15] james_w, well its got a failed build i assume because of the nest part [21:15] ie. there's already a recipe [21:15] oh [21:15] didn't see the recipe [21:15] https://code.launchpad.net/~dsci-admins/+recipe/reconnoiter-daily [21:16] ah [21:16] interesting [21:16] trying to nest from itself [21:16] I love "accidentally" finding recipes [21:17] james_w, yeah.. just reading through this bug report against the same sort of usage of nest-part https://bugs.launchpad.net/bzr-builder/+bug/771568 [21:17] <_mup_> Bug #771568: nest-part unable to nest files

< https://launchpad.net/bugs/771568 > [21:17] seems like it should just do a mv [21:18] jcastro, re charm snippets, what about a gist/pastebin setup? [21:19] what, contribute your snippet, then we just have a list of URLs? [21:19] jcastro, with description, search, comments, tags, ratings [21:20] ok so how would that work [21:20] let's say I have a snippet. [21:20] I put it in pastebin [21:20] then ... ? [21:20] I'm in favor of gist's because you can fork gists [21:20] you'd add a description of what your snippet does publish it to the a snippet repo, other folks could discover it via search, comment on it, and rate it [21:20] How do your other examples work? I don't think I've ever used them [21:21] marcoceppi, ? [21:21] marcoceppi, you mean the example formulas? [21:21] might need to be a little more involved though... templating, local config storage, etc... was thinking language-specific charmutils deployed on each unit. but I really like the simplicity of gists/pastes [21:21] the examples dir is a repo [21:21] hazmat jcastro put up a few packages as examples, one for bash and one for python [21:21] m_3, in that context, well the question is the purpose to share knowledge or multi-file arbitrary language code [21:22] Oh, nevermind, I see what those are now [21:22] gist/pastes with comments/ratings can share knowledge and discovery via search [21:22] libraries share code [21:23] hazmat: I'd be leaning more towards sharing code... it's really boilerplate as far as knowledge goes [21:24] we should include examples in the list [21:25] love the gist/pastebin approach though... I'm not clear on the lines between the different uses [21:25] yeah so the thing is [21:26] definitely a problem... charmers start copying scripts from one charm to the next [21:26] "I need to get foo and do bar to it", here you go dude, here's the pastebin. If it's basically like another store but for snippets .... too complicated? [21:26] What about if snippets get updated? [21:26] or would these just be "use at your own risk brooooo" [21:27] can you update gists? [21:27] so the url doesn't change? [21:28] jcastro: Not really, it creates a fork to it, IIRC [21:28] jk, you can [21:28] https://gist.github.com/1387034 [21:28] Even tracks revision history [21:29] hazmat: BTW, reconnoiter is building in my ppa if you just want a one-off package to charm with (https://launchpad.net/~mark-mims/+archive/ppa/+packages)... I'll let you know when it finishes [21:30] m_3, score! ;-) [21:30] jcastro: and forks https://gist.github.com/1336585 [21:31] ok so this seems pretty lightweight to me [21:32] hazmat: dunno if it'll build, but we'll see [21:33] jcastro: quite lightweight, but that can be a good thing... perhaps this is two different requirements [21:33] m_3, i'm hopeful [21:33] m_3: lightweight wins here I think, they're just snippets [21:33] +1 [21:33] if it does build then https://code.launchpad.net/~james-w/+recipe/reconnoiter-daily will do it daily [21:33] the problem with gists is discovery [21:33] bzr saves the day [21:33] james_w, awesome [21:34] hazmat: so, if we're going for some lightweight ones, why not just a wiki page with the common ones? [21:34] also, sabfl just responded on the list, so it will definately not be me recommending using something from github. :p [21:35] james_w: thanks, I'll try that out... I haven't played with recipes yet... just sort of plugged reconnoiter(sp?) into the debuild process that I've been scared to leave cause it works! [21:35] jcastro, good question [21:35] jcastro: wiki => manual process == evil ( or really, just out of date) [21:36] Wiki pages kind of suck at managing code snippets? [21:36] not for the snippets themselves [21:36] I mean as a link to snippets, but mark has a point about the manualness [21:37] oh dude, I got it. [21:37] charm-store extension [21:37] :) [21:37] http://pad.ubuntu.com/marco-charm [21:37] and then the index becomes: http://pad.ubuntu.com/ep/search?query=charm-snippet [21:38] not a bad idea [21:38] except there is no pad search [21:39] Seems to maintain formatting OK [21:40] marcoceppi: right expect you'd make another one, one for each snippet [21:40] going back to a wiki page... assuming good formatting tools and embedded discussion (disqus).. is it problematic? [21:40] and tag it with #charm-snippet [21:40] i guess i shouldn't assume the current wiki site for juju [21:40] jcastro: yeah, I was just testing the formatting [21:41] wiki'd work [21:41] ok so wiki is fine [21:41] other than no one who doesn't work for canonical can't write to it yet. [21:42] we'll need cli and vim plugins a la pastebinit [21:42] s/need/want/ [21:45] man, bummer about the search on etherpad [21:45] that is almost what we want. [22:28] hazmat: reconnoiter isn't scheduled to build for another 7hrs (amd64) and 11hrs (i386)... I'm guessing they're still playing with perl or something on the buildds [22:56] m_3, no worries, i've been down the buildd road b4 by hand, its a waiting game