[00:01] <SpamapS>  00:01:44 up 163 days,  9:12,  1 user,  load average: 0.42, 13.39, 16.99
[00:01] <SpamapS> doh
[00:03] <SpamapS> [14115521.537845] drizzled invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
[00:03] <SpamapS> why is it always the database that gets oom'd first!
[00:24] <SpamapS> http://fewbar.com/charms/need-maintainers.txt
[00:24] <SpamapS> Looking much better!
[00:57] <negronjl> SpamapS: when was the last time you updated need-maintainers.txt ?  AFAIK  all of my charms have maintainers but, they still show on your black list :)
[01:49] <SpamapS> negronjl: I have a few that aren't showing right either
[01:50] <negronjl> SpamapS: ... the list of shame is not working right ... :)
[01:50] <SpamapS> negronjl: something in LP or bzr is not working right
[01:51] <negronjl> SpamapS: I've been having random issues with bzr today ...
[01:52] <SpamapS> negronjl: AHA
[01:52] <SpamapS> charm getall did bzr checkouts
[01:52] <SpamapS> so I have to do 'bzr update'
[01:52] <SpamapS> doh
[01:53] <SpamapS> negronjl: the next run should fix most of that
[01:53] <negronjl> SpamapS: nice
[01:53] <SpamapS> so to be clear, bzr and lp are working right.. SpamapS just had a bug :)
[01:54] <negronjl> SpamapS: lol ... clearing the air :)
[01:55] <hazmat> m_3, spoke too soon not fixed quite yet
[01:56]  * SpamapS wonders how much faster this would be if he were using http: bzr instead of ssh+bzr
[01:57] <hazmat> SpamapS, probably not much
[01:58] <hazmat> SpamapS, it takes about 7m to updates across all the charms for me atm
[01:58] <hazmat> without ssh
[01:58] <hazmat> that's across oneiric and precise charms though
[01:59] <hazmat> which is about 365 charms
[02:02] <hazmat> ~8m30s to be more precise
[03:57] <imbrandon> oh noes, so head was not producing good code so i took a walk, only to the other side of the desk, went to fix one loose cable and have now tore down my full setup , figured it needs a good cleanup anyhow
[03:57] <imbrandon> 5 min turns to 2 hours
[12:48] <imbrandon> m_3 / SpamapS : lets see if i can ask this in short way but get my full meaning ... ok so what about a distinguishment between a service charm and a data charm that really only wants to dump its code thats diffrent or in addiotion to the say wordpress service charm
[12:49] <imbrandon> but not really provide an interfact, just a data/code dump in reality
[12:49] <imbrandon> gotta head out, i'll poke yall later
[12:54] <mgz> is the version of juju exposed inside the python package anywhere?
[12:54] <mgz> I only see it in setup.py
[13:48] <marcoceppi> mgz: `dpkg -l | grep juju` will give you the version :)
[13:49] <mgz> that's not much use for using within juju itself in a user agent string though :)
[13:49] <marcoceppi> mgz: Versions (should) hit when the go port is finished. Not sure if they're going to put them in the Python version
[13:53] <marcoceppi> Hey hazmat, what's the conversation happening on the mailing list about the merge for docs?
[13:53] <hazmat> marcoceppi, its the thread you started.. https://lists.ubuntu.com/archives/juju/2012-May/001568.html
[13:53] <hazmat> marcoceppi, my comments are here https://lists.ubuntu.com/archives/juju/2012-May/001607.html
[13:54] <marcoceppi> hazmat: that merge doesn't touch the other section of the docs. Would you like me to just update the other section as well to include the new information (I'm confused about what's holding what up)
[13:57] <hazmat> marcoceppi, yeah.. i'd prefer the getting-start doc not have a bunch of local provider specific information, and that it just link to provider specific docs where that information should reside
[13:57] <hazmat> the information added for local provider will need to grow for other corner cases issues..
[13:57] <hazmat> such as ufw usage or existing dns server on the host
[13:58] <marcoceppi> hazmat: cool, I'll move it over to that section. In that respect should we also move getting started EC2? Actually I'll reply back to that thread...
[13:58] <hazmat> marcoceppi, yeah.. i'd like to see it start of with a configuring a provider section, which just looks to individual provider pages, and then continues forward with keygen and bootstrap
[13:58] <hazmat> s/looks/links
[13:59] <marcoceppi> good point
[13:59] <marcoceppi> I'll also add in MAAS configuration since it seems to be missing
[13:59] <hazmat> marcoceppi, awesome, thanks
[14:00] <m_3> marcoceppi: hey... btw, how'd the maas environment work out?  that was pure kvm VMs right?
[14:01] <marcoceppi> m_3: I used VirtualBox and it went pretty well: http://marcoceppi.com/2012/05/juju-maas-virtualbox/ It's not the *best* MAAS experience because WOL doesn't seem to work, but it was a fun starting point
[14:01] <m_3> marcoceppi: awesome man!
[14:03] <jcastro> woo, queue is 19!
[14:04] <marcoceppi> m_3: I look forward to trying again with some real metal and maybe Xen
[14:05] <m_3> marcoceppi: yeah I'm itching to get a little more hardware right now... should have some extra boxes after the move
[14:09] <jcastro> I think I will get another hp microserver
[14:09] <jcastro> see what you guys started?
[14:09] <m_3> ha!
[14:09] <m_3> I really like mine
[14:10] <marcoceppi> I wonder how hard it would be to create a "public" MAAS service
[14:10] <m_3> I think the extra $$ for the ilo sucks... but it's worth it
[14:11] <m_3> marcoceppi: just for demo purposes?  or as a real service
[14:11] <marcoceppi> demo purposes at first, but ideally a public multi-tenant MAAS setup
[14:11] <m_3> hmmm... sounds hard
[14:12] <m_3> I'd love to see a simple way to try juju in general though (not nec maas)
[14:13] <marcoceppi> I'd have to look into how the users work in MAAS, suppose that would be the real limiter. If you could assign units from a larger pool to users directly in MAAS I don't think it'd be that hard, if not it would probably be an uphill battle
[14:14] <marcoceppi> m_3: LXC :P
[14:15] <jcastro> what I want to see
[14:15] <jcastro> is a workload, one on MAAS, and one on Openstack
[14:15] <jcastro> and see if there's a difference
[14:15] <jcastro> and them compare/contrast the pros/cons of doing certain workloads on certain configs
[14:16] <m_3> jcastro: roger... that's planned if we can scrounge the hw
[14:17] <m_3> jcastro: we discussed waiting until constraints could handle "rack-local" deployments... but we really wouldn't have to wait if it's just one rack :)
[14:17] <jcastro> m_3: hey so, assuming your out this week for gluecon, what's your ideal review day?
[14:17] <m_3> it's all rack local
[14:17] <jcastro> I think I'll start penciling in a schedule
[14:17] <m_3> jcastro: Tuesday
[14:18] <m_3> jcastro: ranked preferences T, Th, W
[14:18] <jcastro> perfect
[14:18] <m_3> jcastro: man thanks for setting that stuff up... it'll help out a bunch
[14:19] <jcastro> it's all juan and kapil
[14:19] <jcastro> I just knew what to steal
[14:20] <jcastro> unless I get more comments on the proposal I'll just implement the new wiki page today
[14:20] <jcastro> and then we'll be good to go
[14:20] <m_3> cool
[14:21] <jcastro> after that we have some governance changes
[14:21] <jcastro> which sound dumb but we need them, and we'll likely never use them (a council for the charm store etc.)
[14:21] <jcastro> but jono and I will do all that work
[14:22] <m_3> hazmat: I'll follow up with clint and the lp peeps later today and try to get a non-interruptive fix for the oneiric charms... not happy with their current suggestions for restacking, but don't have anything better
[14:22] <m_3> jcastro: understood
[14:23] <m_3> time to run to gluecon... catch y'all later
[14:41] <mhall119> m_3: do you know of any problems with the postgresql charm and relations for precise?
[14:45]  * nathwill is working on updated owncloud charm... 
[14:46] <nathwill> i think i'm going to try and deal w/ the sqlite vs. mysql by setting a bool standalone config option...
[14:56] <avoine> mhall119: I do, you must be carefull that it's not a hostname that goes into your pg_hda.conf
[14:57] <avoine> because it must be an IP address
[14:59] <mhall119> avoine: thanks, I'll check on that
[15:43] <nijaba> SpamapS: just left the charmers team to join the inactive one...
[15:52] <SpamapS> nijaba: cool hah.. you're way ahead of me. :)
[15:52] <nijaba> SpamapS: not that I am that proud of it, but it's the right place for me in all fairness
[15:53] <SpamapS> nijaba: indeed, we need to be *realistic*
[15:56] <SpamapS> nijaba: I just set it up so that inactive-charmers retains write access to the charms though, so that you can keep doing work on the charms you care about
[16:00] <nijaba> SpamapS: cool, thanks
[16:01] <SpamapS> nijaba: so.. you going to keep working on limesurvey and roundcube?
[16:02] <nijaba> SpamapS: trying to.  hoping that the madness of the past few month will go down soon
[16:03] <SpamapS> nijaba: http://fewbar.com/charms/need-maintainers.txt ...
[16:04] <nijaba> SpamapS: k
[16:13] <marcoceppi> SpamapS: just updated my charms
[16:18] <SpamapS> marcoceppi: woot! thanks
[16:22] <negronjl> 'morning all
[16:24] <SpamapS> negronjl: good morning. Note that you are off the wall of shame completely now. :)
[16:24] <SpamapS> ^5
[16:25] <negronjl> SpamapS: ahh ... I have regained some of my honor ... :)
[16:25] <SpamapS> negronjl: most importantly, you have avoided my nagspam
[16:42]  * jcastro fixes his charm maintainership
[16:45] <jcastro> SpamapS: ok I see you created inactive charmers
[16:45] <jcastro> should I move people there?
[16:46] <marcoceppi> jcastro SpamapS what's the inactive criteria?
[16:46] <jcastro> marcoceppi: not wanting to review charms
[16:47] <jcastro> basically, ~charmers are people who want to review charms and promulgate
[16:48] <marcoceppi> Ah, gotchya
[16:49] <jcastro> marcoceppi: for canonical employees I'll assign them days, for you and brandon you guys can just work on it whenever you want like you do now
[16:49] <jcastro> negronjl: mire, which day is good for you for reviews?
[16:50] <SpamapS> hm
[16:50] <SpamapS> we need --force to be able to force even E:'s
[16:50] <jcastro> SpamapS: you're preferred day is friday still?
[16:50] <negronjl> jcastro:  In order of preference ... Mon, Tues, Wed
[16:50] <SpamapS> jcastro: err, no way
[16:51] <SpamapS> jcastro: friday is *slammed*
[16:51] <SpamapS> jcastro: I already have patch pilots on friday :)
[16:51] <negronjl> SpamapS: Are you talking about --force in promulgate ?
[16:51] <SpamapS> negronjl: yeah
[16:51] <SpamapS> negronjl: it needs to ignore everything
[16:51] <jcastro> SpamapS: ok what days work for you?
[16:51] <negronjl> SpamapS: I don't think we should --force on errors
[16:51] <SpamapS> negronjl: I need to promulgate pictor, so that Dustin can commit/push to it for instance
[16:51] <jcastro> jamespage: what days work for you for charm reviews?
[16:51] <SpamapS> negronjl: its necessary
[16:51] <SpamapS> negronjl: shouldn't, but need the ability to do things wrong sometimes.
[16:52] <negronjl> SpamapS: My thoughts are that if we have an E: and you still want to promulgate it then, maybe the proof script needs to re-think what an E; is
[16:52] <SpamapS> negronjl: not having a maintainer *is* an E
[16:52] <jcastro> lynxman: are you going to be able to do 4h a month on charm reviews? lmk.
[16:52] <SpamapS> but I'm promulgating *so somebody else can fix it*
[16:52] <lynxman> jcastro: sure :)
[16:52] <SpamapS> negronjl: keep in mind that promulgate is also to *change* the branch, not just to add a new one
[16:52] <negronjl> SpamapS: A thought is .... why don't _we_ fix it and then promulgate it
[16:52] <jcastro> lynxman: what days work for you?
[16:53] <negronjl> SpamapS: for maintainer that is
[16:53] <SpamapS> negronjl: because I'd rather the commit that says Dustin is the maintainer come from Dustin. :)
[16:53]  * SpamapS just downgrades promulgate and handles it
[16:53] <lynxman> jcastro: just assign me whichever days you need mmore people :)
[16:53] <SpamapS> negronjl: --force should mean --force. Not --ignore-warnings
[16:53] <jcastro> SpamapS: ok, just need what days are good for you and we're done
[16:54] <SpamapS> negronjl: its wrong, but we're not children, we should have powers to override policy when its getting in the way of GTD :)
[16:54] <negronjl> SpamapS: ok ... I'm convinced
[16:54] <SpamapS> jcastro: M,W,Th
[16:54] <negronjl> SpamapS: Are you fixing it or should I ?
[16:55] <SpamapS> negronjl: Heh, I've moved on. Perhaps we can fix it if it ever comes up again? :)
[16:55] <negronjl> SpamapS: lol ... all that convincing for nothing :)
[16:56] <SpamapS> negronjl: I'm a real s*** like that.
[16:56] <SpamapS> negronjl: I trust you to prioritize it appropriately. :)
[16:56]  * SpamapS translates: DO IT NOW OR SPAMAPS WILL CRY
[16:57] <negronjl> SpamapS: lol ... I'll get it done in a minute
[16:58] <SpamapS> You know what we need tho? We need an audit log of promulgate's activities.
[16:58] <SpamapS> Like, I'd like to see who promulgated what
[16:59] <negronjl> SpamapS: good idea ... when can you have it ready :)
[16:59] <marcoceppi> SpamapS: how would you audit that?
[16:59] <SpamapS> marcoceppi: I just want it available. I don't know how I'd use it.
[17:00]  * SpamapS is like Johnny 5.. need iiiinnnpput
[17:00] <marcoceppi> Right, how would you track that though? Webservice?
[17:00] <marcoceppi> I don
[17:00] <marcoceppi> I don't think there's a way to track that in lp currently
[17:01] <SpamapS> LP probably has it in some way
[17:01] <SpamapS> just not exposed
[17:02] <SpamapS> Even if its just "last touch by..x"
[17:02] <SpamapS> marcoceppi: launchpad logs almost everything that the distro package publisher does
[17:02] <SpamapS> I want similar logs for charms
[17:05] <negronjl> SpamapS: do we want warnings to abort promulgate by default ?
[17:05] <negronjl> SpamapS: you could always use --force to override them
[17:06] <jamespage> jcastro, wednesdays would be good for me
[17:07] <SpamapS> negronjl: I like that it aborts on warnings
[17:08] <SpamapS> negronjl: but I wonder if we should separate the two concerns
[17:08] <SpamapS> negronjl: E's are definitely "never do this unless you know what you're doing" .. but warnings might just be "I'm moving the ownership of a branch so a team can improve it"
[17:08] <negronjl> SpamapS: for now ... let's leave it aborting on warnings as well as errors .... it gives you the opportunity to decide whether you want to fix the warnings or not.
[17:09] <negronjl> SpamapS: you can always just use the --force switch and override it all but, promulgate gives you a chance to decide
[17:09] <SpamapS> negronjl: right, I'm thinking --ignore-warnings should have more friendly language than --force
[17:09] <negronjl> SpamapS: I can just put them both
[17:10] <SpamapS> negronjl: I think it makes sense. --force would ignore both, --ignore-warnings would naturally just ignore warnings.
[17:10] <negronjl> SpamapS: ok .. I'll have it done in a minute
[17:10] <SpamapS> heh.. doh.. my wall of shame hasn't been updating for about 19 reasons
[17:10] <SpamapS> now I just figured out I was still using bzr+ssh so the cron job that did bzr pulls was broken :-P
[17:11] <negronjl> SpamapS: shame on you :)
[17:11] <SpamapS> indeed
[17:20] <negronjl> SpamapS: https://code.launchpad.net/~negronjl/charm-tools/ignore-warnings-modified-force/+merge/107082
[17:23] <SpamapS> negronjl: approved, thanks for being my bit^H^Hest friend. :)
[17:28] <negronjl> SpamapS: lol ... no worries f^H^H^H^^Hriend :)
[17:30] <lynxman> lots of ^H going around eh? :P
[17:31] <SpamapS> lynxman: yeah, make sure you have all your shots ;)
[17:31] <lynxman> lol
[17:32] <hazmat> negronjl, please don't reject the branches
[17:32] <hazmat> for oneiric
[17:33] <hazmat> negronjl, this is a hosting problem not an mp issue
[17:33] <negronjl> hazmat: ahh ...
[17:33] <hazmat> negronjl, there's discussion on the lists about
[17:33] <negronjl> hazmat: I'll leave them alone for now then ...
[17:33] <negronjl> hazmat: what list ?
[17:33] <hazmat> negronjl, all of them ;-)
[17:33] <negronjl> hazmat: damn ....
[17:33] <negronjl> There going to be a lot more ^H flying around here
[17:34] <negronjl> I rejected two MPs already because of that ...
[17:34] <hazmat> negronjl, yeah.. i saw, i'm putting them back into needs review.. we'll hopefully have the branches back this week
[17:35] <negronjl> hazmat: can you also put a comment as to why you are putting them back on ... That way It will remind me of what happened ...
[17:35] <negronjl> hazmat: It will also prevent another poor soul to do what I just did .. :)
[17:36] <hazmat> negronjl, these are the branches with problems fwiw http://paste.ubuntu.com/1003347/
[17:36] <hazmat> negronjl, yup, i'm putting comments in them as well (re mp)
[17:37] <hazmat> personal charm branches are fine
[17:37] <negronjl> hazmat: thx
[17:39] <SpamapS> hazmat: isn't that like.. *all* of the official branches?
[17:40] <hazmat> SpamapS, just oneiric
[17:40] <hazmat> SpamapS, and most of them yes
[17:40] <hazmat> SpamapS, these 6 seem to be okay.. http://jujucharms.com/charms/oneiric
[17:40] <SpamapS> hazmat: hazmat mumble-server was added after the distro branch
[17:41] <hazmat> SpamapS, yeah.. i suspect that was a reason
[17:41] <SpamapS> hazmat: glance, rabbit, and nova* were all already in precise.. so that must have protected them
[17:41] <hazmat> SpamapS, namely they where pushed to after the distro series stuff
[17:41] <hazmat> SpamapS, well there are some that where in precise already that are showing up here
[17:41] <SpamapS> hazmat: so is the problem just the bad stacking right now?
[17:41] <hazmat> zookeeper comes to mind
[17:41] <hazmat> SpamapS, yes
[17:41] <hazmat> er.. aren't showing up
[17:42] <SpamapS> hazmat: so IIRC, we just need to rename all the precise branches, then co/reconfigure all the oneiric branches, then re-rename the precise branches
[17:52] <hazmat> SpamapS, yeah.. i've been talking to m_3 about it
[17:52] <hazmat> the problem arose in renaming the precise branches
[17:52] <hazmat> SpamapS, it would be easier to avoid the distro tools and just push the branches to a new series location, and promulgate the new ones
[17:56] <SpamapS> hazmat: we *must* use at least some of the tools in LP because the REST API does not allow marking a series as "Active Development"
[17:57] <hazmat> SpamapS, that's distinct from the branch mangement
[17:58] <SpamapS> hazmat: it is, but its completely wrapped up in branch-distro at this point
[17:58] <SpamapS> so, we'll need to submit patches to LP to decouple the two
[17:59] <hazmat> SpamapS, easy to just have a separate charm specific tool for it imo
[18:03] <SpamapS> hazmat: right, but it has to be run inside LP, by a LOSA.. so we can't just do it w/o getting patches into LP
[18:03] <hazmat> SpamapS, ugh. oh
[18:06] <hazmat> SpamapS, its a one line fix to launchpad/lib/lp/codehosting/branchdistro.py to switch from stacking on branch name to id is my understanding
[18:07] <hazmat> so that we can rename the branch afterwards
[21:04] <mhall119> jcastro: do you know if anybody is working on any 3d rendering charms?
[21:05] <jcastro> not afaict
[21:05] <jcastro> 83 official charms now, queue down to 15.
[21:05] <jcastro> nice work fellas, that's a spicy meatball!
[21:06] <mhall119> nice
[21:16] <negronjl> SpamapS: https://code.launchpad.net/~clint-fewbar/charm-tools/add-proper-help/+merge/107118  ... Approved
[21:19] <SpamapS> negronjl: danke
[21:19] <negronjl> SpamapS: np
[21:21] <SpamapS> negronjl: now to add bash completion :)
[21:21] <negronjl> SpamapS: heh ... cool
[21:21] <SpamapS> tired of hitting charm rev tab tab tab tab
[21:31] <negronjl> jcastro: ping
[21:32] <negronjl> jcastro:  about patch pilot
[21:41] <mhall119> woot!  Got my summit charm working
[21:47] <nathwill> so would juju-log be the best way to communicate an autogenerated password to the admin during a CMS setup?
[21:59] <SpamapS> $ charm get n
[21:59] <SpamapS> nagios                 nfs                    nova-cloud-controller
[21:59] <SpamapS> newrelic-php           node-app               nova-compute
[21:59] <SpamapS> mmmmmm... tab completion
[22:07] <SpamapS> hazmat: sorry to be a pest, but whats the status on an 'enable proposed' option?
[22:07] <hazmat> SpamapS, i tried out the branch and its working
[22:08] <hazmat> SpamapS, i'll propose it for merging
[22:08] <SpamapS> hazmat: sweet, thanks :)
[22:10] <negronjl> SpamapS: what's the option ( enable proposed ) for ?
[22:10] <SpamapS> negronjl: so we can test updates in precise-proposed
[22:10] <negronjl> SpamapS: ahh... thx
[22:12] <hazmat> enabled via juju-origin: proposed
[22:16] <negronjl> SpamapS: https://code.launchpad.net/~clint-fewbar/charm-tools/add-bash-completion/+merge/107127 ... approved
[22:17] <SpamapS> negronjl: we are on a roll. :)
[22:18] <SpamapS> 35 charms out of 78 need maintainers.
[22:18] <negronjl> SpamapS: heh ... we are .  We should now be off the hook for reviewing for a week :)
[22:18] <SpamapS> Whoo! halfway there
[22:18] <SpamapS> negronjl: you should. I haven't reviewed hardly anything ;)
[22:19] <negronjl> SpamapS: I get bored waiting for CloudFoundry to finish ( and then do it again and again and again ) so, I review ( apparently sometimes I break reviews )