[00:55] <_mup_> juju/local-repo-log-broken-charm r416 committed by kapil.thangavelu@canonical.com [00:55] <_mup_> deploy uses serviceconfigvalue error [00:57] <_mup_> juju/trunk r414 committed by kapil.thangavelu@canonical.com [00:57] <_mup_> merge local-repo-log-broken-charm [r=fwereade,bcsaller][f=885515] [00:57] <_mup_> - Local repository find logs charm error information with location information. [00:57] <_mup_> - Unify metadata and config error handling. Structural errors are preserved and raised. [00:57] <_mup_> - Config definition errors are distinct from value errors. [02:47] Woohay [02:47] https://code.launchpad.net/~niemeyer/lbox/test-branch/+merge/82239 [02:47] Almost there.. [10:26] hazmat: you around? [11:18] fwereade: hiya [11:18] heya rog [11:18] fwereade: someone cut through the phone line this morning [11:18] wtf? [11:18] fwereade: so hoping i don't reach my mobile phone download limit... [11:18] rog, overly casual use of a digger or something? [11:19] rog crikey [11:19] fwereade: yeah. lots of water mains replacement going on [11:19] fwereade: we've had the street dug up for about 5 weeks now! [11:19] rog: unhelpful ;) [11:20] fwereade: indeed. [11:25] fwereade: at least my phone can act as a wifi hotspot, very handy in a pinch [11:46] rog, yeah, very handy (sorry I missed you) [11:46] rog I have a nearby cafe for emergencies :) [11:46] fwereade: no cafes with wifi here in darkest Tyneside :-) [11:47] rog, some parts of malta are more civilised than some parts of the uk, at least, then [11:47] actually, i *say* that, but i should probably explore a bit [11:47] rog, although I guess that statement doesn't say much :p [11:47] lol [11:48] fwereade: depends whether your definition of "civilised" equates to "has wifi" [11:48] rog, there's another definition? [11:49] fwereade: "has running water" does it for me. having been without it yesterday... [11:49] rog, ouch :( [11:50] rog, just going to collect laura from nursery [11:50] fwereade: to be honest i don't mind. i lived without plumbing for almost a decade :-) [11:50] k [12:13] rog, I must say that perception-of-civilisation has a sort of ratchet effect built in [12:14] fwereade: definitely. always good to remember the bottom line... food and shelter :-) [12:15] rog, yeah [12:16] rog, I'm trying to remember a nice statement of the general problem in a book I read recently [12:16] rog: ah, in excession [12:16] That was the Dependency Principle; that you could never forget where your Off switches were located, even if it was somewhere tiresome. [12:17] fwereade: speaking of books, just started Kraken and am having difficulty in avoiding just sitting down for the day and consuming it. [12:17] fwereade: i'd forgotten that. [12:17] rog, yeah, I remember really enjoying it while I was reading it [12:18] fwereade: i misremember, i thought you hadn't read it. anyway, ahem, we digess. [12:18] rog: I got distacted half way through [12:18] rog: been meaning to go back to it for more than a year now :/ [12:19] g'morning folks [12:19] krakens and waters mains indeed ;-).. [12:19] fwereade: ah! carmen did the same thing. my fault - i took it off her to go to orlando, citing greater need and monetary outlay. [12:20] hazmat: hiya [12:20] * hazmat had a hill disappear directly behind the house and turn into a parking lot yesterday [12:20] * rog hates it when they do that [12:33] wifi coverage is strongly motivated by tourism, so malta having a good one is not so much of a surprise to me [12:36] it's pretty amazing when you arrive in San Pedro of Atacama, village lost in the middle of the desert, and you discover you get a wifi signal pretty much everywhere in the main "streets". [12:56] Hello all! [12:57] niemeyer: hiya! [12:58] g'morning [12:59] 'lo [13:02] fwereade, you pinged? [13:21] hazmat, hey [13:21] hazmat, I just wanted to check there wasn't a reason for the -n arg to the agents to be weird [13:22] fwereade, its not wierd at all, in fact the upstart files for unit agent in local do that [13:22] fwereade, i was thinking it would be done more as a class like what was done with the cloud init rather than some gestalt formatting function [13:23] hazmat, agent -n ends up meaning "run as a daemon" instead of "run in foreground", as one might expect on a casual reading [13:23] fwereade, the primary reason -n isn't used is these processes is that there not being supervised.. so they daemonize.. [13:23] fwereade, really? -n should be no daemon [13:23] hazmat, quite so [13:24] I spent most of a day assuming that -n meant no-daemon until I thought to look at that bit of code ;) [13:24] hazmat, anyway, I've fixed that now and it's getting there [13:25] hazmat, the remaining weirdness is almost certainly my fault ;) [13:26] fwereade, yeah.. it is a bit confusing looking at control/options.py and twistd -h [13:27] hmm. ic but yeah it appears to be the opposite [13:27] -n implies daemon [13:27] hazmat, indeed [13:27] hazmat, ah, that was it, I wanted to check that that wasn't really an API change in any meaningful sense [13:28] i might have reversed that from the original twisted semantics [13:28] hazmat, ah, was there a reason you can recall? [13:28] * hazmat checks the twisted source [13:29] fwereade, nothing comes to mind [14:57] fwereade, i think you where right btw regarding HA story, not collapsing the juju services into a single juju service, there will be others in the future and the collapse makes even less as that number grows [14:57] hazmat: cool :) [14:57] although it would make sense to continue the placement of provisioning agent and storage i think [14:58] that's relatively minor and paranoid as well ;-) [14:58] hazmat: potentially -- I'm mainly waiting to see what my brain thinks is a good idea when we come to actually implement it [14:59] hazmat: for all I know I'll be firmly advocating something entirely different :p [14:59] fwereade, ;-) i think the separate service notion gets better once we have service namespaces/hierarchies [14:59] hazmat, definitely [15:00] but thats perhaps not on the roadmap for 12.04.. so perhaps irrelevant [15:00] er. its not on the roadmap [15:00] yep, understood :) [15:02] Just going through the juju docs [15:03] I'm wondering... Juju makes it very easy to deploy and scale services quickly [15:03] but how about maintaining services for a long time, where conffiles need to be adapted over time without adding/removing nodes? [15:03] the typical case where you'd use cfengine/puppet to maintain long-term services [15:04] how does juju play along in this case? [15:05] jcastro: yo [15:09] hi [15:09] m_3: man, you know every one. [15:10] hi every one :-) [15:10] hi raphink! [15:11] sup jcastro ? [15:11] jcastro: yeah, small devops world [15:12] jcastro: about a mongosv charmschool... is it worth a byobu-classroom type setup? [15:12] that seems like a lot of extra distraction [15:12] m_3: I think keeping it simple is key [15:12] otherwise how do we handle other clients? [15:13] I've never tried it on a mac [15:13] * m_3 adds to the todo list [15:13] looking at the attendees they're not going to be dumb people there. I think opening up the hadoop charm and going through the sections will do the trick [15:13] jcastro: would this be more of a charming presentation (sorry) [15:13] than charmschool? [15:14] lead to for wifi setup is a concern too [15:14] raphink: there's facilities to upgrade charms, but I don't know enough about it to answer your question intelligently, perhaps ask on the mailing list? [15:14] s/lead to/lead time/ [15:14] thanks jcastro [15:14] m_3: yeah, so if it ends up being more of a one-to-many but more in depth than a normal presentation, I think that will be fine [15:14] gotcha... cool... I'll reply with that... thanks! [15:15] I mean, if they're having it anyway, and Juan's going to be there ... [15:15] jcastro: from what I understand, upgrading a charm will allow to re-run the installation, but will it update a machine's configuration without re-installing it? [15:15] I am not sure [15:17] ok [15:29] <_mup_> juju/preserve-unit-for-external-gc r415 committed by kapil.thangavelu@canonical.com [15:29] <_mup_> defer removal of unit state to a garbage collector [15:31] Lunch time! [15:36] <_mup_> juju/preserve-unit-for-external-gc r416 committed by kapil.thangavelu@canonical.com [15:36] <_mup_> preserve service state for out-of-band garbage collection, to provide for a currently executing hook retrieving service config. [15:39] raphink, changing the service's configuration, will invoke the charm's config-changed hook and can update local config files... for additional configuration management, we're working on a feature called co-located/subordinate charms that will allow for deploying puppet, logging, etc alongside/within other service units [15:40] that's what I meant [15:40] upgrade-charm is also present though its more for changes to the functionality of the charm than as a general means to effect on-going long term management [15:40] thanks hazmat , that sounds interesting [15:42] hazmat: so the "juju master" (how do you call machine 0?) would become a puppet master and potentially a log server, too? [15:42] or would you make charms to deploy puppet masters and log servers? [15:44] i wouldn't call it a juju master, its just the first machine in the environment, running some internal juju services, we've discussed an ha story on list that turns it into just another machine [15:44] ah right [15:45] raphink, but to the question.. you'd deploy a puppet-master charm, or a munin aggregator charm as a separate service (the head) and then relate it to munin-node or puppet subordinate/co-located service [15:45] ok [15:45] the subordinate services will associated to existing services via add/remove-relation [15:45] and then deploying a new service would be pretty much simply relating a new machine to the puppet service [15:45] ie. the tails that connect back to the head. [15:45] sorry, deploying a new _service unit_ [15:46] raphink, well you wouldn't be associating the machine per se.. you'd be associating to puppet to another service.. say hadoop [15:46] er.. hdfs data node [15:47] the containers running those service units would all be populated with units of the puppet agent charm [15:47] s/charm/service [15:48] ie. the association isn't between a machine and a puppet service but just a relation between services [15:48] right [15:48] the effect of having it everywhere.. ie all machines is achieved by setting up some default co-location services for the environment [15:48] you only deploy puppet client services [15:49] and you register these nodes to the puppet master to tag them properly for deployment [15:49] right? [15:50] raphink, basically.. the puppet client service and puppet master service have a relation like any other relation, whose hooks effect that registration. [15:50] so yes [15:50] ok [15:51] and then it's the puppet code that instantiates the functional relations (like db/frontal for example) ? [15:52] at the moment this feature is at the level of consenting adults.. a co-located/subordinate charm can do all sorts of interference to the parent/master service unit its deployed along with which is prevented by juju. And at the moment the external system has minimal knowledge of the service unit its deployed with (just identity). [15:52] there's some mail on the list going through some additional things that could be done like exposing additional cli api to provide for populating the puppet master with more relevant facts/tags. [15:53] right [15:53] I remember when I read about mcollective [15:54] the guy talked about how machine names didn't really matter anymore [15:54] since he could use tags to deploy/control them [15:54] I guess the idea behind juju is also to automate this kind of relation between machine name and functional names (like wordpress/1) [15:57] raphink, well its to obviate the machine name [15:57] yes [15:58] not to beat a dead horse, but say i've got a logging or metrics aggregator, i don't want it to record the machine name but the unit name, which could have migrated away from the given machine.. more importantly i don't care about the machine performance, but the service level aggregate among its units. [15:58] s/performance/identity [16:00] right [16:23] What's this Jim Jammer guy doing? [16:31] Hm [16:35] windows phone? I'm imagining a private conversation between loved ones simply routed to the wrong place [16:46] yes, every list will eventually get spam, vacation responders, and miscellaneous other cruft [16:47] not to mention the occasional troll [16:52] jcastro, just to clarify you where serious about needing metrics reports this week? [16:52] hazmat: yes please. [16:53] jcastro, ok.. in progress [16:53] hazmat: I'll clarify with jono today during our call how important they are to him to have right away [16:53] jcastro, awesome, thanks [17:37] where are the WTF test results? [17:37] they used to be in the topic [17:50] SpamapS: is it easy to transfer ownership of upstream charmers teams in lp? I prefer to create the teams beforehand, but I'd rather it not show me as the team owner for all time [17:52] m_3: the branch owner team should be owned by charmers, and have charmers and the upstream managed team as its members. [17:52] m_3: you can give away ownership of a team to another team that you are an administrator of. I think I'll make you a charmers administrator [17:52] niemeyer, fwereade: PTAL at the go-juju-initial-ec2 [17:52] m_3: actually you're in ~juju so you are already an admin [17:52] niemeyer, fwereade: i think it should be good to go [17:52] rog: Cheers [17:53] SpamapS: I thought we were going to create new team and add charmers as members of that team [17:53] ah, yes... sorry read above wrong [17:53] m_3: so like, for voltdb, I'd call it voltdb-charmers [17:55] I did this last week... lemme find the team [17:56] crud, I removed it [17:56] created "Test Charmers" with a testcharm to test out the lp:charm/testcharm aliases and ownership [17:58] SpamapS: ok, so looking back on it, that process should work fine if I can transfer ownership... cool thanks! [17:59] Is there any documentation on the other supported environments for Juju? [18:00] marcoceppi: the orchestra provider is probably the hardest to find docs on [18:01] marcoceppi: but that is coming [18:01] marcoceppi: ec2 and local are well documented https://juju.ubuntu.com/docs/ [18:05] Right, I thought there were other environments. Maybe I'm confused with what Orchestra is? [18:06] Wikipedia says many things, but nothing that looks like the Orchestra you've referred to [18:17] SpamapS, wtf.labix.org [18:18] marcoceppi, https://wiki.ubuntu.com/ServerTeam/Orchestra [18:21] Oh god Orchestra looks awesome [18:50] hazmat: thanks [18:50] So, I'm thinking I'll upload 416 to precise. [18:53] SpamapS, sounds good [18:55] hey SpamapS [18:55] so, marcoceppi's blog post is ready for the minecraft charm [18:55] but he's pulling it from his personal branch [18:56] it would be nice for that part of the blog to just say "charm get minecraft" [18:57] So in other words, I should totally review the charm right now and get that bad boy in the store, so we don't miss the surge of interest around Minecraft's release [18:57] SpamapS: correct! [18:59] jcastro: will review shortly. :) [18:59] marcoceppi: please make sure you have your asbestos suit handy.. ;) [19:04] * marcoceppi suits up [19:38] marcoceppi: btw, as a member of charmers, you can make it official yourself, though I have found at least one thing that needs fixing before it is importable. [19:40] SpamapS: I didn't want to be presumptuous and say "oh, this is done" without a somemore eyes on. [19:40] What did you find? [19:41] SpamapS: boo, bad best practice, everyone should check, even if you're a pro [19:41] marcoceppi: yeah the optional review is something we should all make use of until we're sure about the process and requirements. :) [19:41] I suppose we could enforce the NEW queue like Debian/Ubuntu do.. but for now, lets just make it a convention [19:41] marcoceppi: commented in bug 857654 [19:41] <_mup_> Bug #857654: Charm needed: Minecraft Server < https://launchpad.net/bugs/857654 > [19:42] marcoceppi: basically you need to set the license info right for opt/minecraft [19:45] SpamapS: Ack, missed that. The rest looks pretty easy to fix. I'll try to find a state that I can check in the minecraft setup to remove the sleep [19:46] marcoceppi: again tho, those are just bugs, I'd say just import it once you fix the license info [19:47] \o/ [19:48] * marcoceppi hates legal stuff [19:51] marcoceppi: everybody except me seems to share that, so please, defer all legal stuff to me... keep illegal stuff for jcastro. [19:52] It appears that the startup script is actually not from Mojang, but the Curse wiki [19:52] So I'm just going to link back to the source and say it's released under the CC-BY-NC-SA 3.0 [19:57] marcoceppi: sounds good, the CC-BY-NC-SA specifically mentions that you must attribute the author. [19:57] marcoceppi: which is annoying, because the author of said script is not clear [19:58] http://www.minecraftwiki.net/wiki/User:Hount [19:58] Right, so I just throw back a link to the source, which should dispell anyone curious of the author. [19:58] created the page [19:59] really, CC-BY-NC-SA is a *horrible* software license. [20:00] well, people don't think about that when they toss random scripts on their CC licensed-by-default wikis [20:00] Yeah [20:00] people don't consider licensing at all [20:01] Its one of those things that will likely never actually bite anybody int he arse, but when it does, it will likely be a very expensive bite. [20:01] marcoceppi: I think a link to the page and mention of the CC-BY-NC-SA is as good as you can get, since the attribution on the page is even unclear. [20:02] marcoceppi: technically though, you have to respect the copyrights you're informed of, and in this case, Mojang AB and Curse Inc. are claiming copyright. [20:02] well [20:02] Curse Inc. is actually, not Mojang. [20:03] http://www.curse.com/legacycontent/curse-network-terms-of-service [20:03] two pages on IP [20:04] "By submitting, posting or displaying User Submissions on, to, or through Curse Websites (or its successors and affiliates), you grant Curse, Inc. a worldwide, non-exclusive, transferrable, royalty-free right to use, reproduce, distribute, display, perform, make derivative work" [20:04] I'd say its Curse's [20:04] and CC-BY-NC-SA would be very clear, that you need to attribute it to them. [20:04] man, this due diligence thing is a buzzkill [20:05] jcastro: a bigger buzzkill would be Curse suing all users of the minecraft charm. :-/ [20:05] Yeah, I pushed up what I have now [20:05] SpamapS: yeah I know I know [20:05] opt/minecraft is released under Attribution-NonCommercial-ShareAlike 3.0 Unported. [20:05] (CC BY-NC-SA 3.0) http://creativecommons.org/licenses/by-nc-sa/3.0/ made [20:05] available from (http://www.minecraftwiki.net/wiki/Server_startup_script) by Curse [20:05] need to add Inc. [20:05] marcoceppi: yeah, add Inc. and thats good enough for me. [20:06] interesting though [20:06] with the NC bit.. nobody can charge for access to the minecraft servers they're deploying [20:06] Curse runs the wiki and the forums [20:06] Oh. [20:06] what? [20:06] marcoceppi: what would you say to supplanting that script with an upstart job? [20:06] Because of the init script [20:06] SpamapS: I'd be all for it [20:06] marcoceppi: right, if you are charging for that server access, you are now using the script for commercial purposes [20:06] Shouldn't be _too_ difficult [20:07] It should be dead simple [20:07] I'll read up on upstarts [20:07] tho you'd lose the cool update/backup/etc. bits [20:07] yeah but we'd be jameshunt approved! [20:07] marcoceppi: given that, I think we actually need to keep CC-BY-NC-SA out of the official charm repo [20:07] Well, with the upstart it won't be needed [20:07] right [20:08] give me a min to whip something together [20:08] w00t [20:08] marcoceppi: might want to send them a mail and be like "hi, we're trying to make it easy for people to deploy minecraft servers, can you clarify the license on this script?" [20:08] Yeah [20:08] they probably don't know/care that it's a problem [20:08] The original submitter probably didn't realize they gave away all IP rights when submitting stuff to that wiki [20:08] ^^ right [20:08] and Curse probably does not want the rights to that script [20:09] SpamapS: there are alternatives to that script, linked at the bottom [20:10] yeah, those have licenses.. nice [20:10] mcwrapper is MIT [20:10] Though done *completely* wrong [20:10] (has to be in the software..heh) [20:11] well, this is one of the first ones [20:11] mcshellscript has no license [20:11] I think we should set the standard, and do it the upstarty way [20:11] jcastro: I think so too [20:11] jcastro: I agree [20:11] even if it means another day or whatever [20:11] It looks like I can finally ditch screen too [20:11] The whole point of having this distro of charms is that you can use them without thinking about it [20:12] minecraft-init has the most clear license, btw [20:13] # (c) 2010-2011 Dagmar d'Surreal [20:13] # Released under the terms of the GNU GPL 2.0. [20:13] # Run this script with the argument 'licence' to read the licence. [20:13] * SpamapS adds a question to the Discuss page of the original script about its licensing [20:24] * marcoceppi needs to figure out how to test the upstart script [20:25] http://www.minecraftwiki.net/wiki/Talk:Server_startup_script#Licensing_of_this_script.3F [20:26] marcoceppi: service minecraft start [20:26] marcoceppi: want to pastebin it? You're in luck, I'm not just the charm expert, I'm also an upstart expert. ;) [20:26] Where to I put the upstart script? [20:26] /etc/init.d/ ? [20:27] /etc/init/minecraft.conf [20:27] oh god, the error messages! [20:28] can't you just send them out to a logfile? [20:29] exec java -foo minecraft.jar server.whatever >> /var/log/minecraft/minecraft.log 2> /var/log/minecraft/minecraft.err [20:29] http://paste.ubuntu.com/740560/ [20:30] are you *sure* it forks? [20:30] oh and don't emit anything ;) [20:30] So, no forking, no emiting? [20:30] 'started minecraft' is automatically emitted [20:30] marcoceppi: since you ran it in screen before, I'm guessing there was no forking [20:31] marcoceppi: also description can just be "Minecraft server" .. it will show in bootup as 'Starting: Minecraft server' and 'Started: Minecraft server' [20:32] Stupid blog post from 2005 led me astray [20:32] ;) [20:32] yeah trust nothing before 2010 regarding upstart [20:32] Everytime I try to "start minecraft" I get this [20:32] start: Rejected send message, 1 matched rules; type="method_call", sender=":1.173" (uid=1000 pid=6044 comm="start minecraft ") interface="com.ubuntu.Upstart0_6.Job" member="Start" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init") [20:33] thats because you're not root. :) [20:33] UGH, duh. [20:33] make *sure* you removed the 'expect fork' btw [20:33] wow, that actually worked [20:33] there's a bug, if you say 'expect fork' and it doesn't.. the job will be stuck forever. [20:33] cool, I removed it, it's all working now \o/ [20:33] also you don't need script [20:34] chdir is a stanza [20:34] so you can just do 'chdir /opt/minecraft' and then exec [20:34] marcoceppi: \o/ [20:35] sudo stop minecraft yields this: [20:35] stop: Unknown instance: [20:38] Here's the updated script [20:38] http://paste.ubuntu.com/740563/ [20:39] marcoceppi: is it still running tho? [20:39] yup [20:39] so maybe it does fork. ;) [20:39] just.. doesn't let go of stdout/stderr? hrm [20:40] it does fork. [20:40] marcoceppi: so, to make it easier to read, maybe consider moving all the java -X args into their own env? [20:40] hey, expect fork - all is good now [20:41] one ENV for each, or one ENV to rule them all? [20:42] oh [20:42] no its forking because you left the & [20:42] Oh, so I don't need to push it to the background then? [20:42] marcoceppi: http://paste.ubuntu.com/740568/ [20:42] that might work [20:43] marcoceppi: no, upstart does that for you. :) [20:44] perfect [20:45] Hi, today I've got an off-topic prob. [20:45] May anybody help me with unity ? [20:46] TheMue: #ubuntu maybe? [20:47] Yep, sounds logical. *smile* But I'm starting #juju by default, so I used it for my first question. *lol* [20:49] TheMue: by all means, be the first to create a unity charm! ;-) (using vnc server? ;-) [20:49] hehe, will start creating charms aftere Dec 1st. but this time my unity settings are messed up. [20:50] So, reset done, try a restart. [20:52] SpamapS: For the interface, do I need to do anything special with that? [20:52] charm proof gives me a warning, since I don't have relation hooks [20:53] Otherwise I've pushed up all the other changes, with the exception of unpack detection, to the bzr [21:14] I think I've found a way to settle the problem with detecting unpacking [21:44] SpamapS jcastro I think minecraft is ready for final review [21:50] whoa, that was fast! [21:51] marcoceppi: bzr pulling now [21:53] marcoceppi: nice. So do you want to do the official "promulgating" ? [21:53] Sure, might as well learn now [21:54] marcoceppi: bzr push --remember lp:~charmers/charm/oneiric/minecraft/trunk && charm promulgate ... that should do it. [21:55] Will I always have to push to charmers/charm? going forward? [21:59] SpamapS: marcoceppi: off to a lug meeting, I'll check in in a few [21:59] jcastro: \o [21:59] marcoceppi: just ping me me when blog post is ready/updated with the charm get [21:59] will do [21:59] and I'll suck it onto cloud.ubuntu.com [22:02] jcastro: that ThinkUp stuff is pretty sweet...would be sweet to get a charm for it [22:02] yeah [22:02] I put it on the list right away [22:04] Okay, just confirmed all the new upstart stuff works properly, promulgating [22:07] marcoceppi: *saweet* [22:08] Awesome, pushed and working [22:08] $ charm list|grep minecraft [22:08] lp:charm/minecraft [22:08] woot [22:09] awesomely unbelievable [22:09] * marcoceppi pelvic-thrusts around the office [22:09] lol [22:16] Shouldn't charm get take a --repository flag? [22:25] marcoceppi: no it only cares about official lp:charm charms [22:25] marcoceppi: otherwise, just use bzr branch [22:26] It's just odd that it always branchs into CWD, most ever other charm command allows you specify a directory [22:26] ahhhh that [22:27] good point [22:27] I'll throw up a bug against it, if you want [22:28] almost done [22:28] cool! :D [22:31] marcoceppi: truth be told, charm get is kind of.. not something we need.. just seemed missing, which is I think why negronjl wrot eit [22:32] It's basically a wrapper for bzr branch lp:charm/ right? [22:32] marcoceppi: r82 pushed with repo name for charm get :) [22:32] marcoceppi: right [22:32] <3 [22:32] should arrive as an update from the PPA tomorrow [22:32] which reminds me, I need to upload charm-tools to Ubuntu [22:35] marcoceppi: props! [22:39] m_3: Thanks! 1 down, many more to go :) [23:01] looks like more errors building on precise.. [23:01] https://launchpadlibrarian.net/85303628/buildlog_ubuntu-precise-i386.juju_0.5%2Bbzr416-1juju1~precise1_FAILEDTOBUILD.txt.gz [23:02] <_mup_> Bug #891419 was filed: Juju fails test suite when building on precise < https://launchpad.net/bugs/891419 > [23:13] * SpamapS goes on a bug triage rampage [23:20] bcsaller: hey are you working on colocation? [23:20] bcsaller: I'm thinking bug 805585 should be assigned to you as part of that [23:20] <_mup_> Bug #805585: Break the one service-unit per instance assumption < https://launchpad.net/bugs/805585 > [23:21] SpamapS: I am working it, called "subordinate services now", less ambiguous [23:27] * SpamapS imagines services lining up in neat rows being inspected by commanders. ;) [23:30] bcsaller: is there another bug report already open? otherwise I'll morph this one into subordinates [23:31] SpamapS: I don't have one for a devel branch, I can map the existing one to it when I'm ready for the first push [23:34] Ok, basically re-wrote the bug.. bug 805585 is yours now ;) [23:34] <_mup_> Bug #805585: Policy charms should be able to be deployed along side other charms inside the same machine/container.