[06:41] <koolhead17> hi all
[06:41] <koolhead17> SpamapS: around
[07:17] <SpamapS> koolhead17: actually yes
[07:18] <koolhead17> SpamapS: my talk on juju got selected :)
[07:18] <koolhead17> will share slide in few days :)
[07:22] <SpamapS> koolhead17: congrats!
[11:22] <niemeyer> Good morning all
[12:50] <jorge> hazmat: hi man! all fine?
[12:50] <jorge> hazmat: recently i've talked to niemeyer about a problem when running "juju status". i always get a "bind error". i've tested a lot of things with sniffers and verified logs along the command call. i've detected that juju try to ssh to an instance and suddenly the ssh connection is closed! so, googling i've found a irc log about the same problem. in this case there was a discussion about ipv6.
[12:51] <jorge> hazmat: so i've ran with "strace -e trace=listen,bind,connect -f juju status" and saw that after try to bind to an ipv6, the process dies (http://pastebin.com/JmCnbZbY). In auth.log, at the instance, i can see a suddenly "ssh connection closed". So, it appears that this two things are correlated.
[12:51] <jorge> hazmat: well, i had a sysctl.conf entry disabling ipv6 (net.ipv6.conf.all.disable_ipv6=1). So, removing that, all is working fine!!! OMG! There were some days trying to understand this problem. Now, just a opinion. I think that somewhere in the code, when some 'if tests' analyses the return of the calls, when the ipv6 returns an error, it understand that all is with error.
[12:51] <jorge> hazmat: So, even though ipv4 connection is OK, the process dies! Just a bet hehe.
[13:35] <bac> hi, i'm seeing the problem reported by gary_poster and me last week again.  in the install hook 'config-get' is not returning anything despite having defaults set in config.yaml.  the same charm works for others.  i'm using the PPA version 0.5+bzr451-1juju2~precise1.  any ideas on how to debug it?  this problem is blocking me.
[13:36] <gary_poster> (bac, you verified that environments.yaml says "juju-origin: ppa" also right?
[13:36] <gary_poster> )
[13:36] <bac> gary_poster: yes
[13:36] <gary_poster> cool
[13:36] <bac> gary_poster: were you able to resolve the problem?  any debugging hints?
[13:37] <gary_poster> I have debugging hints on our yellow page
[13:37] <gary_poster> bac, looking in the data directory and looking at the ppa environment variables were the things that Kapil had me do
[14:12] <hazmat> jorge, interesting, and odd, juju defers to the ssh binary for setting up the tunnel, and then we always hand it an ipv4 address, something sounds odd there.. i guess its the ssh failing when trying to establish the listening/forwarding port
[14:13] <hazmat>  hmm.. we could specify the host ip address for the forward port to be more explicit as 127.0.0.1, it sounds like just the port spec alone is causing a bind to additional interfaces
[14:19] <hazmat> bac which charm?
[14:19] <bac> hazmat: the buildbot charm we're working on
[14:19] <hazmat> bac keep in mind the environment will cache the charm, if the version hasn't been incremented.. so subsequent deploys without incrementing the version or destroying the environment will use the cached version
[14:20] <bac> hazmat: gary_poster pointed me to the master-customize log file.  in that is see the add-apt-repository failed due to name lookup, so it didn't install juju from the PPA after all
[14:20] <bac> hazmat: thanks but versioning is not the problem
[14:20] <hazmat> bac what does juju status report the state of the unit as ?
[14:21] <bac> hazmat: it is install_error b/c 'config-get' is not returning anything, so the install charm fails
[14:21] <hazmat> if one exists at all, then it should have installed juju into the container, there aren't any fallbacks to juju code installation
[14:21] <bac> hazmat: but i think that is related to the version mismatch caused by it not being able to add the PPA repo
[14:23] <bac> hazmat: sorry, i don't understand your last comment.
[14:23] <bac> hazmat: juju was installed in the container, but it was not the PPA version it was from universe
[14:24] <bac> so i wonder if the version mismatch is what is causing the problem with config-get.
[14:24] <hazmat> bac, that would make sense i think, and would explain the mismatch, can you ssh or chroot into the container and verify the package version?
[14:25] <bac> hazmat: i could and saw that it was not the ppa version (r338 or similar)
[14:25] <bac> hazmat: i manually added the PPA repo and was able to install the proper one.
[14:25] <bac> but after doing that, 'juju ssh' began prompting me for the ubuntu user password.  any idea what that is?
[14:27] <hazmat> bac it should be setup with ssh keys
[14:39] <bac> hazmat: here is the master-customize.log that shows the errors i mention:  http://pastebin.ubuntu.com/823887/
[14:40] <bac> at line 255 is the apt-add-repository failure
[14:41] <bac> and line 661 looks like an error too in that the key isn't being added to authorized_keys.  that would explain why i cannot ssh.
[14:41] <hazmat> bac, indeed that looks like both the problems
[14:42] <hazmat> bac to reset it you have to destroy-environment and recreate it
[14:42] <bac> hazmat: have done so.  this log file is from a clean deploy into a new environment
[14:42] <hazmat> ugh.. it looks like its not able to setup the resolv.conf correctly at the top of the log
[14:42] <bac> yeah
[14:43] <hazmat> i noticed this problem in the precise containers, i've got a branch in the review queue which requires the resolvconf package install explicitly
[14:44] <hazmat> bac, if you want to try it out as an alternative, you can set juju-origin: lp:~hazmat/juju/local-respect-series    and do a destroy-environment/bootstrap
[14:44] <gary_poster> there was a resolv.conf change in precise recently.  it was not required, and lxc depended on this.  When it was added, it overwrote the custom /etc/resolv.conf that lxc installed (with nameserver 10.0.3.1). It bit me in another way.  I'm also having lxc issues (lxc-start is hanging, at least on lucid); trying to gather data for Serge before I bother him.
[14:45] <gary_poster> it was not required -> resolvconf was not required
[14:45] <gary_poster> when it was added -> when resolvconf was added
[14:45] <gary_poster> Lordy, my pronoun use was horrible :-/
[14:45] <gary_poster> I blame it on baby-caused lack of sleep :-P
[14:45] <hazmat> gary_poster, consistency makes it work :-)
[14:45] <gary_poster> lol
[15:54] <jcastro> m_3: FYI remember you have a charm session tomorrow for developer week: https://wiki.ubuntu.com/UbuntuDeveloperWeek
[16:04] <jcastro> koolhead17: heya
[16:05] <koolhead11> hola jcastro :)
[16:06] <jcastro> https://code.launchpad.net/~jorge/charms/oneiric/owncloud/upgrade-to-3
[16:06] <jcastro> owncloud bumped to 3,0 and there's my branch to upgrade the charm
[16:06] <jcastro> however I can't test it today, I'm having juju problems of some kind
[16:06] <jcastro> so I haven't proposed it yet but if you're looking for an easy upgrade/fix it just needs to be tested that it works.
[16:08] <koolhead11> jcastro: cool!! lemme check it,. i will need sometime.
[16:08] <jcastro> no rush, I just wanted to make you aware that it's there
[16:09] <koolhead11> jcastro: super :)
[16:10] <m_3> jcastro: yup... _and_ a talk tomorrow afternoon at mongo-boulder
[16:10] <jcastro> man, look at you, unstoppable
[16:11] <koolhead11> m_3: hi there
[16:11] <m_3> hey koolhead11!
[16:11] <koolhead11> jcastro: you were working on that ubuntupad about juju-charm school content
[16:11] <koolhead11> how are we planning to use it
[16:11] <m_3> wait, weren't you 17?  where'd 11 come from?
[16:12] <jcastro> he must have lost 6 kool points
[16:12] <koolhead11> m_3: am at work so am 11 :D
[16:58] <jcastro> hey SpamapS
[16:58] <jcastro> is there a flag for charm get unofficial unfinished charms?
[16:58] <jcastro> like say, django?
[17:09] <SpamapS> jcastro: no, bzr branch those
[17:09] <jcastro> k
[17:09] <SpamapS> jcastro: if we want to support that in charm get, we'll have to support showing all 9 branches that matched the given word...
[17:10] <jcastro> I have some charm workflow questions, can we chat later?
[17:11] <SpamapS> jcastro: I'm not averse to accepting random bzr branch urls in charm get.. just for consistency.
[17:11] <SpamapS> jcastro: certainly!
[17:13] <jcastro> SpamapS: or m_3: You guys know offhand the status of the django charm?
[17:15] <m_3> jcastro: nope, haven't checked on it in a while
[17:37] <dpm> jcastro, is the django charm we're talking the same one noodles created on http://micknelson.wordpress.com/2011/11/22/a-generic-juju-charm-for-django-apps/ if so, I can ask him directly
[17:37] <jcastro> yep
[17:52] <dpm> jcastro, SpamapS, so I was trying to set up a django server on a Canonistack instance, and I couldn't get past the 'bootstrap' step. Would you have a few minutes to give me a hand? Here's what I'm getting:
[17:52] <dpm> http://pastebin.ubuntu.com/824142/
[17:53] <jcastro> adam_g: might need your help on this one too ^
[17:53] <dpm> the access key is from:
[17:53] <dpm> https://pastebin.canonical.com/59146/
[17:55] <adam_g> dpm: you need to specify:
[17:55] <adam_g>     ec2-uri:  http://91.189.93.65:8773/services/Cloud
[17:55] <adam_g>     s3-uri: http://91.189.93.65:3333
[17:56] <adam_g>     ec2-key-name: keypairname
[18:02] <dpm> adam_g, where can I find the 'keypairname' I should specify there?
[18:02]  * dpm is new to cloud
[18:06] <SpamapS> you don't actually need ec2-key-name
[18:07] <dpm> so I should only specify the first two lines above, then?
[18:27]  * m_3 found the perfect sick-food... meatballs-n-spaghettios
[18:29] <SpamapS> m_3: yes that is the perfect food to make you sick
[18:38] <etneg_> well nice logo
[18:38] <etneg_> :D
[18:39] <etneg_> just noticed ensemble went through a change
[18:39] <jcastro> SpamapS: I can chat any time you want.
[18:39] <jcastro> etneg_: yeah we're growing up!
[18:39] <etneg_> come a long way
[18:39] <jcastro> SpamapS: I am just brainstorming so we don't need to bother m_3.
[18:39] <SpamapS> "What a long strange trip its been"
[18:39] <etneg_> i wasnt around the time juju was announced else i'd have tkane part in creating the logo
[18:39] <jcastro> that's my way of saying I have really stupid questions and want to limit the people who hear them. :)
[18:40] <jcastro> etneg_: plenty to do, want to write a charm?
[18:40] <SpamapS> jcastro: just realized I completely forgot breakfast.. need to eat and then I'll put on my stupid question answering hat and buzz you on G+
[18:40] <etneg_> more logo stuff?
[18:40] <etneg_> vectors? sure
[18:40] <etneg_> code? i'll pass
[18:40] <jcastro> heh
[18:40] <jcastro> SpamapS: nod.
[18:40] <jcastro> SpamapS: I am available for the rest of the day, no calls, no rush, at your convenience.
[18:40] <etneg_> if you guys plan to modify the existing logo, let meknow
[18:40] <etneg_> :D
[18:41] <etneg_> or need icons, let me know
[18:41] <SpamapS> Does anybody else get a warm fuzzy when a bug they reported and worked around in 2 places gets fixed without a single question from the developer fixing it?
[18:41]  * SpamapS is a bug reporting STUD
[18:41] <etneg_> at the time i worked on ensemble's logo i wasnt eexactly vector-compliant, was mostly paper stuff
[18:42] <SpamapS> https://review.openstack.org/#patch,sidebyside,3575,1,nova/tests/api/ec2/test_cloud.py
[18:42] <etneg_> either way nice logo
[18:42] <SpamapS> etneg_: there was a blog post showing the story of the juju logo which included your early drawings I think
[18:42] <etneg_> ye and mine sucked now that i look at it
[18:42] <etneg_> too many elements and what not, i think the team was kind to mention it
[18:42] <etneg_> lol
[18:42] <EvilBill> hmmmm, re: mac version of juju client - I just found what appears to be an easy-to-use packager: http://s.sudre.free.fr/Software/Iceberg.html
[18:43] <SpamapS> etneg_: http://design.canonical.com/2011/11/juju-logo/
[18:43] <etneg_> ye just read that awhile ago
[18:43] <SpamapS> ok.. eating.. now
[18:43] <etneg_> i was lipping through ubuntu's design stuff and bumped into that
[18:43] <etneg_> so dropped by here
[18:44] <etneg_> lipping/slipping
[18:44] <etneg_> the juju logo looks prett sweet
[18:47] <etneg_> gl:D
[19:08] <hazmat> for giggles, a graphviz output of the entire charm universe with dependencies lined out.. http://kapilt.com/files/charm-graph.png
[19:09] <m_3> hazmat: nice
[19:17] <jimbaker> graphviz, at least hierarchical drawing, is definitely not a good way to render it... but still useful to see the centrality of some charms like mysql
[19:17] <m_3> maybe even try twopi?
[19:19] <jimbaker> twopi probably would do better
[19:20] <jimbaker> esp since it's not truly hierarchical
[19:20] <jimbaker> maybe some charms are like that, but not true in general
[19:22] <hazmat> jimbaker, i'm going to play around with networkx with matplot lib as an alternative
[19:22] <jimbaker> hazmat, sounds like a plan. there's definitely some interesting graph relations there
[19:23] <SpamapS> jcastro: G+ yo
[20:38] <gary_poster> SpamapS, hi.  is your charm tests spec hardened enough for us to try and follow it, and have a reasonably high probability of us not having to rework the whole thing later?
[20:39] <gary_poster> (From https://code.launchpad.net/~clint-fewbar/charm-tools/charm-tests-spec branch)
[20:39] <SpamapS> gary_poster: I think so.. I can give you my juju wrapper script that I use to run the example tests if you like?
[20:39] <gary_poster> SpamapS, cool, yeah thanks
[20:40] <SpamapS> http://paste.ubuntu.com/824374/
[20:40] <SpamapS> gary_poster: it doesn't do the deploy-previous yet :)
[20:40] <SpamapS> gary_poster: and you have to set RESOLVE_TEST_CHARMS=1 to make it do anything at all
[20:41] <gary_poster> :-) cool, it's a start, thanks SpamapS .  The main idea is for us to have a target for writing tests, and this gives us one.
[20:44] <_mup_> juju/refactor-machine-agent r450 committed by jim.baker@canonical.com
[20:44] <_mup_> UnitManager tests
[20:45] <_mup_> juju/refactor-machine-agent r451 committed by jim.baker@canonical.com
[20:45] <_mup_> Merged trunk
[20:46] <SpamapS> gary_poster: indeed, I've written a few more in the course of writing the spec.. definitely need to put get-unit-info into juju itself
[20:47] <gary_poster> cool
[20:52] <SpamapS> If anybody is interested in learning a few in's and outs of packaging.. I'll be giving a brief presentation over in #ubuntu-classroom in about 9 minutes
[22:25] <grapz> SpamapS, I think I've found out about the SSH issue I had yesterday
[22:26] <grapz> just because I'm being cheap, I was using t1.micro to do testing on, and it seems like it sometimes takes forever to complete the init steps
[22:29] <grapz> it's been going on for 9 minutes now, and I don't see the 'cloud-init boot finished' on my t1.micro yet (but now I can SSH to it), and the m1.small that I started at the same time, finished ages ago
[22:30] <grapz> there should maybe be a disclaimer about using t1.micro in the docs somewhere
[22:31] <SpamapS> grapz: sometimes they work
[22:31] <SpamapS> but usually no
[22:31] <SpamapS> I mean, I run my personal website on one... but it gets like, 150 visits a day ;)
[22:32] <grapz> :)
[22:32] <grapz> I'll add a line to the 'default-instance-type' in the docs about it being really slow at times - might save someone else from stumbling upon it
[22:33] <SpamapS> grapz: indeed, perhaps add it as a footnote so it doesn't interrupt the flow.
[22:33]  * SpamapS goes off to run a few errands
[22:34] <grapz> good idea
[22:53] <grapz> So, when I've made a change to the docs, added and pushed the change to my personal branch, I just file a bug against juju with the branch attached, and then it will be reviewed ? (my first time submitting a patch in LP)
[22:55] <_mup_> juju/refactor-machine-agent r453 committed by jim.baker@canonical.com
[22:55] <_mup_> Missing file
[23:09] <m_3> ugh... ec2 is _crawling_ atm
[23:25] <_mup_> juju/refactor-machine-agent r454 committed by jim.baker@canonical.com
[23:25] <_mup_> Cleanup