[02:11] <Luca__> jamespage: Hi there, I am trying to set up openstack using bundles and/or reducing # of required jobs. I know you are working on openstack's charms, could you provide any update on your progresses?
[04:07] <AskUbuntu> Can Juju cannot services that are in different environments? | http://askubuntu.com/q/378679
[09:51] <AskUbuntu> Swift - No ring is created when deployed using juju. attached is output of 'swift-init start main' on swift-proxy node | http://askubuntu.com/q/378774
[10:12] <InformatiQ> hey guys I'm new to juju and a bit confused about the difference between deploy and add-unit
[10:13] <InformatiQ> could some one kindly explain
[10:44] <noodles775> jamespage or adam_g : If you've time, I've got a patch for what seems to be a bug in the swift-proxy charm when using essex, attached to bug 1251551
[10:44] <_mup_> Bug #1251551: Essex + Keystone deploy broken <swift-proxy (Juju Charms Collection):New> <https://launchpad.net/bugs/1251551>
[10:44] <jamespage> hey noodles775
[10:44] <noodles775> Hi james :)
[10:45]  * jamespage looks
[10:52] <noodles775> InformatiQ: `juju deploy` is for deploying a new service (and by default, it'll create a single unit for that service). add-unit can then be used to add extra units to that existing service. This blogpost shows a simple example: http://smartbridge.com/blog/use-juju-to-deploy-and-scale-wordpress-in-the-cloud/
[10:56] <InformatiQ> noodles775: thanks for the answer, so a deploy is creating the configuration and the required instances to run those, then add-unit just does the same but it would not as for configs and just clone the already deployed service
[10:56] <InformatiQ> noodles775: is that correct
[10:57] <InformatiQ> noodles775: also in that blog post, adding a worpress unit does not mean it will actually load balance or anything, i will then need to add a load balancer service to handle the actual scaling
[10:59] <jamespage> noodles775, nice work on the template unit testing - I like that
[10:59]  * jamespage had been pondering how todo that best
[11:05] <noodles775> InformatiQ: So yes, deploy tells juju about the service and sets up some configuration that is re-used by subsequent units. And yes, the blogpost doesn't include a load balancer. As an example of how simple that is, see "How to deploy the charm" on the haproxy charm at: https://jujucharms.com/fullscreen/search/precise/haproxy-21/#bws-readme
[11:05] <jamespage> luca__, hey - you had a question on openstack bundles?
[11:06] <noodles775> jamespage: Great - yes, I was unsure how to test the changes - I was happy to find that the choice loader just worked in those tests :)
[11:06] <jamespage> noodles775, I made a few tweaks to how the tests get executed; we have a pattern that we have used across the other openstack charms
[11:06] <jamespage> but it broadly looks OK
[11:06] <noodles775> Excellent, thanks.
[11:08] <luca__> jamespage: Hi James, I did but I can't remember what the question was. I'll dig through my notes to see if I can find it :)
[11:09] <jamespage> noodles775, the proposal has changes to the README and to swift-test as well - any particular reason?
[11:09] <noodles775> jamespage: yeah, mentioned in the MP description, but happy to revert if you don't want them.
[11:10] <noodles775> jamespage: hrm, I see my changes to the readme, but not to swift-test?
[11:10]  * jamespage ponders that one
[11:11] <jamespage> oh - sorry - that was me being an ass
[11:11] <jamespage> (to much autopep8)
[11:11] <noodles775> hah :)
[12:01] <InformatiQ> noodles775: thanks for your help, that helped me a lot
[12:01] <InformatiQ> I am quite impressed of juju's ease of use and low barrier to entry
[12:02] <InformatiQ> not liking the bash install hooks though
[12:03] <benji> InformatiQ: fortunately, you can write hooks in any language you want
[12:03] <jamespage> if anyone has a bit of review time:
[12:03] <jamespage> https://code.launchpad.net/~openstack-charmers/charms/precise/ceph/alternatives-config/+merge/195148
[12:04] <jamespage> https://code.launchpad.net/~openstack-charmers/charms/precise/ceph-osd/alternatives-config/+merge/195149
[12:04] <jamespage> (they have been in use in testing for quite some time and where used for the keynote at the OpenStack summit a few weeks back)
[12:05] <noodles775> InformatiQ: np :) And yes, as benji said, you can use any language you want. There's also support for using configuration tools like ansible/saltstack if you're into that.
[12:05] <noodles775> jamespage: oh, that reminds me, can I swap you for a review of https://code.launchpad.net/~michael.nelson/charm-helpers/ansible-tags/+merge/194324
[12:06] <InformatiQ> noodles775: yeah i was googlng for ansible support but seemed to be still not merged
[12:07] <noodles775> InformatiQ: yeah, there's some basic support in current charm-helpers (ie. an apply_playbook() helper), but I'm hoping to get the above branch landed soon which will make the ansible suppport much nicer.
[12:12] <noodles775> jamespage: done.
[12:12] <jamespage> noodles775, looking at your ansible one now
[12:12] <noodles775> Great, thanks.
[12:12]  * noodles775 -> lunch
[12:12] <jamespage> noodles775, thanks for the review (and yes alot of the delta is re-sync of charm-helpers)
[12:22] <jamespage> noodles775, reviewed and +1'ed
[12:32] <noodles775> Great, thanks jamespage
[12:32] <jamespage> np
[12:37] <jamespage> love it when I propose branches and find my stuff is already merged
[12:37] <jamespage> \o/
[12:37] <jamespage> free work!
[12:38] <jamespage> dosaboy, please see my comments on mysql and rabbitmq charms re argonaut backwards compat
[12:38] <jamespage> that fix is already in cinder and glance
[12:43] <dosaboy> jamespage: yep, actually the question was raised over whether we should allow non-openstack charms that use ceph to specify a source for the ceph packages
[12:44] <jamespage> ooo - good one
[12:44] <dosaboy> since right now if deployed on precise they are forced to use Argonaut
[12:44] <jamespage> dosaboy, that might not be much of an issue - the mysql and rabbitmq charms both use the kernel module
[12:44] <jamespage> so its only the cli tools that might be incompat
[12:45] <dosaboy> yeah and that is the problem ;)
[12:45] <jamespage> dosaboy, with havana backend?
[12:45] <dosaboy> i mean i agree we should provide back-compat support
[12:45] <dosaboy> but if users want to use > A they also have that option
[12:45] <dosaboy> for the cli tools that is
[12:45] <dosaboy> and
[12:45] <dosaboy> if their cluster is > A the tools may have issues
[12:46] <jamespage> its awkward
[12:46] <jamespage> dosaboy, if we go down that route the cloud-archive must be installed at a lower priority than main archive
[12:47] <jamespage> then you can cherry pick the ceph tools by themselved
[12:47] <jamespage> then you can cherry pick the ceph tools by themselves
[12:48] <dosaboy> jamespage: agreed
[12:48] <dosaboy> or could version ping just the packages we ned but that is a little messay
[12:48] <dosaboy> messy even
[12:57] <InformatiQ> in the case where i deploy 2 wordpress + 1 mysql + haproxy then I want to have a central logging server then I would need to deploy rsyslog to each of those services with the --to param and a rsyslog service to collect them all?
[13:10] <noodles775> InformatiQ: So the rsyslog-forwarder charm is a "subordinate" charm, so you just deploy it as normal and then relate it to the services where you want it in use (juju knows not to create any separate instances for that charm, due to it being a subordinate charm).
[13:12] <noodles775> InformatiQ: Then you can deploy the rsyslog charm and relate it to the rsyslog-forwarder. (I've not used these, just going from the summary/readme at https://jujucharms.com/fullscreen/search/precise/rsyslog-1/
[14:51] <jamespage> noodles775, your swift-proxy change worked OK for havana so I went ahead and merge it - thanks!
[14:51] <jamespage> it was a bit crufty  from pre-redux stuff
[14:53] <noodles775> Great, thanks jamespage. Yeah, looked like a huge cleanup!
[15:09] <AskUbuntu> Will Juju support start/stop of existing units? | http://askubuntu.com/q/378920
[16:09] <noodles775> jamespage: Hi, my MP is still approved but not landed - does it need to be merged manually? https://code.launchpad.net/~michael.nelson/charm-helpers/ansible-tags/+merge/194324
[16:09] <jamespage> noodles775, yes - sorry
[16:09] <jamespage> no auto-landing just yet....
[16:13] <mattyw> I seem to be able to bootstrap multiple environments for a single provider - and they are kept seperate but destroy-environment kills everything - is this a known problem?
[16:16] <jamespage> mattyw is that with maas?
[16:22] <mattyw> jamespage, aws
[16:23] <jamespage> mattyw, juju version?
[16:24] <mattyw> jamespage, ah - the destroy is an old version: 1.13
[16:24] <jamespage> mattyw: and do you have unique control-buckets and secrets for each environment?
[16:24] <jamespage> (just checking the obvious stuff first)
[16:25] <mattyw> jamespage, bucket and secret are different
[16:26] <jamespage> mattyw, I would suspect a bug - but I could not confirm that
[16:26] <jamespage> fwereade_, jam: ^^ ring any bells?
[16:26] <mattyw> jamespage, I'll try updating the old version and see if it happens again
[17:08] <fwereade_> mattyw, what provider?
[17:09] <fwereade_> mattyw, ec2 will have problems if the environments have the same name
[17:09] <fwereade_> mattyw, and I *think* openstack has the same issue
[17:10] <fwereade_> mattyw, maas is meant to be working if you have up-to-date juju and maas, and you have unique values of... er<checks>
[17:11] <fwereade_> mattyw, maas-agent-name -- but that should not be set automatically, so you're safe unless they're old environments or you're doing something really weird
[17:12] <fwereade_> mattyw, sorry, maas-agent-name *should* be set automatically
[17:12]  * fwereade_ will bbl
[17:50] <InformatiQ> using juju with local provider, afer a reboot of the VM i get "ERROR Unable to connect to environment "local"
[17:51] <InformatiQ> I was thinking that a jujud should be running but cabn't find the service
[18:23] <marcoceppi_> InformatiQ: what does `initctl list | grep juju` show on your machine?
[18:39] <InformatiQ> marcoceppi_: uju-db-rhanna-local stop/waiting
[18:39] <InformatiQ> juju-agent-rhanna-local start/running, process 907
[18:42] <marcoceppi_> InformatiQ: `sudo start juju-db-hanna-local`
[18:42] <marcoceppi_> InformatiQ: wait a few seconds, then try juju status
[19:12] <InformatiQ> recover error: abrupt end to file .juju/local/db/journal/j._1, yet it isn't the last journal file
[19:13] <InformatiQ> ok so apparantly juju-db cannot recover so that's why it can't start
[19:13] <InformatiQ> hmmm
[19:16] <InformatiQ> ok got it, remove journal j.__? files and restart service this should work in case of corruåt journal but no db chnages
[19:16] <InformatiQ> first issue with juju == first real learning experience
[19:17] <InformatiQ> good day so far
[19:57] <jcastro> hey arosales or marcoceppi
[19:57] <jcastro> which one of you recorded the last charmer meeting?
[19:57] <marcoceppi> jcastro: I think it was arosales
[19:57] <jcastro> I need a link to the video please!
[19:58] <InformatiQ> hey guys any pointers to how to do python or ansible charms
[19:58] <avoine> would it be correct to use admin-secret as my charm default admin password like juju-gui does?
[19:58] <InformatiQ> or if you know one charm from the store written ansible/puppet/python would be cool
[19:58] <avoine> InformatiQ: I've done charm in python
[19:59] <marcoceppi> InformatiQ: http://micknelson.wordpress.com/2013/11/08/juju-ansible-simpler-charms/
[19:59] <avoine> python-django, gunicorn, but postgresql and etherpad-lite would be better examples
[19:59] <arosales> jcastro, I indeed did
[19:59] <arosales> jcastro, sure let me grab it
[20:00] <InformatiQ> marcoceppi: that blog post is mentioning that the ansble stuff was not yet commited
[20:00] <marcoceppi> InformatiQ: it's been merged, that post was from august
[20:01] <arosales> jcastro, https://www.youtube.com/watch?v=QlI2Qz2nucc
[20:02] <InformatiQ> marcoceppi: wasn't sure how fast juju gets things in ;)
[20:02] <InformatiQ> arosales:
[20:02] <marcoceppi> InformatiQ: that is part of charm-helpers, a seperate project that's designed to help streamling writing charms
[20:02] <InformatiQ> avoine: so a big hooks.py and everything else points to it
[20:02] <marcoceppi> InformatiQ: that's one method
[20:03] <avoine> InformatiQ: yeah, this way it more convenient
[20:53] <dannf> helping someone behind a firewall in another channel - does juju use the various *_proxy variables? does it need more than http/https out to work?
[20:54] <dannf> (when talking to the charmstore)
[21:03] <thumper> dannf: not as much as I believe we should
[21:03] <thumper> I'm not sure it has been thoroughly thrashed out and exhaustively tested
[21:04] <dannf> thumper:  ack
[21:04] <thumper> so, my normal stance is, if it isn't tested, it is broken