[00:01] <_mup_> Bug #939932 was filed: Should be able to set --repository from system environment <juju:New> < https://launchpad.net/bugs/939932 >
[00:02] <hazmat> SpamapS, why does my repo need to be in ~/.juju
[00:03] <SpamapS> hazmat: I mean your pointer to repository should be able to be specified from a config file somewhere in ~/.juju
[00:03] <hazmat> SpamapS, ah.. yeah.. that sounds good
[00:03] <SpamapS> hazmat: I'm not entirely sure environments.yaml is the right place
[00:04] <SpamapS> hazmat: one thought I had.. environments should actually be usable as repositories
[00:04] <SpamapS> long term anyway :)
[00:18]  * hazmat notes its beer o clock around here
[00:19] <SpamapS> hazmat: yageshegedra
[00:19] <_mup_> Bug #939944 was filed: Default Charm namespace should be overridable by environment variables. <juju:In Progress by clint-fewbar> < https://launchpad.net/bugs/939944 >
[00:19]  * SpamapS is getting the hang of lbox.. ;)
[04:39] <locke105> is there a way to use juju without an amazon S3-like store? looking for a way to deploy to an openstack setup but I don't want setup a Swift module if i dont have to
[04:51] <_mup_> juju/enhanced-relation-support r9 committed by jim.baker@canonical.com
[04:51] <_mup_> Cleanup
[07:53] <ejat> can someone review lp:~fenris/charms/oneiric/symfony/trunk
[07:54] <ejat> im having a problem when i run the install script manuall on ec2 .. its works ..
[07:54] <ejat> but when i use juju deploy ...
[07:54] <ejat> it can be view / test on ec2
[07:56] <ejat> !ping SpamapS & hazmat
[07:56] <ejat> !ping jcastro
[08:55] <m_3> ejat: hey, so take a look at the logs on the service unit
[08:56] <m_3> ejat: they're found in /var/lib/juju/units/<unit>/charm.log
[08:56] <m_3> that should help debug this a bit
[09:01] <ejat> m_3: ok thanks ..
[09:03] <m_3> ejat: I'm spinning it up now, but I created a new Bug #940140
[09:03] <_mup_> Bug #940140: Charm needed: Symfony <Juju Charms Collection:New> < https://launchpad.net/bugs/940140 >
[09:04] <m_3> please grab it and attach your branch... it pops up on our review queue if you also add the tag: 'new-charm'
[09:05] <ejat> ok thanks m_3
[09:05] <ejat> ill try to update the bugs accordingly
[09:10] <m_3> np, it's just a good place to keep track of conversation about it... other than irc logs :)
[09:24] <m_3> ejat: it just came up to a 'started' state for me
[09:25] <m_3> ejat: what problems are you seeing?
[09:28] <ejat> yeah .. show started .. but when i open the public dns .. its show nothing ..
[09:29] <ejat> rather than i manually deploy using the script ..
[09:30] <m_3> are you "exposing" the service after deploying?  i.e., 'juju expose symfony'
[09:30] <m_3> (it's firewall stuff)
[09:31] <ejat> m_3: yeah .. did it also ...
[09:31] <ejat> # Make it publicly visible, once the symfony service is exposed
[09:31] <ejat> open-port 80/tcp
[09:31] <ejat> inside the install
[09:31] <m_3> there's an additional command that runs from your client
[09:31] <m_3> juju bootstrap
[09:32] <m_3> juju deploy ...
[09:32] <m_3> juju expose symfony
[09:32] <m_3> it's designed to be a controlled/gated network exposure for a whole stack of services
[09:33] <ejat> yeah .. only done that 3 command ..
[09:35] <m_3> ejat: hmmm... if juju status shows that the service unit is 'started' and lists 'open-ports:', then I'm not sure what's going on
[09:36] <m_3> I'm getting a 'It works!' from apache and a directory listing when I hit http://<ec2-addr>/symfony
[09:36] <ejat> http://<ec2-addr>/symfony/web
[09:38] <m_3> right, that's showing the pretty 'project created' page:  http://ec2-107-22-14-139.compute-1.amazonaws.com/symfony/web/
[09:40] <m_3> maybe it's been upgraded and is a bit stale?  you might try recycling your environment if nothing else is running
[09:43] <ejat> your instance on precise ?
[09:43] <ejat> or oneiric ?
[09:44] <ejat> m_3: if u see that .. mean my charm work :)
[09:45] <ejat> or i should change my     default-series: oneiric
[09:45] <ejat> in my juju environments
[09:46] <m_3> ah, sorry... I was assuming you were using oneiric instances because your branch had charms/oneiric/symfony
[09:46] <m_3> ejat: yes, it looks like the install part of the charm works fine
[09:47] <m_3> I'd recommend changing to 'default-series: oneiric' in your ~/.juju/environments.yaml file
[09:48] <ejat> i already put that in my environment
[09:48] <m_3> cool
[09:50] <ejat> can u try http://ec2-46-137-225-47.ap-southeast-1.compute.amazonaws.com/symfony/web
[09:50]  * ejat confuse .. y u getting the pretty page .. but i am not :(
[09:52] <ejat> m_3: can u view it ?
[09:53] <m_3> ejat: I get a php file
[09:53] <m_3> but it's not viewable
[09:53] <ejat> yeah .. thats what i get too ..
[09:53] <m_3> this is on an oneiric instance?
[09:53]  * ejat wondering y u can get it :)
[09:53] <ejat> yups .
[09:54] <ejat> just now u launch it on what instance?
[09:54] <m_3> try to 'juju ssh symfony/0'
[09:54] <m_3> and then 'sudo apache2 restart'
[09:54] <m_3> see if that fixes it
[09:54] <m_3> I've only run it on oneiric
[09:55] <ejat> 0 or 1 ?
[09:55] <m_3> sorry, that should be 'sudo service apache2 restart'
[09:55] <m_3> whichever unit you've got started
[09:55] <ejat> yeah its works
[09:55] <ejat> after restart
[09:55] <ejat> can u retry
[09:56] <m_3> I bet you need an extra restart after you make the symlink for sf
[09:56] <ejat> owh okie ..
[09:56] <m_3> yes, I see the pretty 'project created' page
[09:57] <ejat> \0/
[09:57] <m_3> cool
[09:58] <ejat> but need someone to review the code .. make it more clean ..
[09:58] <ejat> :)
[10:00] <m_3> sure... we can put it through the usual review process.  When you're ready just add the 'new-charm' tag to that bug
[10:01] <m_3> and I or somebody in the group will review the branch
[10:02] <m_3> not right now though :)... back to sleep for me
[10:03] <ejat> thanks so much m_3
[10:04] <m_3> glad to help
[10:06] <ejat> see ya soon .. or maybe in uds-q .. :)
[10:07]  * ejat also feel \\0/ can contribute some charm as state within the uds-p milestone .. 
[10:08] <ejat> trying to submit other charm if possible .. gtg to0 ...
[12:28] <jamespage> hazmat, m_3: I'd really like to refactor the hadoop charm into mapreduce and hdfs charms - any objections?  I'll leave the current hadoop-master/hadoop-slave as is
[12:28] <hazmat>  james_w sounds good to me
[12:29] <hazmat> er..
[12:29] <hazmat> jamespage, +1
[12:29] <jamespage> lol
[12:29]  * hazmat checkouts  ironfan
[12:29] <jamespage> hazmat, it would mean that the hbase-master charm could be multi-master much more easily
[12:34] <SpamapS> jamespage: that sounds great! :)
[12:35]  * jamespage is running mapreduce jobs on his pandaboard this morning :-)
[12:38] <hazmat> jamespage, nice!  i've been meaning to touch base someone about juju on arm
[12:38] <hazmat> w/
[12:38] <hazmat> jamespage, which jvm?
[12:39] <jamespage> hazmat: the only one for armhf (openjdk)
[12:39] <jamespage> now that the thumb2 port has landed as default in openjdk-6 its actually OK
[12:39] <jamespage> and passes the TCK
[15:23] <m_3> jamespage: splitting hadoop makes sense to me
[15:28] <m_3> jamespage: I also like Clint's approach (ceph and mysql) to a single charm that can be deployed into different roles
[15:29] <m_3> jamespage: either way, I'm not particularly fond of the names "-master" and "-slave"
[15:29] <m_3> professionally, that is :)
[15:41] <jamespage> m_3: remind me how that works again?
[15:43] <m_3> sure... so consider the simple one... mysql
[15:45] <m_3> juju deploy ... local:mysql masterdb
[15:45] <m_3> juju deploy ... local:mysql slavedb
[15:45] <m_3> juju add-relation masterdb:master slavedb:slave
[15:45] <m_3> probably better named something like 'replicaset1' or something... but I'm cutting/pasting
[15:49] <jamespage> ah - I see
[15:49] <jamespage> nice
[15:49]  * jamespage goes to refactor his charms
[15:50] <m_3> yeah, it's really elegant
[15:50] <m_3> but shhhhhh... we don't want it to go to his head :)
[16:39] <m_3> jcastro: review queue length back down to 1 (I'll catch saltstack next week)
[16:39] <jcastro> \o/
[16:39] <jcastro> m_3: was rick's thing hard or easy?
[16:45] <m_3> jcastro: pretty straightforward... just some basic updates to the rails charm
[16:45] <jcastro> k
[16:45] <jcastro> have you had a chance to look at summit yet?
[16:46] <m_3> I'll put the rails one up for review soon... wanted to do some cleanup before showing it to rails peeps at conferences
[16:46] <m_3> summit's next on the list today
[16:46]  * jcastro nods
[16:46] <m_3> the good news is we actually have a django charm
[16:46] <jcastro> hey alright!
[16:46] <m_3> like the rails/node charms, this one will deploy a django app straight from a bzr repo
[16:47] <jcastro> that's basically awesome
[16:47] <m_3> so hopefully it'll go quick
[16:47] <jcastro> it gives you a good story for those language conferences
[16:47] <m_3> haven't really checked the state of the charm though
[16:47] <m_3> might need some updating / completion... it was never put up for inclusion into the store for some reason
[16:48] <m_3> written by... Michael Nelson
[16:48] <m_3> looks like great work... just don't know if he finished or not
[16:48] <m_3> I'll find out today/tomorrow
[16:53] <gary_poster> m_3, thanks for review!  We'll get to the fixes
[16:55] <m_3> gary_poster: thanks for the charm!  please do branch lp:charm-tools too when y'all get a chance... y'all have great stuff for a charm-helpers-py!
[16:56]  * m_3 too many "y'all"s in one place... I guess I'm feeling very Texan atm
[16:57] <m_3> my fav is still "y'all're".... which is actually more characters than "you are"... which defeats the purpose of a contraction... harumph
[17:08] <SpamapS> m_3: but it rolls of the tongue so nicely... like y'all're just a rollin in thu mud on a sundee
[17:08] <m_3> :)
[17:23] <jamespage> m_3: that works really nicely
[17:23] <jamespage> thanks for the tip!
[17:24] <jamespage> m_3, http://bazaar.launchpad.net/~james-page/charms/precise/hadoop-hdfs/trunk/view/head:/README
[17:25] <m_3> jamespage: awesome... that looks great
[17:25] <jamespage> m_3: certainly reduces the amount of code replication across the two charm approach (most of it is the same)
[17:25] <m_3> we can add additional namenodes too... not sure what to call that relation tho :)
[17:26]  * SpamapS is all for charm consolidation whenever possible
[17:26] <m_3> yeah, buildbot ended up using cross-charm links to reduce code-repl
[17:26] <SpamapS> I've been thinking about a streamlined approach to configuring the various roles.. I wonder if we could add a --role=slave and that would pull $charmroot/roles/slave.yaml as the default values to override the usual defaults..
[17:27] <m_3> consolidation would work well for them
[17:27] <SpamapS> This happens with ceph really badly.. you don't know if its a single node ceph tester, or a 100 node ceph buildout, until the 2nd unit is added...
[17:27] <m_3> SpamapS: including sample deploy scripts into the readme works well for that imo
[17:27] <SpamapS> m_3: yeah, thats the way right now
[17:28] <SpamapS> I'm getting way too far ahead of myself with the role thing. :)
[17:28] <m_3> they had a $CHARM_DIR/samples/ directory with various config scenarios
[17:28] <m_3> hong-kong-phooey
[17:29]  * m_3 makes bruce lee fighting sounds
[17:30] <m_3> jamespage: a namenode-cluster gets complicated with the relations though... I'd hvae to do that one on the whiteboard :)
[17:31] <jamespage> m_3: yeah - in 1.0.0 it is a single point of failure TBH
[17:31] <m_3> w/ a lot more coffee
[17:31] <jamespage> its possible with DRBD and stuff
[17:31] <m_3> I thought they added that in 205
[17:32] <jamespage> m_3: nah
[17:32] <m_3> or was that for the 0.23 line
[17:32] <SpamapS> I'm more and more convinced that some charms need a config item that is "wait for relationX" so that you can just skip configuration until relationX is established, so that you don't get into the situation we see with nova where it stores in sqlite, then mysql
[17:32] <jamespage> yep
[17:32] <m_3> ah, gotcha... my bad
[17:32] <jamespage> SpamapS, +1 to that
[17:32] <SpamapS> I need to return to the ceph charms so I can demonstrate that..
[17:33] <SpamapS> actually using that approach would probably allow easy mysql ring replication for the mysql charms too
[17:33] <m_3> SpamapS: or some way to know that the relation is actually completed before then doing a 'juju set --config ' from an outside script
[17:34] <SpamapS> m_3: hm, I think thats another approach, but one that will be more complicated and not yield better results
[17:34] <jamespage> other than using a full config management solution like puppet does anyone have a nice way of determining whether a restart of a service is required?
[17:34] <jamespage> I though about checksumming the config files and only restarting if stuff had changed.
[17:38] <m_3> jamespage: hmmm... no clue
[17:39] <m_3> that might be useful as an upstart primitive though.... service xxx status
[17:42] <SpamapS> jamespage: I do that in mysql
[17:43] <jamespage> SpamapS, I'll take a look - just trying to avoid blind restarts
[17:43] <jamespage> 'something might have changed'
[17:43] <SpamapS>         if oldhash != tmd5.digest():
[17:43] <SpamapS>             os.rename('/etc/mysql/my.cnf','/etc/mysql/my.cnf.%s' % md5.hexdigest())
[17:43] <SpamapS>             os.rename(t.name, '/etc/mysql/my.cnf')
[17:44] <SpamapS> jamespage: with mysql is pretty important to only restart when critical configs are changed. ;)
[17:48] <jamespage> ack
[17:48] <jamespage> now to refactor the hbase-* charms into a single charm
[17:51] <_mup_> Bug #940492 was filed: Charm metadata must support subordinates and container relations <juju:New> < https://launchpad.net/bugs/940492 >
[17:56] <_mup_> Bug #940498 was filed: Juju must provide the implict juju-info relation <juju:New> < https://launchpad.net/bugs/940498 >
[21:59] <_mup_> juju/enhanced-relation-support r10 committed by jim.baker@canonical.com
[21:59] <_mup_> More work on spec