[00:33] <tjaalton> sigh.. the openchrome uses CDBS, and the documentation is offline
[00:34] <tjaalton> ah, the package has some
[01:12] <tjaalton> ffs.. the openchrome package is crap.. I can't build the source after test building the binary
[01:12] <tjaalton> "unrepresentable changes to source"
[01:12] <bryce> erf
[01:21] <tjaalton> finally
[01:23] <tjaalton> now to bed, bye! ->
[01:32] <bryce> cya
[02:50] <ubotu> New bug: #162740 in xserver-xorg-video-intel (universe) "blender-bin crashed with SIGSEGV when starting it (DRI related)" [Undecided,Incomplete] https://launchpad.net/bugs/162740
[03:25] <ubotu> New bug: #42990 in xkbutils "XGL breaks setxkbmap (kde)" [Medium,Triaged] https://launchpad.net/bugs/42990
[03:52] <bryce> tjaalton: hmm, I added my blog to planet-ubuntu a while ago, yet my past posts did not show up.  Perhaps it only pulls new ones?  I'll have to mess with it
[06:28] <tjaalton> bryce: yes, new ones only
[06:44] <tjaalton> and maybe if you modify an older post
[06:47] <bryce> nope; I tried modifying the bug tool post (added a screenshot) but it didn't show up
[06:48] <bryce> I'll do another post and check that it shows up
[06:52] <bryce> wow, all my inkscape bug work over the holidays bumped my karma up quite a bit
[06:53] <tjaalton> heh
[06:55] <tjaalton> there's an upstream intel branch about which should fix EXA slowness, and I tried to build it, but failed. I'll try again today
[06:55] <tjaalton> "intel-batchbuffer"
[06:59] <bryce> oh btw, brian murray found a bug in the greasemonkey tag script where if there is a + or & in the description, the tool may change the description inappropriately
[07:05] <tjaalton> ok, I'll update it
[07:07] <bryce> tjaalton: has -intel fixed the issue that prevents DRI for virtual displays larger than 2048x2048?
[07:08] <bryce> (bug #164049)
[07:08] <ubotu> Launchpad bug 164049 in xserver-xorg-video-intel "intel xorg driver disables direct rendering for virtual display larger than 2048" [Low,Confirmed] https://launchpad.net/bugs/164049
[07:08] <bryce> I ask because in bug 174745, they report the crash was caused by having a virtual size over 2048x2048
[07:08] <ubotu> Launchpad bug 174745 in xserver-xorg-video-intel "xorg lockup when screen is rotated" [Undecided,Confirmed] https://launchpad.net/bugs/174745
[07:19] <tjaalton> no, it requires TTM
[07:19] <tjaalton> AIUI
[07:54] <bryce> ahh
[08:19] <bryce> yay!  all -intel bug triaging is caught up :-)
[08:20] <tjaalton> heh, I noticed that my "launchpad-x" mailbox filled up :)
[08:20] <bryce> :=)
[08:21] <bryce> I got a couple new widescreen monitors today, but vowed to get -intel triaging done before I even opened the boxes
[08:21] <tjaalton> hehe, what models?
[08:21] <bryce> BenQ
[08:21] <tjaalton> sweet, I bought a BenQ last month
[08:22] <bryce> I've never bought benq before, but I did some pretty thorough research and they came out on top for my requirements
[08:22] <bryce> they also were quite highly rated on newegg, so I'm very optimistic
[08:23] <bryce> but...  if I'm offline all day tomorrow you'll know why ;-)
[08:23] <tjaalton> heh, ok!
[08:23] <tjaalton> mine is a 24" with hdmi input
[08:24] <bryce> oh maybe I've got the same
[08:24] <tjaalton> so even if we won't get a new telly anytime soon, I'm still able to get a PS3 and use the full resolution
[08:24] <bryce> MNTR BENQ|24" LCD 16MS HDMI FP241W
[08:24] <tjaalton> yep, same model
[08:25] <tjaalton> you've certainly done your research :)
[08:25] <bryce> 8-)
[08:25] <tjaalton> I could've bought a 24" model half the price, but I knew this one had a higher quality panle
[08:25] <tjaalton> -el
[08:26] <bryce> how's HDMI work?  dell was asking me about if we've done testing of that
[08:26] <bryce> yeah
[08:26] <tjaalton> I don't have a gfx card with HDMI
[08:26] <bryce> ah
[08:26] <tjaalton> apparently there are still issues
[08:26] <bryce> me either
[08:27] <bryce> have you played with s-video?
[08:27] <tjaalton> at least alsa lacks some support for transporting audio over it, but I guess it's almost ready
[08:27] <tjaalton> my old laptop (T23) has an s-video port
[08:28] <bryce> here's what you need for your TV:  http://blog.wired.com/gadgets/2008/01/ces-2008-keynot.html
[08:29] <tjaalton> hmm, let me recover the firefox sesssion
[08:29] <tjaalton> -s
[08:31] <tjaalton> ah, that one.. a bit pricey, but otherwise seems quite nice :)
[08:35] <tjaalton> I wonder how much power that monster will suck
[08:36] <bryce> yeah no kidding
[08:36] <bryce> but it sounds like it'd play youtube videos really well, so hey
[08:39] <tjaalton> yep, 400x300 (?) clips on a 4096x2160 screen :)
[08:39] <bryce> awwsome
[08:41] <bryce> oh btw, I learned a mechanism for marking bugs as "needs forwarded upstream" and started marking -intel bugs that look ready to report upstream
[08:42] <bryce> I wanted to focus on getting through the preliminary triage so put off reporting them upstream for now, but plan to spend a day or so in the next week or two pushing bugs upstream
[08:42] <tjaalton> ok, cool
[08:43] <tjaalton> the newest version should fix quite a fex bugs
[08:43] <bryce> excellent
[08:44] <bryce> the way to mark bugs as needs forwarded is to go Affects +Project, then submit without entering a bug url.  Easy
[08:44] <bryce> if you run across other bugs that look ready to go upstream, mark 'em
[08:50] <tjaalton> ok, good to know
[09:05] <ubotu> New bug: #181437 in linux-restricted-modules-2.6.24 (restricted) "Segmenation fault when executing aticonfig" [Undecided,New] https://launchpad.net/bugs/181437
[09:06] <ubotu> New bug: #181434 in xorg (main) "Blue screen with videos with Hardy Xorg 7.3" [Undecided,New] https://launchpad.net/bugs/181434
[09:34] <bryce> tjaalton: is the new version 2.2.1?
[09:34] <bryce> sounds like it'll fix VT switching and some startup issues
[09:37] <tjaalton> it's from the stable branch, so it'll become 2.2.1
[09:37] <tjaalton> not released yet though
[09:38] <bryce> gotcha
[09:38] <bryce> sounds like 2.2.1 is scheduled to be released within the month
[09:40] <bryce> 2.3 is planned for early March and will focus on modesetting bugs
[09:40] <tjaalton> it was supposed to be out before christmas
[09:40] <tjaalton> but yeah
[09:40] <bryce> heh
[11:01] <tjaalton> sigh, pretty annoying bugs in the xserver.. keys are stuck when you press then long enough
[11:01] <tjaalton> like, when playing with compiz settings like fire :)
[12:19] <ubotu> New bug: #179164 in xorg (main) "Xorg failsafe mode throws out Xorg.log" [Undecided,New] https://launchpad.net/bugs/179164
[13:05] <ubotu> New bug: #181485 in xserver-xorg-video-ati (main) "ati driver blocks the system" [Undecided,New] https://launchpad.net/bugs/181485
[15:29] <ubotu> New bug: #178935 in xserver-xorg-driver-ati (main) "screen stays off when opening laptop lid with screensaver on" [Undecided,New] https://launchpad.net/bugs/178935
[15:40] <ubotu> New bug: #181526 in xserver-xorg-input-evdev (main) "[hardy] [evdev with X Input hotplug] changes keymap to greek regularly" [Undecided,New] https://launchpad.net/bugs/181526
[18:11] <ubotu> New bug: #181568 in linux-restricted-modules-2.6.24 (restricted) "aticonfig --enable-monitor=lvds crashes X" [Undecided,New] https://launchpad.net/bugs/181568
[18:36] <ubotu> New bug: #181573 in xserver-xorg-driver-ati (main) "[Hardy]Radeon Xpress 1100 IGP: screen gets partly black for a while" [Undecided,New] https://launchpad.net/bugs/181573
[19:02] <ubotu> New bug: #181334 in newt (main) "Default console font unsuitable for debconf / whiptail" [Undecided,New] https://launchpad.net/bugs/181334
[20:31] <ubotu> New bug: #181595 in xkeyboard-config (main) "unable to type <, > and | while using Finnish layout on a 101-key keyboard" [Undecided,New] https://launchpad.net/bugs/181595
[20:50] <ubotu> New bug: #181602 in xserver-xorg-video-ati (main) "ATI driver update causes Display Corruption on ATI Radeon 9500 AGP" [Undecided,New] https://launchpad.net/bugs/181602
[23:07] <ubotu> New bug: #181121 in linux-restricted-modules-2.6.24 (restricted) "glplanet crashed with SIGSEGV" [Undecided,Incomplete] https://launchpad.net/bugs/181121
[23:25] <ubotu> New bug: #181638 in linux-restricted-modules-2.6.24 (restricted) "ipw3945 fails to load" [Undecided,New] https://launchpad.net/bugs/181638


[01:33] <lifeless> SpamapS: around ?
[01:33] <lifeless> SpamapS: can you perhaps lurk in #maas, plenty of cross over i suspect, and we get lots of juju q's in there.
[05:15] <EvilMog> I have officially figured out the killer Juju app, although I doubt I can get the package maintainers to make one
[05:15] <EvilMog> John the ripper + MPICH2
[05:15] <EvilMog> build a charm for that and you'd have an instant password cracking cluster, and every infosec junky would have it in their private cloud
[05:54] <SpamapS> EvilMog: I'll take that challenge
[05:54] <EvilMog> that would be awesome
[06:01] <SpamapS> EvilMog: they're both packaged, so thats at least easy
[06:01] <EvilMog> ypi
[06:01] <EvilMog> you'll want to use the latest jtr source
[06:02] <EvilMog> the packaged one doesn't have mpich support
[06:02] <EvilMog> need to edit the makefile uncomment a few lines to add it in
[06:08] <EvilMog> actually I'll be honest I'd even be happy with an auto mpich setup and pre-setup the hosts files and node information for mpich2
[06:08] <SpamapS> EvilMog: why isn't the latest one packaged?
[06:08] <EvilMog> because it changes so often
[06:08] <SpamapS> ah so you're just one of those devs who thinks "latest" == "best" ;)
[06:08] <EvilMog> what you'd want is the latest code-train with unofficial jumbo-5 patch
[06:09] <EvilMog> theres 2 releases, theres the stable but missing tons of features, then theres the jumbo patch which supports MPI and way more password formats
[06:10] <EvilMog> I'm just a heavy john user, and virtually every cluster I've built has used the latest code train with most recent jumbo release
[06:10] <EvilMog> this also greatly improves crack performance
[06:10] <SpamapS> EvilMog: it just baffles my mind that an OS released < 2 months ago would have something so out of date
[06:11] <EvilMog> the debian base package uses the stable tree
[06:11] <SpamapS> EvilMog: sounds to me like john+mpi is a fork
[06:11] <EvilMog> its not
[06:11] <EvilMog> its an official build
[06:11] <EvilMog> theres 2 releases stable and unstable
[06:11] <EvilMog> the debian base package uses stable
[06:12] <SpamapS> I only see "official free" and "community enhanced"
[06:12] <EvilMog> same thing
[06:12] <EvilMog> official free = stable
[06:12] <EvilMog> which is whats packaged
[06:12] <EvilMog> community enhanced is where the good stuff is
[06:13] <EvilMog> including all the performance enhancements
[06:14] <SpamapS> Ok https://launchpad.net/~pi-rho/+archive/security seems to have jumbo-5 packaged
[06:14] <EvilMog> nice
[06:14] <EvilMog> it never used to
[06:14] <SpamapS> just have to copy that source package and verify the sources
[06:14] <EvilMog> so the only thing you neeed to do then is verify they compiled it with mpich support
[06:14] <EvilMog> http://openwall.info/wiki/john/parallelization
[06:15] <EvilMog> theres 2 lines that need to be uncommented in the make file
[06:15] <SpamapS> https://launchpadlibrarian.net/107245212/buildlog_ubuntu-precise-amd64.john_1.7.9-jumbo-5-1ubuntu1~ppa2~p_BUILDING.txt.gz
[06:15] <EvilMog> CC = mpicc -DHAVE_MPI -DJOHN_MPI_BARRIER -DJOHN_MPI_ABORT
[06:15] <EvilMog> MPIOBJ = john-mpi.o
[06:15] <SpamapS> no mention of mpich
[06:16] <imbrandon> morning
[06:17] <SpamapS> DEB_MAKE_EXTRA_ARGS := SYSTEMWIDEFLAGS="-DJOHN_SYSTEMWIDE=1 -DJOHN_SYSTEMWIDE_EXEC=/usr/lib/john"
[06:17] <SpamapS> EvilMog: looks like it will need some work
[06:17] <SpamapS> imbrandon: alo
[06:17] <EvilMog> yeah, I'm working on a build script
[06:17] <EvilMog> thinking wget the source, apt-get install the pre-reqs
[06:17] <SpamapS> imbrandon: You'll be excited to know I'm uploading PHP 5.4.4 to quantal right now
[06:18] <EvilMog> find and edit makefile
[06:18] <imbrandon> sweet
[06:18] <EvilMog> then make and install package
[06:18] <EvilMog> so if the mpich2 environment is pre-setup I can just call the build script as a post install
[06:18] <imbrandon> gonna try for backport ?
[06:18] <imbrandon> ahhaha
[06:19] <SpamapS> imbrandon: you already know what that will be the problem
[06:19] <imbrandon> yup
[06:19] <SpamapS> EvilMog: *edit* the makefile?
[06:19] <SpamapS> EvilMog: no wait to configure it w/ cmdline args?
[06:19] <SpamapS> -CFLAGS = -c -Wall -O2 -fomit-frame-pointer -I/usr/local/include $(OMPFLAGS)
[06:19] <SpamapS> +CFLAGS = -c -Wall -O2 -fomit-frame-pointer -fPIC -I/usr/local/include $(OMPFLAGS) $(SYSTEMWIDEFLAGS)
[06:20] <SpamapS> thats the diff the package has
[06:20] <imbrandon> SpamapS: is there a little SpamapS yet ? hehe
[06:21] <SpamapS> imbrandon: 2 weeks old now
[06:21] <imbrandon> oh wow, i'm so behind
[06:21] <imbrandon> Congrats man
[06:21] <SpamapS> imbrandon: and this would be the 3rd child process I've forked
[06:21] <EvilMog> that works too
[06:21] <imbrandon> :)
[06:22] <EvilMog> I'm just a very hacky analyst who does things the hard way out of ignorance
[06:26] <EvilMog> http://download.openwall.net/pub/projects/john/contrib/mpi/John_the_Ripper_on_a_Ubuntu_10.04_MPI_Cluster.pdf
[06:27] <SpamapS> EvilMog: the GPG key that openwall uses is pretty crusty
[06:27] <EvilMog> if that helps
[06:27] <EvilMog> more than likely
[06:27] <SpamapS> pub   1024R/295029F1 1999-09-13
[06:28] <EvilMog> ick
[06:28] <SpamapS> yeah its like they don't care
[06:28] <imbrandon> 1999
[06:28] <EvilMog> you'd think the authors of hash cracking software would give a damn :P
[06:29] <SpamapS> EvilMog: actually I'd think the uathors of hash cracking software would run a single evil mirror just to see if anybody checked
[06:29] <EvilMog> sadly though I have to sneak off to work, I'll be back on in about 8 hours
[06:29] <EvilMog> you know that would be entertaining
[06:30] <SpamapS> I have a reasonably well filled out web of trust here.. and I can't find any Debian developers who have signed it yet
[06:30] <imbrandon> time for fooood, my tummy is growling
[06:30] <SpamapS> or even any transitive
[06:36] <SpamapS> Wow finally I found one like 3 levels deep thats in my keys
[06:56] <imbrandon> mmm coco-puffs
[06:59] <SpamapS> EvilMog: looks to have built fine
[07:52] <SpamapS> alright.. skeleton john the ripper charm done
[07:52] <SpamapS> complete w/ mpich2 scale-out (hopefully)
[07:53] <SpamapS> If I can add gluster/ceph .. I am a god ;)
[08:51] <SpamapS> EvilMog: lp:~clint-fewbar/charms/precise/john/trunk  .. needs to setup the SSH keys between hosts, but mpi kinda sorta works
[08:51] <SpamapS> thinking this should just be a generic 'mpich2' charm
[08:51]  * SpamapS goes to bed
[12:41] <jcastro> jml: the "ubuntu" charm I just recommended to you on askubuntu had some problems yesterday, I don't know if we fixed it
[12:42] <imbrandon> jcastro: what was wrong with it ?
[12:48] <koolhead17> jamespage, the Juju on LXC issue still giving issues
[12:49] <koolhead17> in one day it created good GB of logs
[12:50] <jml> just trying to find documentation on how to set up environments.yaml for ec2
[12:50] <jml> looks like it's not in the package docs or on the wiki. trying code tree instead.
[12:54] <imbrandon> jml: https://juju.ubuntu.com/docs/getting-started.html#configuring-your-environment-using-ec2
[12:55] <jcastro> jml: https://juju.ubuntu.com/docs/getting-started.html#introduction
[12:55] <jcastro> imbrandon: it didn't launch
[12:55] <jml> ta
[12:55] <jml> jcastro: how would I have found that from https://juju.ubuntu.com?
[12:55] <imbrandon> jcastro: ahh
[12:55] <jcastro> on the Documentation link
[12:55] <jcastro> but you're right, the webpage sucks
[12:56] <jcastro> we're supposed to have a new one
[12:56] <imbrandon> jml: there is a Documentation link on the right, but its not clear, i'm gonna try and fix that today
[12:56] <jcastro> I wonder if we can get rid of all that marketing crap on it and put the useful information
[12:56]  * jcastro will ask
[12:57] <jml> what are control-bucket and admin-secret?
[12:57] <jcastro> look at the note underneath
[12:58] <jcastro> Note If you already have an AWS account, you can determine your access key by visiting http://aws.amazon.com/account, clicking "Security Credentials" and then clicking "Access Credentials". You'll be taken to a table that lists your access keys and has a "show" link for each access key that will reveal the associated secret key.
[12:58] <jcastro> oh
[12:58] <jcastro> I see what you mean
[12:58] <jcastro> those are generated for you
[12:58] <imbrandon> its a s3 bucket name
[12:58] <imbrandon> if its not made it will make it for you
[12:59] <jml> so I don't have to specify those?
[12:59] <imbrandon> yes you have to specify those but the are filled in if you followed the doc
[13:00] <jml> imbrandon: oh right. I followed another, different doc first that had me specify a local environment.
[13:00] <jml> fun times, eh?
[13:00] <imbrandon> hehe
[13:00] <imbrandon> right :)
[13:01] <jcastro> ugh, this doc needs some work
[13:01] <imbrandon> basicly they can be anything as long as they are unique to the env
[13:01] <jcastro> this LXC section sucks, I'll work on it today
[13:01] <imbrandon> jcastro: yes , yes it does, i've been doing bitesize chunks as i had time
[13:01] <imbrandon> heh
[13:02] <imbrandon> but the juju.ubuntu.com wiki needs fixed as well
[13:02] <imbrandon> can you get me access to edit that ?
[13:02] <jml> how do I set a default environment?
[13:03] <jml> jcastro: also, I get this on 'juju deploy ubuntu': Error processing 'cs:precise/ubuntu': entry not found
[13:03] <imbrandon> jml: add default: env-name to the top
[13:05] <jml> imbrandon: thanks.
[13:06] <imbrandon> jml: try "juju deploy cs:~charmers/precise/ubuntu"
[13:06] <EvilMog> thanks SpammapS I'll give it a shot in the morning shortly
[13:07] <jml> imbrandon: same problem, except cs:~charmers/precise/ubuntu
[13:08] <imbrandon> hrm
[13:08] <jcastro> yes, we noticed yesterday it was broken
[13:08] <jml> oh, that's what broken meant.
[13:08] <jcastro> jml: no unfortunately the wiki is acl'ed to ~charmers because we enable html to put whiz bang things on it
[13:09] <jcastro> jml: you should be able to bzr branch the ubuntu charm and deploy it manually
[13:09] <jcastro> bzr branch lp:charms/precise/ubuntu
[13:09] <imbrandon> jcastro: i'm in ~charmers and cant edit
[13:09] <jcastro> then "juju deploy --repository . local:ubuntu" should work
[13:09] <jcastro> imbrandon: huh, really?
[13:09] <imbrandon> yea i tried to fix it up some over the weekend and it said i had no rights
[13:10] <jml> jcastro: thanks.
[13:10] <jcastro> imbrandon: k, I'll ask to fix that
[13:10] <jcastro> jml: when clint wakes up I'll ask him what's up with that
[13:10] <imbrandon> jcastro: rockin let me know, cuz i have time to do some fixin on it today if it get worked otu
[13:10] <imbrandon> out*
[13:11] <jcastro> imbrandon: lp:juju/docs could always use love in the meantime. :)
[13:11] <imbrandon> yup already have that open :)
[13:11] <imbrandon> been working on the navigation
[13:11] <imbrandon> err secondary nav
[13:17] <imbrandon> jcastro: we should just have sphinx generate the whole juju.ubuntu.com page , its controled by the same acl ... woudlent take that much to add the front page stuff in
[13:17] <hazmat> hmmm..
[13:17] <imbrandon> err i guess its not
[13:18] <imbrandon> morning hazmat
[13:19] <imbrandon> hazmat: what ya think ? wouldent be too much work
[13:20] <imbrandon> pkgme.net is doing it that way i see
[13:20] <imbrandon> :)
[13:21] <jml> heh
[13:21]  * imbrandon waves to jml :)
[13:21] <jml> jcastro: have updated the question with the qualifiers to my success.
[13:21] <jml> I think I'm going to write something to do this for me :(
[13:22] <jcastro> jml: wait for smoser or someone else on the server team to respond
[13:22] <jcastro> you can't be the first guy to want to do this
[13:22] <imbrandon> jml: i hadent looked at your ask question yet but there are helper tools in juju-jitsu and charm-tools
[13:23] <jml> imbrandon: thanks. I'm not going to look those up right now, I'm afraid.
[13:23] <jml> jcastro: good call.
[13:26] <smoser> what are we responding to, jml
[13:26] <smoser> jcastro,
[13:26] <jcastro> smoser: http://askubuntu.com/questions/153029/tool-to-fire-up-ec2-instance-and-ssh-in
[13:27] <smoser> i swear, this seems like a trap
[13:28] <jcastro> no, a proper trap would include getting you to maintain something new
[13:28] <smoser> imo ubuntu-ec2-run does the correct thing and lets you create security groups and pass them through.
[13:30] <smoser> jml, see kirkland's cloud-sandbox in bikeshed
[13:31] <imbrandon> hazmat: ping, any idea why the copyright at the bottom of juju.u.c/docs wont show when generated automaticly , but when i run "make html" local it shows hust fine , there is a huge diffrence in the sphinx version , maybe thats it ?
[13:31] <imbrandon> s/hust/just
[13:31] <smoser> but having a tool create a security group and upload ssh keys for you seems overkill to me.  you might as well just do those things (euca-create-group, euca-import-keypair) and then use them. having each tool do that for itself doesn't make sense.
[13:35] <jml> smoser: I guess I don't see why I should have to think about those things at all when a tool could just create a disposable security group and keypair and then clean up after itself.
[13:38] <hazmat> imbrandon, dunno offhand
[13:38] <imbrandon> kk
[13:39] <hazmat> imbrandon, i imagine some delta between the build steps.. but i didn't setup the j.u.c/docs build
[13:39] <imbrandon> i'll just pull the if/else out for now, was going to move the js to the bottom anyhow
[13:39] <hazmat> imbrandon, i did setup this one.. http://jujucharms.com/docs/  and the copyright shows
[13:39] <imbrandon> rockin, kk yea likely a delta in the sphinx version then
[13:40] <hazmat> imbrandon, yeah.. 0.6.4 vs 1.1
[13:40] <imbrandon> and thats old :)
[13:40] <imbrandon> heh
[13:40] <smoser> well, you're certainly welcome to write such a tool.  patches to ubuntu-ec2-run would be welcomed, although i think it would actually better fit in the bikeshed tool.  the reason being that ubuntu-ec2-run is a single "run something" command rather than a long lived environment command (which would be required to properly manage security groups and ssh keys.
[13:42] <imbrandon> hazmat: btw i did split out the theme into its own
[13:42] <imbrandon> lp project under .... one sec
[13:43] <imbrandon> https://launchpad.net/ubuntu-community-webthemes/light-sphinx-theme
[13:43] <hazmat> smoser, a flag to just enable web and ssh seems like a nice option without mucking with security groups, ditto for lp id  or manual specify ssh key for a key to use instead of keypairs..
[13:43] <hazmat> its not about long lived, its about convience.
[13:43] <hazmat> patches welcome i know ;-)
[13:43] <smoser> well, it is long lived.
[13:44] <smoser> if you're making temporary things, then you have to clean up those things.
[13:44] <smoser> and that means you have to be around when the instance terminates to cleanup
[13:44] <hazmat> smoser, you mean the sec group as a transient thing to clean.. fair enough
[13:44] <ToyKeeper> Hi, um, I'm trying to deploy a blank unit for charm development, but I'm getting 'not found' on both cs:precise/ubuntu and cs:oneiric/ubuntu.  Any idea what I'm missing?
[13:45] <hazmat> imbrandon, cool
[13:45] <smoser> hazmat, or keypairs if you were uploading them (import-keypair). but thats not necessary, really.
[13:45] <smoser> (and you're right that 'ssh-add -L' probably is going to get you the right thing by default)
[13:48] <smoser> so i guess the security group is the only thing that would need to be temporary, and fwiw, the 'default' security group can be modified to include 'ssh'
[13:48] <smoser> at which point, you
[13:50] <jml> there's also some prior art in lp:lp-dev-utils which creates security groups and keypairs, and cleans them up on following runs.
[13:50] <smoser> you'd have nothing to clean up, and ubuntu-ec2-run "just works" . the one command extra that jml had to type would be "euca-authorize default -p 22".
[13:51] <smoser> in the end, i use the 'default' group
[13:51] <smoser> so tha tisn't an issue for me, and i have wrappers that specify '--key brickies' (which i agree would be a nice add to ubuntu-ec2-run)
[13:52] <smoser> why they default to the 'default' security group, but provide no way to default to keypairs is strange.
[14:05] <hazmat> mgz, ping
[14:05] <mgz> pong
[14:05] <hazmat> mgz, would you mind using the lbox command to submit the ostack branch?
[14:05] <hazmat> mgz, it should be a simple thing of just installing lbox , and lbox propose from within the branch
[14:05] <mgz> I'm on it, battling through go being weird about things
[14:06] <mgz> I believe I have it defeated now though
[14:06] <hazmat> mgz, k, ping me if you need any help wrt
[14:06] <hazmat> mgz, slay the dragon :-)
[14:06] <mgz> hm, don't have exp/html
[14:08] <mgz> hosted on google code after it got removed for 1.0 apparently
[14:15] <hazmat> mgz, huh.. are you installing the package or from bzr?
[14:15] <hazmat> it should be staticallly linked in the lbox bin
[14:16] <mgz> I'm trying to build the tools myself
[14:16] <mgz> which has been... interesting
[14:24] <mgz> okay, done. amusing turns out you need a trunk copy of the go source anyway.
[14:26] <mgz> ...and the lbox webbrowser launching script is broken?
[14:27] <mgz> ...ah, nope, just couldn't cope with giving up the term to lynx.
[14:29] <mgz> ...unknown files doesn't mean the branch in unclean
[14:30] <mgz> hazmat: done, not sure what exactly, but something. it posted a comment as me at least.
[14:31] <hazmat> mgz did ask you for google login info?
[14:31] <mgz> nope.
[14:31] <hazmat> mgz first time round i'd run with -v.. it is reentrant/idempotent incidentally
[14:32] <hazmat> mgz.. oh.. sorry it needs a flag to enable the reitveld integration..
[14:32] <hazmat>  lbox propose -cr -v
[14:32] <mgz> ah, now I see that the subcommands have --help too
[14:37] <mgz> ...and it failed in a fun manner
[14:37] <mgz> 2012/06/19 15:35:55 error: Failed to send patch set to codereview: Issue creation errors: {'subject': [u'Ensure this value has at most 100 characters (it has 204).']}
[14:40] <mgz> how do you spell a string slice in go...
[14:51] <mgz> dammit, there are two rietveld.go files, edited the wrong one
[14:56] <mgz> hazmat: really done now.
[14:59] <zirpu> how close is juju to being ready for production use?
[15:00] <hazmat> mgz thanks
[15:02] <robbiew> zirpu: define "production"
[15:03] <zirpu> used to build a set of instances for running a service. mostly i want to setup a set of mongodb shards and keep it running.
[15:03] <robbiew> zirpu: juju runs this -> http://www.omgubuntu.co.uk/
[15:04] <robbiew> I guess my suggestion would be to try it in a test environment, let it run a bit, and if you are satisfied with it...roll it out
[15:05] <zirpu> i'll troll the bug list too. that should help me avoid gotchas etc.
[15:07] <zirpu> s/troll/trawl/  oops. :-\
[15:07] <mgz> troll is valid, it might just be misconstrued
[15:15] <m_3> zirpu: we've been developing a set of practices for long-running juju environments... writing them up is stil tbd for this cycle tho
[15:17] <m_3> zirpu: most is prettymuch what you'd expect... freeze your charms, freeze juju.. the rest really depends on the number of people who're maintaining and need access/control
[16:28] <jcastro> negronjl: m_3: hazmat: we should talk velocity/oscon demo
[16:28] <m_3> yup
[16:29] <m_3> jcastro: now?  irc meeting in #ubuntu-meeting atm that I could hang "over"
[16:29] <jcastro> I think today sometime would be awesome
[16:31] <m_3> jcastro: see what's good for negronjl... I'm just charmpiloting the rest of the day
[16:31]  * jcastro nods
[16:32] <jcastro> whoa, holy docs queue batman
[16:40] <james_w> http://puppetlabs.com/blog/module-of-the-week-puppetlabs-openstack/
[16:40] <m_3> jcastro: I was running off of charm-tools' review-queue
[16:40] <m_3> now I see the docs queue
[16:41] <jcastro> I don't think juan has fixed the bug in the cli tool
[16:41] <jcastro> we only found it yesterday
[16:41]  * m_3 face palm
[16:43] <negronjl> jcastro, m_3: I'm here
[16:44] <negronjl> jcastro:  what bug in which tool ... I can fix it but I've been working on the maas demo
[16:44] <jcastro> your CLI review checker
[16:44] <m_3> negronjl: no biggie... jorge was mentioning the docs queue and I realized I was looking at the charm review-queue which didn't show them
[16:44] <negronjl> jcastro:  what's the issue ( or bug number )
[16:44] <m_3> I can fix it
[16:45] <jcastro> https://bugs.launchpad.net/charmworld/+bug/1002977
[16:45] <negronjl> m_3: thx
[16:45] <_mup_> Bug #1002977: Review queue should list lp:/juju/docs <Juju Charm Tools:Confirmed for negronjl> <charmworld:Fix Released by hazmat> < https://launchpad.net/bugs/1002977 >
[16:45] <hazmat> negronjl, i put some notes in the bug about what i had to change
[16:45] <m_3> negronjl: when's a good time to hang on node/mongo stuff?
[16:45] <jcastro> kapil left notes there
[16:45] <hazmat> negronjl, its slow..
[16:45] <hazmat> for interactive usage
[16:46] <negronjl> hazmat: m_3 is going to fix the cli tool
[16:47] <m_3> I see the comment on the fix
[16:48] <negronjl> m_3: i can hangout
[16:48] <m_3> jcastro: ?
[16:49] <jcastro> count me in!
[16:49] <imbrandon> nodejs ? /me wants on
[16:50] <jcastro> I'll start the hangout
[16:50] <m_3> spinning up the other machine (cam's still borked on this one)
[16:56] <jcastro> imbrandon: invited, come on in
[16:57] <imbrandon> had my headset off
[17:03] <imbrandon> bah
[17:03] <imbrandon> my connection keeps resetting
[17:04] <imbrandon> i'm just gonna not hang this time :( but yea m_3 hit me up on the node monitoring stuff after
[17:04] <imbrandon> if ya like
[17:05] <m_3> imbrandon: cool
[17:21] <jcastro> negronjl: martin's in china so I guess that means "sure, keep it."
[17:22] <negronjl> jcastro: lol
[18:04] <japage> hi - is anyone else having trouble finding cs:precise/nova-cloud-controller  in the ubuntu store?
[18:06] <hazmat> m_3, you going to strange loop?
[18:07] <m_3> hazmat: not planned
[18:07] <jimbaker> hazmat, i submitted a talk for strangeloop but it was not accepted
[18:09] <hazmat> jimbaker, bummer
[18:11] <jcastro> dang
[18:11] <jcastro> that sounded like a shoe in
[18:13] <m_3> jcastro: we just need to keep trying... juju'll gradually get more notice
[18:13] <m_3> jcastro: gluecon rejected my proposed talks even though the conference is right on target
[18:13] <jcastro> yes, we will go until mims is like superdiamond on all airlines
[18:13] <m_3> jcastro: the cool part was that there was enought mention of juju during the conference that I'll think we'll get in next year
[18:14] <imbrandon> lol
[18:14] <m_3> that pattern's not suprising with new stuff
[18:15] <m_3> unless it's huge commercial things with big marketing budgets (i.e., not juju)
[18:15] <SpamapS> japage: http://jujucharms.com/tools/store-missing
[18:15] <SpamapS> japage: it is, indeed, missing
[18:15] <japage> thanks for the link SpamapS!
[18:16] <SpamapS> japage: we are working on getting more visibility into the charm store import process
[18:16] <SpamapS> when I say working, I mean, we are aware of the problem
[18:16] <SpamapS> I don't think anybody is actually working on it directly. :-P
[18:16] <hazmat> i've asked relevant folks about it
[18:16] <SpamapS> japage: the charm store isn't really useful for production anyway.. since you can't fix any charm bugs
[18:16] <hazmat> i'll see if i can get a more proactive tooling around the issue
[18:17] <hazmat> SpamapS, you can publish a fix with a new version at the store
[18:17] <SpamapS> what we really need isn't switch-charm' but 'fork-charm'
[18:17] <SpamapS> hazmat: *I* can, but Users* cannot
[18:17] <hazmat> switch-charm still seems like the right alt solution
[18:17] <japage> SpamapS : hazmat : no worries, i was giving it a test run doing evaluations of all of the different cloud stuffs.
[18:17] <hazmat> SpamapS, what's fork-charm?
[18:17] <SpamapS> hazmat: production doesn't really involve letting third parties control your destiny at 3am :)
[18:18] <hazmat> SpamapS, their not upgrading your systems at 3am ;-)
[18:18] <imbrandon> whats charmload expecting anyhow, i couldent get it to populate mongod
[18:18] <hazmat> a deployed charm is cached within the env, the store isn't consulted again unless your upgrading.
[18:18] <SpamapS> hazmat: fork-charm would download the charm, unpack it, bump the revisioand switch the charm
[18:18] <hazmat> imbrandon, charmload?
[18:19] <imbrandon> from charmstore
[18:19] <SpamapS> hazmat: In the case where your site is broken at 3am, and the fault is found to be the charm, you must be able to fix the charm, and upgrade then
[18:19] <imbrandon> charmload and charmd
[18:19] <m_3> SpamapS: isn't that what destroy-environment is for? :)
[18:19] <SpamapS> hazmat: fault isn't always found at the time changes are made :)
[18:19] <japage> SpamapS : what kind of refresh rate does that tool tend to see?
[18:19] <SpamapS> japage: 15min
[18:19] <SpamapS> I think
[18:19] <japage> cool
[18:20] <japage> juju is a lot of magic
[18:20] <SpamapS> nah, just smoke, mirrors, and python
[18:20] <jcastro> the charms are the magic!
[18:20] <japage> lots of python
[18:21] <japage> thanks guys, super appreciate the help
[18:22] <imbrandon> hazmat: there is like -0- documents and the only info is "run charmload <mongo addr>" after 3 hours nothing in the db still
[18:22] <imbrandon> and charmd seems to run a store, but empty without i'm guessing charmload
[18:23] <imbrandon>  /charm-info?... etc all "work" but are empty
[18:23] <hazmat> imbrandon, oh.. this is the store impl
[18:24] <SpamapS> something definitel wrong with this xen box + tmux + irssi .. keyboard/buffer/something lags out after a few weeks
[18:24] <imbrandon> screen ftw :)
[18:24] <hazmat> imbrandon, i set it up once.. just to experiment, it was pretty hands off afaicr
[18:24]  * hazmat digs it up again
[18:25] <hazmat> except it picked the same db collection that i was using for the charm browser
[18:25] <imbrandon> yea like it shows a ton of stuff trying to get from getBranchTips, but never fills in the mongodb
[18:25] <hazmat> imbrandon, it populates the juju db / charms collection in mongodb
[18:25] <imbrandon> do i need to have created that db first ? i wouldent think so
[18:26] <japage> so, when something is MIA in the charms store, is there another way to go get that code and package it similarly for use? or should i just be patient?
[18:26] <SpamapS> perhaps we should be running our own parallel charm store to see if it has the same problems and results as the production one :)
[18:26] <imbrandon> SpamapS: heh i was just trying that
[18:26] <SpamapS> japage: bzr branch lp:charms/precise/foo
[18:26] <imbrandon> or was getting there
[18:26] <imbrandon> heh
[18:27] <kees> SpamapS: uuuh, why does this should a 0 line delta? :P https://code.launchpad.net/~charmers/charms/precise/sbuild/trunk/+merge/110934
[18:27] <japage> awesome
[18:27] <kees> comparing the two trees clearly shows my changes. :P
[18:27] <SpamapS> japage: put that in a dir named 'precise' under another dir which you can name anything (mine is /home/clint/charms) and then set JUJU_REPOSITORY=/home/clint/charms ... it will now be local:charms/precise/foo (assuming metadata.yaml has name: foo)
[18:28] <hazmat> imbrandon, charmload localhost:27017 is all i do
[18:28] <hazmat> it starts loading and spewing stuff on the console
[18:28] <japage> SpamapS: you rock. thanks!
[18:28] <SpamapS> kees: well, thats backwards for one (lp:charms/sbuild into your branch) .. but.. perhaps they already got merged?
[18:28] <imbrandon> hrm i dident add the port , let me try that, but yea i get a ton on console
[18:29] <hazmat> imbrandon, if its writing the console its writing to mongo
[18:29] <hazmat> its got a hardcoded db name of 'juju'
[18:29] <imbrandon> http 27018 on the web shows nothing in the db tho
[18:29] <imbrandon> one sec
[18:30] <hazmat> imbrandon, the data is there, try the cli
[18:31] <imbrandon> http://<IP_ADDRESS>:28017/
[18:32] <kees> SpamapS: ah, you're right. okay. fixed: https://code.launchpad.net/~kees/charms/precise/sbuild/trunk/+merge/111080
[18:33] <hazmat> imbrandon, http://<IP_ADDRESS>:28017/listDatabases?text=1
[18:33] <imbrandon> http://paste.ubuntu.com/1049617/
[18:33] <hazmat> imbrandon, use the mongo cli
[18:34] <hazmat> or a real front end, the data is there
[18:34] <imbrandon> k
[18:34] <imbrandon> hazmat: this is why i said it isnt
[18:35] <imbrandon> http://<IP_ADDRESS>:9090/charm-info?charms=cs:~charmers/precise/memcached
[18:35] <imbrandon> but i know it loaded that key already
[18:36] <hazmat> imbrandon, ic.. it failed processing it because you have the ssh accepting all clients and it doesn't like the output
[18:36] <hazmat> er. all server fingerprints
[18:37] <imbrandon> erm?
[18:37] <hazmat> imbrandon, ie you have something in your ~/.ssh/config like UserKnownHostsFile=/dev/null
[18:37] <imbrandon> yes
[18:37] <hazmat> it doesn't like that
[18:37] <hazmat> because it pollutes the cli output its parsing
[18:37] <imbrandon> heh wow, ok
[18:37] <imbrandon> ahh
[18:37]  * hazmat just figured that one out as well
[18:37] <imbrandon> wow, it parses the cli output ?
[18:38] <hazmat> imbrandon, yeah.. bzr is in python.. its executing the cli
[18:38] <hazmat> and then it processes it, and zip its up into mongodb gridfs
[18:38] <hazmat> and deletes the checkout
[18:38] <imbrandon> heh you would think it would just use the lp api and get json
[18:38] <hazmat> imbrandon, json for the file contents?
[18:39] <imbrandon> well a poiinter to the revision
[18:39] <hazmat> it needs the file contents
[18:39] <SpamapS> thats why it is failing on the ubuntu charm then
[18:39] <hazmat> its assembling a zip
[18:39] <imbrandon> ohh ok
[18:39] <SpamapS> hazmat: probably should be rewritten to ignore unknown lines, rather than fail on them :-P
[18:39] <imbrandon> still seems awkwasrd
[18:39] <hazmat> SpamapS, rewritten.. interesting idea
[18:40] <hazmat> SpamapS, so i think i hack up a version of this to try and figure out exactly why the store isn't loading them correctly
[18:40] <hazmat> the alternative is grepping through stdout logs of the charmload processes
[18:40] <hazmat> or having the store actually hand out that info.
[18:40] <SpamapS> hazmat: we need those exposed publicly anyway
[18:40] <SpamapS> otherwise we'll never be able to maintain the store
[18:40] <hamptonpaulk> can anyone point me to some docs on debugging relation-errors?
[18:43] <imbrandon> hazmat: ahh that worked
[18:43] <imbrandon> well     LogLevel ERROR
[18:43] <imbrandon> worked :)
[18:44] <SpamapS> hamptonpaulk: hm. I don't think there's a good definitive doc on that specific issue.
[18:44] <SpamapS> We should actually produce an error handling document
[18:44] <SpamapS> hamptonpaulk: basically you need to find the charm log
[18:45] <SpamapS> hamptonpaulk: with the local provider its in your datadir, under 'user-envname/units/unit-##/unit.log'
[18:45] <SpamapS> hamptonpaulk: in ec2/maas/orchestra, it will be in /var/lib/juju/units/unit-#/charm.log
[18:45]  * hamptonpaulk checking local
[18:46] <SpamapS> hamptonpaulk: Another way to go is to run 'juju debug-hooks unit/#' and then on another terminal 'juju resolved --retry unit/# relationname'
[18:46] <SpamapS> hamptonpaulk: that will pop up a window where you can re-run the hook script and see the failure
[18:47]  * SpamapS suddenly has an image of the kid from "The Sixth Sense" saying "....  I see fail"
[18:47] <imbrandon> lol
[18:47] <hamptonpaulk> SpamapS: ok, thanks. I will give it a go.
[18:48] <tedg> I'm a bit confused.  I've got a setup where I can run juju commands like status, but terminate-machine doesn't work.
[18:48] <tedg> What does terminate-machine do differently?
[18:49] <SpamapS> tedg: nothing really
[18:49] <SpamapS> tedg: it just pokes some nodes in zookeeper so the provisioning agent will terminate the machine
[18:49] <hazmat> tedg, it kills a machine by id that is not in use
[18:49] <tedg> Hmm, odd.  I'm getting a "ERROR SSH authorized/public key not found"
[18:50] <tedg> It's like it's using a different account / setup than others.
[18:50] <hazmat> hmm
[18:50] <tedg> Do the other commands use zookeeper?
[18:50] <SpamapS> almost all of them
[18:50] <SpamapS> certainly status
[18:50] <hazmat> every command does except destroy-environment and bootstrap
[18:51] <hazmat> tedg, that's odd its not materially different from any of the other commands
[18:55] <tedg> Here's the stack trace if that's helpful: http://paste.ubuntu.com/1049668/
[18:57] <tedg> Huh, adding "authorized-keys-path: ~/.ssh/id_rsa" to ~/.juju/environments.yaml fixes it.
[18:59] <SpamapS> tedg: you might have a ~/.ssh/config rule interfering, tho that wouldn't make much sense given that status works ;)
[18:59] <tedg> Yeah, my config is basically empty except for allowing unknown keys.
[19:16] <imbrandon> hazmat: yup thats all it was, db filling in nicely now
[19:16] <imbrandon> ty
[19:17] <hazmat> imbrandon, np
[19:17] <imbrandon> btw i just added the loglevel to my ssh.conf too
[19:17] <imbrandon> so it quelches warnings
[19:19] <imbrandon> i hope 2 and 3rd runs are faster :|
[19:22] <imbrandon> SpamapS: until we start using semver or whatever when we make official builds can the bzr build number be part of the version not just +bzrXXX e.g. when 0.5.1 rolls out <IP_ADDRESS>0 assuming bzr rev 560 ? it would make my life with rpm's and osx brew much easier
[19:23] <imbrandon> ( that fits into semver too iirc )
[19:24] <SpamapS> imbrandon: sure we can change that.. what official builds are you pulling into rpms and osx brew tho?
[19:24] <SpamapS> imbrandon: I'd have thought you'd just pull from lp:juju
[19:24] <imbrandon> well i am for the osx brew for now, but i'd like to use the tarbal
[19:24] <imbrandon> so that its a known version
[19:24] <imbrandon> e.g. brew allows for a --HEAD too
[19:25] <SpamapS> oh
[19:25] <imbrandon> so i can make "brew install juju" install from the tar and "brew install juju --HEAD" from lp:bzr
[19:25] <SpamapS> I hadn't considered making official tarballs
[19:25] <imbrandon> LP makes the tarbals
[19:25] <imbrandon> no biggie
[19:25] <SpamapS> oh for the ppa
[19:25] <imbrandon> yea
[19:25] <SpamapS> thats a bit of a happy accident
[19:25] <imbrandon> lol yea
[19:26] <imbrandon> works tho
[19:26] <SpamapS> I've been thinking about splitting the PPA's
[19:26] <SpamapS> or limiting the PPA to building from a stable series
[19:26] <imbrandon> and have liek a juju/crack ppa
[19:27] <imbrandon> heh
[19:28] <imbrandon> but yea that makes "brew install juju" install from the tar and "brew install juju --HEAD" from lp:bzr possible
[19:28] <imbrandon> and then i know exactly the version too thats installed
[19:29] <SpamapS> really juju should have a --version for that
[19:29] <SpamapS> I'm still surprised that was never introduced :p
[19:29] <SpamapS> anyway, lunchtime
[19:29] <imbrandon> heh ttyl
[19:29]  * imbrandon looks into how hard --version will be to add
[19:30] <imbrandon> uht ohh look out i'm doing python
[19:30] <imbrandon> heh
[20:51] <imbrandon> SpamapS: ping
[20:54] <imbrandon> SpamapS: well i poked a bit into the python just cuz i was a little bored :) got the --version added but not sure how to pull it dynamicly from setup.py
[20:54] <imbrandon> SpamapS: http://bazaar.launchpad.net/~imbrandon/juju/version-cli-option/revision/543?start_revid=543
[21:19] <SpamapS> imbrandon: I think we should flip it around, and have a juju.version
[21:19] <SpamapS> imbrandon: so  from juju.version import JUJU_VERSION
[21:19] <SpamapS> imbrandon: and have setup.py pull that in
[21:20] <imbrandon> ahh ok
[21:24] <SpamapS> hazmat: ^^ is that a common python idiom?
[21:24] <SpamapS> jimbaker: ^^
[21:27] <jimbaker> SpamapS, i don't know about common, but it seems reasonable enough
[21:29] <hazmat> SpamapS, i was thinking  text file
[21:29] <jimbaker> SpamapS, you are still centralizing it from a metadata perspective in setup.py, so that's good
[21:29] <hazmat> SpamapS, the upgrade branch already has that
[21:29] <hazmat> a juju/version.txt
[21:29] <hazmat> that drives a python api and can be used by tooling
[21:29] <hazmat> i can merge that solo, its tiny
[21:30] <imbrandon> k
[21:30] <SpamapS> hazmat: sahweet
[21:30] <SpamapS> hazmat: https://bugs.launchpad.net/juju/+bug/938899
[21:30] <_mup_> Bug #938899: juju needs a '--version' option <juju:New> < https://launchpad.net/bugs/938899 >
[21:31] <SpamapS> hazmat: assigning to you
[21:31] <hazmat> sounds good
[21:31] <SpamapS> hazmat: thats a honolulu feature tho, right?
[21:31] <imbrandon> darn i almost killed my first juju bug :) j/k
[21:31] <imbrandon> heh
[21:32] <hazmat> SpamapS, it was just because other things where priority, but its basically done, just need to copy it over, so feel free to rearrange
[21:32] <hazmat> i'll switch out else when i close it
[21:32] <hazmat> also fixes up the python packaging (includes test data, etc)
[21:33] <SpamapS> hazmat: done, and tested, are two different things :)
[21:33] <SpamapS> hazmat: lets land all the stuff that is "done" in the first few days of honolulu
[21:39] <hazmat> SpamapS, the upgrade stuff uses and installs this..
[21:40] <hazmat> k
[21:40] <SpamapS> hazmat: Its not that meaningful as a milestone.. so its no big deal. I just want to "release" something.
[21:41] <imbrandon> http://api.websitedevops.com/out.charmload
[21:41] <imbrandon> got an error that may help
[21:41] <hazmat> imbrandon, thanks
[21:41] <hazmat> that should tell us where the errors are in mia charms
[21:41] <imbrandon> hopefully :)
[21:42] <SpamapS> 2012/06/19 21:40:25 JUJU ----- lp:~charmers/charms/precise/nova-cloud-controller/trunk
[21:42] <SpamapS> 2012/06/19 21:40:25 JUJU Trying to add charms [cs:~charmers/precise/nova-cloud-controller] with key<EMAIL_ADDRESS>[21:43] <SpamapS> 2012/06/19 21:40:25 JUJU All charms have revision key<EMAIL_ADDRESS>Nothing to update.
[21:43] <imbrandon> SpamapS: this is on a secondary run
[21:43] <nathwill> working on trying to finish the storage backend for a revamped owncloud charm.. y'all think it'd be best to use s3fs, or require an nfs instance?
[21:43] <SpamapS> imbrandon: is cs:precise/nova-cloud-controller in there?
[21:43] <SpamapS> nathwill: *both* :)
[21:43] <imbrandon> one sec , lemme check
[21:44] <SpamapS> nathwill: give s3 as one option, and nfs as another. :)
[21:44] <imbrandon> SpamapS: nope
[21:44] <imbrandon> http://<IP_ADDRESS>:9090/charm-info?charms=cs:precise/nova-cloud-controller
[21:44] <nathwill> SpamapS: lol. i see... :P
[21:45] <imbrandon> SpamapS: charmd running on 9090 feel free to poke away at it
[21:45] <SpamapS> imbrandon: ok, so where's the initial import log?
[21:46] <imbrandon> that i dident redirect to the log :(
[21:46] <imbrandon> i can redo it tho
[21:46] <imbrandon> if it will help
[21:46] <SpamapS> actually
[21:46] <SpamapS> it seems that one has never been fixed
[21:46] <SpamapS> still points at 'precise'
[21:47] <imbrandon> some kinda 64bit int error
[21:47] <SpamapS> no this is a trunk name issue
[21:47] <SpamapS> fixing
[21:47] <imbrandon> panic: interface conversion: interface is int, not int64
[21:47] <imbrandon> is what i was getting at
[21:48] <SpamapS> weird
[21:48] <hazmat> imbrandon, you have to kill mongodb and start over for the initial logs, it will skip things its already seen that are unchanged.
[21:48] <hazmat> cool
[21:48] <hazmat> imbrandon, nice catch
[21:48] <imbrandon> woot :)
[21:49] <hazmat> hmm. the terracotta charm has some other oddities
[21:49] <hazmat> its one of two charms using a short cut for interface declaration that's supported in pyjuju but not by charm proof, or gojuju
[21:49] <imbrandon> ohh pizzahut just showed up, charmd is running on 9090 , i'll be back after foood :)
[21:50] <imbrandon> actually , one sec
[21:50] <imbrandon> root@server-1339205906-az-1-region-a-geo-1:~# ssh-import-id hazmat
[21:50] <imbrandon> INFO: Successfully authorized [hazmat]
[21:50] <imbrandon> root@server-1339205906-az-1-region-a-geo-1:~# ssh-import-id clint-fewbar
[21:50] <imbrandon> INFO: Successfully authorized [clint-fewbar]
[21:50] <imbrandon> root@server-1339205906-az-1-region-a-geo-1:~#
[21:51] <imbrandon> if you need , ssh as root and byobu is running, i'm headed to eat
[21:51] <imbrandon> box has nothing meaningfull on it
[21:51] <imbrandon> its a charm playground
[21:51]  * imbrandon heads to eat
[21:52] <hazmat> SpamapS, actually that interface declaration short cut causes a runtime  exception in proof
[21:54] <SpamapS> Ok, nova-cloud-controller should come off the MIA list now
[21:55] <SpamapS> kees: so, your changes to sbuild change the config.yaml options...
[21:55] <SpamapS> kees: the problem with that is if you have an existing deployment, your configurations are lost.
[21:56] <SpamapS> kees: we probably need a way to mark config options as deprecated, and then convert their values into the new ones (yet another use case for config-set)
[21:59] <SpamapS> perhaps somebody else could +1 this MP so we can land it in galapagos? Great change.. .really needed too.
[21:59] <SpamapS> https://code.launchpad.net/~therve/juju/validate-config-values/+merge/104808
[22:00] <SpamapS> fixes bug 979859
[22:00] <_mup_> Bug #979859: Unable to set boolean config value via command line <juju:In Progress by therve> < https://launchpad.net/bugs/979859 >
[22:01] <kees> SpamapS: do you want me to figure out a way to deal with that, or should users of that charm just feel pain?
[22:01] <SpamapS> kees: I think an update to the README is ok
[22:02] <SpamapS> IMO we should ditch the 'revision' file and go to a 'changelog' file so each revision can actually have info with it, so upgrade-charm can display it.. but thats neither here nor there.
[22:03] <SpamapS> kees: also the package-builder relation seems poorly defined. Were you thinking of just using private-address/public-address  (so no need for hooks) ?
[22:03] <SpamapS> kees: but I think you should also keep the old values, so users can use 'charm get servicename' to get the old values and plug them into the new ones.
[22:03] <kees> SpamapS: "charm proof" yelled at me, so I figured I'd at least provide a "here I am" report
[22:04] <SpamapS> I:'s are just info.. you can safely ignore I's
[22:05]  * kees nods
[22:06] <imbrandon> can we relation-set on juju-info ? heh
[22:08] <SpamapS> imbrandon: probably
[22:08] <SpamapS> That would be.. misguided.. but probably :)
[22:08] <imbrandon> heh
[22:09] <imbrandon> it would be a hack round config-set
[22:10] <imbrandon> hrm *thinks of ways to twist that into submission*