[00:52] <cjohnston> Does anyone have any experience with using salt in a charm?
[01:14] <sidnei> cjohnston: ping noodles775 in the morning
[01:14] <sidnei> cjohnston: though he (and me and hazmat) favours ansible
[01:14] <cjohnston> sidnei: ya. was hoping for someone tonight..
[01:15] <sidnei> let me see if i can find you an example
[01:15] <hazmat> cjohnston, there's support for it in charmhelpers
[01:15] <cjohnston> hazmat: right.. I'm having a specific issue, but I know that not many people have experience with it
[01:16] <hazmat> cjohnston, traceback?
[01:17] <hazmat> cjohnston, i'm happy to take a look, but no guarantees. i haven't used the combo, though i'm familiar with both.
[01:17] <cjohnston> hazmat: http://paste.ubuntu.com/6440481/  I believe the issue is with my attempt at getting relation info.
[01:18] <cjohnston> I'm trying to get the postgres host, grains.get('postgres:host'),  is what I'm using
[01:19] <hazmat> cjohnston, hmm.. it looks something wrong in the template expression
[01:20] <hazmat> cjohnston, do you have a minimal file that reproduces ?
[01:20] <hazmat> cjohnston, one that you can share that reproduces?
[01:21] <cjohnston> its supposed to be producing django DATABASES = {}
[01:21] <cjohnston> one sec
[01:24] <cjohnston> hazmat: http://paste.ubuntu.com/6440506/
[01:26] <hazmat> cjohnston, the sls file for it?
[01:27] <cjohnston> I think I may have just figured something out... hrm.. lemme see what it does, if not I'll paste
[01:35] <hazmat> cjohnston, any luck?
[01:38] <cjohnston> well, the traceback is gone, but I have 'None' instead of real data
[01:40] <hazmat> cjohnston, are you using the charm-helpers salt support? ie. http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/saltstack/__init__.py
[01:41] <cjohnston> yes
[01:41] <cjohnston> hazmat: http://paste.ubuntu.com/6440556/
[01:47] <hazmat> cjohnston, so the relation data isn't there yet, which hook is that being run in?
[01:48] <cjohnston> db-relation-joined and db-relation-changed... if I do relation-get it returns the correct data
[02:03] <cjohnston> hazmat: is ('postgres:host') correct? should postgres be something else maybe?
[02:05] <hazmat> cjohnston, the grains with the data  are in /etc/salt/grains ..
[02:06] <hazmat> cjohnston, it looks like you need a prefix from http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/templating/contexts.py#L34
[07:54] <InformatiQ> i'm working on a trac charm using ansible
[07:54] <noodles775> InformatiQ: Excellent! Just ping with any questions... I guess you saw that the extra ansible support landed yesterday in charm-helpers.
[07:55] <InformatiQ> does anyone have any pointer how the juju_state_to_yaml outputr looks like
[07:55] <InformatiQ> noodles775: i was waiting for it to start writing my code ;)
[07:56] <InformatiQ> I have been using ansible for a while now and I can see a lot of potential for combining it with juju
[07:56] <InformatiQ> although i still struggle a bit with juju concepts
[07:56] <noodles775> Yep - I think the combination has lots of potential to simplify charms too (and make them much more flexible out-of-the-box).
[07:58] <noodles775> InformatiQ: so do you want a paste of an example yaml file that's outputted by the function (I can do that, just wondering why you need it, normally you wouldn't need the file itself, as it's just used to provide context for your templates). Ah, probably the key names...
[08:00] <noodles775> cjohnston: Did you find the data you were looking for? FWIW, I'd recommend checking the actual grains written to the file in /etc/salt/grains as hazmat suggested (or alternatively using a pdb when running your hook in the debug-hook window) to confirm the actual keys, but they should be "reln_type:reln_key" (where reln_type is just os.environ.get('JUJU_RELATION_ID'))
[08:00] <noodles775> cjohnston: er, os.environ.get('JUJU_RELATION'), sorry (ie. output of charmhelpers.core.hookenv.relation_type())
[08:16] <InformatiQ> noodles775: yes I need that file to know what are the  vars that are available
[08:16] <InformatiQ> noodles775: i would appreciate if you could paste one for me or just tell me how to generate it
[08:26] <noodles775> InformatiQ: Cool, so in the long run it'd be best to look at the one generated automatically by your charm, as it is just a json dump of the charm configuration (which is very dependent on the charm you're using). But as an example, if I was working with a charm which had these options in the config.yaml:
[08:26] <noodles775> https://jujucharms.com/fullscreen/search/precise/swift-proxy-30/?text=swift-proxy#bws-configuration
[08:27] <noodles775> then the file contents are just a dump of the charms config, eg: http://paste.ubuntu.com/6441675/
[08:28] <noodles775> The juju_state_to_yaml helper also adds 'charm_dir', 'local_unit', as well as relationship data (which is only present once those relationships are added).
[08:29] <noodles775> (for all the details, see http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/templating/contexts.py ), but otherwise, let me know when you've got a simple install hook which just installs ansible, and I'll show you how you can inspect the real file yourself.
[08:33] <InformatiQ> noodles775: are you the author of the blog micknelson.wordpress.com
[08:34] <noodles775> InformatiQ: yep, you can blame me for any errors there :)
[08:34] <InformatiQ> noodles775: just that i left a comment and it is still waiting moderation ;)
[08:35] <InformatiQ> noodles775: so I followed your example and have that hooks.py and install/start/stop/etc and links to it
[08:35] <noodles775> InformatiQ: It should be there, I approved it 15mins ago or so.
[08:35] <InformatiQ> now I am working on an ansible playbook
[08:36] <noodles775> InformatiQ: Great. Just start with something really simple (ie. something that has a single task tagged with 'install'), then we can start the deploy/debug-hook cycle so you can see how to debug and test as you go.
[08:36] <noodles775> s/something that/a playbook that/
[08:47] <InformatiQ> noodles775: ok should have the needed stuff there
[08:48] <InformatiQ> noodles775: so what is the path to testing the hook without really deploying?
[08:50] <noodles775> InformatiQ: So I tend to write unit-tests to test things like "calling the install hook installs ansible", but there's not a lot more you could unit-test (perhaps with ansible, we could add some helpers that ensure your playbook is formatted correctly etc.). When developing your charm though, you really want to be deploying to test it. Do you have an environment bootstrapped?
[08:51] <InformatiQ> noodles775: yes I have a local env
[08:52] <noodles775> Great. So you can try deploying your charm (if you can push your branch somewhere, I can follow along/help a bit more).
[08:57] <noodles775> InformatiQ: hah - thanks for the flowers :-) (the tweet)
[09:03] <InformatiQ> noodles775: pushed current code to https://github.com/InformatiQ/charm-trac
[09:03] <InformatiQ> noodles775: i got 2013-11-19 09:01:01 ERROR juju.worker.uniter uniter.go:350 hook failed: fork/exec /var/lib/juju/agents/unit-trac-0/charm/hooks/install: exec format error
[09:03] <noodles775> InformatiQ: Perfect, let's find out why...
[09:04]  * noodles775 grabs the charm
[09:08] <noodles775> InformatiQ: Ok, I'm guessing the error is that we've not yet imported charmhelpers (nor is it yet available in the charm - it's not included automatically). But let's actually confirm that the right way. In a separate terminal, run `juju debug-hooks trac/0`
[09:09] <InformatiQ> noodles775: ok that dropped me in a shell on the new machine
[09:10] <noodles775> Then in your original terminal, do `juju resolved --retry trac/0`
[09:10] <noodles775> When you switch back to the debug-hooks window, it should now be ready to run the install hook.
[09:10] <InformatiQ> yes
[09:11] <noodles775> Run `hooks/install` to see the error.
[09:12] <InformatiQ> noodles775: syntax error at line 4
[09:12] <InformatiQ> hmm
[09:13] <noodles775> Yep, let's back out a bit (it was just worth seeing how to use debug-hooks). Basically, hooks/install is currently running your hooks/hooks.py as a bash script.
[09:13] <noodles775> So edit the file (right there on the unit, so we can iterate quickly)
[09:13] <InformatiQ> aha
[09:14] <InformatiQ> yeah got that and now add the hash bang for python?
[09:14] <noodles775> Yep, then you'll see the error related to charmhelpers being missing.
[09:14]  * noodles775 looks up the latest and greatest way to include those in your charm.
[09:15] <InformatiQ> yup charmhelpers not defined
[09:25] <noodles775> jamespage: hi! I'm just looking for the best way to pull charmhelpers into a charm (to help InformatiQ). I notice in your swift-proxy charm you've got a charm-helpers.yaml defining the import, and in the Makefile the sync target calls charm-helper-sync... where does charm-helper-sync come from?
[09:26]  * noodles775 normally does it with a much uglier Makefile target.
[09:28] <InformatiQ> this is looking a bit complicated for me
[09:28]  * InformatiQ is a code monkey not a developer
[09:31] <noodles775> InformatiQ: hah. New things are always tricky at first. We can do it a simpler way. Just do `bzr branch lp:charm-helpers /tmp/charm-helpers && cp -R /tmp/charm-helpers/charmhelpers hooks`
[09:31] <noodles775> InformatiQ: that'll put the current charmhelpers python library in your hooks directory so we can use it.
[09:32] <noodles775> InformatiQ: oh, and if it's not clear, this is on your development machine, you can exit out of the debug-hooks.
[09:36] <InformatiQ> noodles775: ok so now I need to redeploy?
[09:37] <noodles775> InformatiQ: You can just upgrade the charm too `juju upgrade-charm trac --repository....`
[09:38]  * noodles775 is just testing the updated hooks.py before pasting it.
[09:48] <noodles775> InformatiQ: so this is what your hooks.py should look like - I'll update the blogpost with the imports and the main section, note you also had site.yaml rather than sites.yaml too: http://paste.ubuntu.com/6441930/
[09:50] <noodles775> InformatiQ: also, in your playbooks/sites.yaml, you've got "lates" instead of "latest".
[09:56] <InformatiQ> noodles775: cool things are moving ahead
[09:56] <InformatiQ> cool
[09:58] <noodles775> Yep. I'm still just looking at an issue I'm seeing (not an issue of yours, but with the ansible support that I've added). So don't worry if it gets stuck. (It's worthwhile to me because I'm keen to iron out issues in the ansible support :-) ).
[09:59] <InformatiQ> where should the playbook dir reside? in the hooks ?
[10:00] <noodles775> It's fine where you've got it.
[10:00] <InformatiQ> i am getting file not found
[10:00] <noodles775> Did you fix the "playbooks/site.yaml" to "playbook/sites.yaml"?
[10:01] <noodles775> (in hooks/hooks.py, that is)
[10:01] <InformatiQ> yes i have
[10:02] <InformatiQ> http://paste.ubuntu.com/6441986/ that is the traceback
[10:06] <noodles775> InformatiQ: hrm - that's not related to your playbook. Checking the line that's failing from your tracebook says that it's trying to run `juju-log` and not finding it. But I don't know why that would be (ie. why a juju unit wouldn't have juju-log available).
[10:13] <InformatiQ> juju-loh is not even available on my juju host
[10:13] <InformatiQ> is it deprecated now?
[10:14] <InformatiQ> i am using the ppa version of juju
[10:14] <InformatiQ> ppa:juju/stable
[10:15] <InformatiQ> on saucy
[10:15] <noodles775> No, it's still very much a part of juju. I'm using the same ppa (on saucy), and this is the output I see on the trac unit: http://paste.ubuntu.com/6442038/
[10:16] <noodles775> InformatiQ: I'm not sure how you ended up with a juju unit without juju-log, but it might be worth redeploying...
[10:19] <InformatiQ> noodles775: just sshed into one of the successfully deployed machine and juju-log cmd is not available too
[10:19] <noodles775> Ahh - hangon.
[10:20] <InformatiQ> although actually the install hook for that service had juju-log in there
[10:22] <noodles775> InformatiQ: Cool, confirmed: it's not an installed command available whenever you log in. But it is available when you're running a hook. So first, make sure you're in a `juju debug-hooks trac/0` session (even if it's not currently within a hook)
[10:22] <InformatiQ> noodles775: juju-log is supposed to be here /var/lib/juju/tools/1.16.3.1-precise-amd64/juju-log
[10:22] <InformatiQ> and that is probably not in the path
[10:23] <InformatiQ> noodles775: i guess you either extend PATH in the charmhelpers/core/hookenv.py or explicutly use the full path for juju-log
[10:24] <InformatiQ> because I am in juju debug-hooks for that service
[10:24] <noodles775> InformatiQ: you won't need to. It'll be available when you're actually running a hook. Great (that you're in the debug-hooks session), we just need to trigger a hook first. Try:
[10:25] <noodles775> InformatiQ: back in your other terminal, run `juju set trac tracadmin_user=foo` (it'll just cause the config-changed hook to be triggered)
[10:25] <noodles775> InformatiQ: when you switch back to your debug-hooks terminal, you should see it's updated and juju-log will be on the path.
[10:27] <InformatiQ> well that didn't help either but I set it manually
[10:28] <InformatiQ> and now a new failure related to config-get i guess because it doesnot have the needed configs
[10:28] <InformatiQ> i guess i now cleanup, fix sources push to git and retry
[10:30] <noodles775> InformatiQ: Yeah - I'm still investigating something with the ansible support, but I'll create a pull-request demoing the stubbed charm once it's working. Thanks for your patience :)
[10:32] <InformatiQ> noodles775: ok, i guess that was a good drill i have updated the charm on github
[10:32] <InformatiQ> let me know when it is ready to proceed
[10:33] <InformatiQ> i need to get back to my dayjob now
[10:33] <noodles775> Great, will do. Enjoy :-)
[10:36] <davecheney> http://us-east.manta.joyent.com/dfc/public/QaipSnfmeK.0.svg
[10:36] <davecheney> ^ sorry, it has the wrong mime type
[10:36] <davecheney> i'll have to fix my client
[10:36] <davecheney> ignore, wrong chan
[11:07] <jamespage> noodles775, its in charm-helpers
[11:08] <jamespage> (yeah - I know thats a bit sucky)
[11:08] <jamespage> noodles775, http://paste.ubuntu.com/6442249/
[11:08] <noodles775> Thanks jamespage
[11:11]  * noodles775 wonders if a simple Makefile might provide a good bootstrap to pull that one file from the branch, sync charmhelpers, and create a stubbed (but working) basic charm.
[11:38] <noodles775> InformatiQ: The issue I thought I was looking out was a typo on my part (I had sites.yaml, rather than sites.yml). Here's an example of your charm being deployed: http://paste.ubuntu.com/6442336/
[11:39] <noodles775> InformatiQ: What you had in your branch was fine as is, all I needed to do was remove the unused hooks: https://github.com/InformatiQ/charm-trac/pull/1
[11:39]  * noodles775 -> lunch
[11:53] <AskUbuntu> jujud hangs when connecting to the mongo,maybe tls handshake error | http://askubuntu.com/q/379325
[12:29] <jamespage> noodles775, ooo - now that is an idea
[12:33] <InformatiQ> noodles775: great thanks
[12:33] <InformatiQ> now I need to figure out what to do about those db relations
[12:33]  * InformatiQ wonders what subordinates are
[12:33] <InformatiQ> to the docs
[12:37] <InformatiQ> noodles775: one more thing related to the state_to_yaml what you pasted earlier had the config vars, but what about relation vars?
[12:56] <noodles775> InformatiQ: they'll also be in the file once you add a relation hook and it's called (the helper updates the vars file based on the current config and current relation just before running the playbook with the tag)
[13:15] <cjohnston> noodles775: I finally figured it out ;-)
[13:16] <noodles775> cjohnston: great :-) Let me know if it's something that could have been avoided by better docstrings in the charmhelper modules.
[13:18] <cjohnston> noodles775: it was figuring out grains.get('db:database')  (the 'db' part), I didn't find anything that said what it should have been
[13:21] <noodles775> cjohnston: Right - I'll update the docstring to make that explicit.
[13:34] <gnuoy> if a unit dies unexpectedly does that trigger cluster relation departed on the other units in the same server ? I thought it would but I don't seem to be seeing that
[13:57] <hazmat> gnuoy, it used to with pyjuju.. in juju-core the signaling is explicit after the admin does juju remove-unit.
[13:57] <gnuoy> hazmat, ah ok, thanks
[14:03] <InformatiQ> I have a " agent-state-info: 'hook failed: "install"'"
[14:04] <InformatiQ> how do i get it fixed after i have fixed my hook
[14:05] <InformatiQ> i did try juju resolved
[14:05] <InformatiQ> but didn't get that fixed
[14:06] <InformatiQ> ok aparantly me being in debug hooks prevented it from continuing
[14:06] <InformatiQ> all good now
[15:18] <SuperMatt> I'm having trouble using this: https://juju.ubuntu.com/docs/howto-node.html with my own node app. I don't particularly care for the mongodb integration, so how could I tweak the charm for what I need?
[15:28] <marcoceppi> hey SuperMatt, so you can fork the charm, using charm-tools (available from ppa:juju/stable), just run juju charm get node-app, edit the metadata.yaml file to include additional interfaces you wish to communicate with, then write the hooks for those relations
[15:28] <SuperMatt> thanks :)
[15:29] <SuperMatt> I think I discovered why the charm hasn't really been working for me
[15:29] <marcoceppi> SuperMatt: We do have people working on the node-app charm to make it more robust, but that's a way for you to patch in the mean time
[15:29] <SuperMatt> there's a lot of stuff in the config.yaml that the tut doesn't really mention
[15:30] <marcoceppi> SuperMatt: Must have changed since the tut was written
[15:30] <marcoceppi> SuperMatt: I'll also include https://juju.ubuntu.com/docs/charms-deploying.html#local in case you didn't already know how to deploy a charm from a local repo
[15:31] <SuperMatt> marcoceppi: if you don't mind, I'm going to just have a bash at tweaking this thing, and I'll let you know what I discover :)
[15:32] <marcoceppi> SuperMatt: sure! if your changes can benefit the larger community, feel free to submit a merge req back in to the store
[15:32] <SuperMatt> well, I don't know about that ;)
[15:32] <SuperMatt> I imagine it's a good idea to have the charm allow you to pick if you want to have mongodb, rather than it being required
[15:32] <marcoceppi> SuperMatt: you can submit for a review anywasys :_
[15:32] <SuperMatt> sure
[15:33] <SuperMatt> thanks
[15:33] <SuperMatt> I'm kinda just learning about juju right now
[15:33] <SuperMatt> so it's all a bit up in the air for me
[15:33] <SuperMatt> if I manage to do something cool I'll merge back
[15:34] <SuperMatt> thanks for the help though, I didn't realise you could simple pull out a charm and modify it
[15:34] <SuperMatt> q
[15:34] <SuperMatt> ops
[15:34] <SuperMatt> I actually typed :q there
[15:34] <SuperMatt> >.<
[15:42] <SuperMatt> marcoceppi: I've just spotted exactly what I needed to change to make the installer work for me. Thanks a lot
[15:42] <marcoceppi> SuperMatt: NP! Glad I could help
[15:47] <SuperMatt> all right, here goes nothing
[16:23] <noodles775> jamespage: trivial one-liner if you've a few secs: https://code.launchpad.net/~michael.nelson/charm-helpers/remove-saltstack-import-from-ansible-support/+merge/195817
[16:25] <jaywink> hi .. anyone with knowledge whether on azure "force-image-name" config can be used to use an image captured into personal gallery? I cannot really find image names..
[16:25] <jaywink> and I'm interested in freezing an image to use for deployments anyhow
[16:49] <InformatiQ> noodles775: according to your patch https://code.launchpad.net/~michael.nelson/charm-helpers/ansible-tags/+merge/194324 line 201 + ("{relation_type}{namespace_separator}{key}".format(
[16:49] <InformatiQ> noodles775: the relation vars are prefixed with relation_type
[16:49] <InformatiQ> how do i get the relationtype?
[16:49] <InformatiQ> so i can formulate the var name
[16:51] <InformatiQ> noodles775: or how can i print the vars.yml so I can inspect it
[17:02] <SuperMatt> marcoceppi: my juju experiments are going very well now. Thank you for your help
[17:02] <InformatiQ> noodles775: ok found out what type it is from env var
[17:02] <marcoceppi> SuperMatt: awesome, let us know if you have any other questions :)
[17:02] <SuperMatt> sure thing
[17:02] <SuperMatt> I think I'm going to stay in here
[17:02] <InformatiQ> but ansible complains about variable not defined
[17:03] <SuperMatt> I think learning juju, lxc, cgroups and maybe a little openstack are going to make me indispensible in the future
[17:04] <jamespage> noodles775, merged
[17:04] <jamespage> (implicit approval)
[17:05] <InformatiQ> SuperMatt: indeed
[17:36] <InformatiQ> noodles775: it seems ansible does not like vars with '-' as in the case with private-address so simply also key.replace('-','_') as you did for the relation_type
[18:25] <InformatiQ> noodles775: check my git repo hooks/charmhelpers/contrib/templating/contexts.py to see the small chnage needed
[19:41] <InformatiQ> hey guys, some advice needed
[19:41] <InformatiQ> working on a trac charm
[19:41] <InformatiQ> should i make mysql an optional db ?
[19:42] <InformatiQ> i was thinking to make sqlite default backend and make mysql optional
[19:48] <jcastro> InformatiQ, yes, that sounds great
[19:48] <jcastro> that's what the etherpadlite charm does
[19:48] <jcastro> that way if someone wants to run "small" on one instance they can do so
[19:48] <jcastro> and then expand out to mysql later
[19:48] <InformatiQ> jcastro: good to see someone up
[19:49] <InformatiQ> jcastro: the proble is that trac is not quite kind when it comes to migrating dbs
[19:49] <jcastro> I would leave a note in your README though, reminding people that if they add the mysql relation that their data will not magically be migrated to the new DB
[19:50] <jcastro> yeah so I would just mention that in the README
[19:50] <InformatiQ> jcastro: good isea
[19:50] <jcastro> maybe link to db migration docs if trac has them or something
[19:50] <InformatiQ> jcastro: so hooks would be
[19:51] <InformatiQ> install to get all installed
[19:51] <InformatiQ> config-changed to init the env and db using sqlite
[19:51] <InformatiQ> if relation added
[19:51] <InformatiQ> then keep the sqlite db and reconfigure to point to mysql and then people need to do the work to get it migrated
[19:52] <InformatiQ> jcastro: what do you think? (my first charm))
[19:52] <jcastro> yeah, sec, I am looking at http://bazaar.launchpad.net/~charmers/charms/precise/etherpad-lite/trunk/view/head:/hooks/hooks.py
[19:53] <jcastro> I think that would be in relation changed?
[19:53] <jcastro> marcoceppi,  is that right?
[19:54] <InformatiQ> jcastro: yeah that would be db-relation-changed
[19:54] <jcastro> oh interesting, I didn't know trac did postgresql too
[19:55] <marcoceppi> InformatiQ: jcastro: sure, that's one way to approach it
[19:55] <jcastro> (just searching for other charms that support multiple DBs)
[19:57] <marcoceppi> jcastro: typically, you'd make sure the data migrated between sets
[19:57] <InformatiQ> hei guys, so I start a new project and start creatingthe infra with juju say a wordpress + mysql
[19:57] <InformatiQ> then i need to add plugins and a new theme to wordpress and whatever
[19:57] <InformatiQ> soe of these changes are on filesystem
[19:58] <InformatiQ> now when do add-unit wordpress that won't take my chnages
[19:58] <marcoceppi> InformatiQ: check the readme, there is a way to make that happen
[19:59] <marcoceppi> InformatiQ: you either need to place your plugins and themes in a repository OR use an NFS charm to share the files across a mount
[19:59] <InformatiQ> marcoceppi: well that is a general case notspeciic to wordpress
[20:00] <marcoceppi> InformatiQ: it's what teh wordpress charm does
[20:00] <InformatiQ> mainly about the lifetime and repeatability of a juju infra
[20:00] <InformatiQ> i am sysadmin
[20:00] <marcoceppi> InformatiQ: what's your question?
[20:01] <marcoceppi> i'm not quite grasping what you're trying to ask
[20:01] <InformatiQ> i use ansible to deploy services, and whenver i want to change my infra i update the ansible scripts and redeploy
[20:02] <sarnold> InformatiQ: perhaps you're looking for juju subordinate charms to deploy different wordpress plugins?
[20:02] <InformatiQ> I am trying to understand how does juju handle changes to infra?
[20:03] <jcastro> so you could fork the wordpress charm, make the changes you want, and deploy
[20:03] <jcastro> however, juju has a concept of subordinate charms
[20:03] <thumper> o/
[20:03] <jcastro> which "bolt on" to existing charms
[20:04] <InformatiQ> jcastro: yeah i am trying to understand that now
[20:04] <jcastro> so you could have "wordpress" and say "all-my-custom stuff charm"
[20:04] <jcastro> however with this particular charm marco made it so you could do plugins and custom things on disk without having to do that
[20:04] <jcastro> you basically deploy the NFS charm as a subordinate of wordpress
[20:05] <jcastro> and then when you add unit of wordpress it'll also pull in nfs and have the right things on disk for the new unit
[20:07] <InformatiQ> so a subordinate sticks to the service and get redeployed whenver a unit is added
[20:08] <jcastro> yeah
[20:08] <InformatiQ> hmm
[20:08] <jcastro> the relationship is made between the services, not the machines
[20:08] <InformatiQ> jcastro: yup got that
[20:08] <jcastro> so any new unit you add will be like the others
[20:09] <jcastro> https://jujucharms.com/fullscreen/search/precise/wordpress-20/?text=wordpress#bws-readme
[20:09] <jcastro> the "single mode and the scale out" section explains the NFS bit with the wordpress charm btw
[20:10] <jcastro> (sorry we're in the middle of a team call right now, trying to respond as fast as I can)
[20:11] <InformatiQ> jcastro: oh no worries i got enough to read already
[20:12] <jcastro> if we're not responsive over the next 2 days it's because we're doing a developer conference, but feel free to post on the mailing list!
[20:21] <InformatiQ> jcastro: one last question
[20:22] <jcastro> shoot!
[20:22] <InformatiQ> in the case i want to add a monitoring agent to all my machines, then that is not a subordinate
[20:22] <InformatiQ> and add-unit will not help get that agent to all machines right?
[20:23] <jcastro> ok so let's say you have newrelic
[20:24] <jcastro> we made that a subordinate so that anything you relate to newrelic will automatically get the agent deployed
[20:24] <jcastro> but correct, if you don't have a relationship with the agent and the service on the machine then juju won't help in that case
[20:25] <jcastro> but we want to get as many monitoring agents in the charm store as possible so that you can just relate them to whatever you want to monitor
[20:26] <jcastro> the same thing would apply to say, backup agents too
[20:27] <InformatiQ> jcastro: so the monitoring agent gets to be a subordinate of a service hmmm
[20:27] <InformatiQ> makes sense
[20:28] <jcastro> what agent do you use btw?
[20:28] <InformatiQ> sensu
[20:28] <jcastro> oh, we have that!
[20:28] <InformatiQ> i saw there is an agent already there
[20:28] <InformatiQ> but i am trying to get beyond just using things
[20:28]  * jcastro nods
[20:30] <InformatiQ> I am also thinking in terms of multiple services per machine
[20:30] <InformatiQ> so that means what when each service has an agent attached to it
[21:00] <jcastro> arosales, gary_poster would like us to move bundle workflows so he can attend it, I was thinking swapping it out with automated charm testing.
[21:00] <jcastro> this is for thursday
[21:01] <gary_poster> thank you for considering jcastro
[21:01] <jcastro> gary_poster, for the rest of the stuff you asked about we only have 2 "tracks" and we have to share with the rest of cloud/server, so that unfortunately is the case
[21:02] <gary_poster> jcastro, ack, figured it might be something like that
[21:02] <arosales> jcastro, +1
[21:05] <jcastro> marcoceppi, ok automated charm testing is an hour earlier than before on thursday
[21:23] <marcoceppi>  jcastroack
[21:49] <arosales> marcoceppi, rick_h_ had a question on charm testing urls
[21:50] <arosales> specifically https://jenkins.qa.ubuntu.com/job/precise-openstack-charm-mysql  is 404'ing
[21:50] <arosales> marcoceppi, afik those URLs ~should~ still be valid, but wanted to confirm with you.
[21:52] <arosales> marcoceppi, I think we are not seeing testing results at jujucharms.com as some testing aren't running
[21:52] <arosales> ie https://jujucharms.com/fullscreen/search/precise/mysql-29/?text=mysql
[21:52] <arosales> no test results
[21:52] <arosales> https://jujucharms.com/fullscreen/search/precise/jenkins-8/?text=jenkins
[21:52] <arosales> has test results
[21:56] <unbreak-it> Would this be a good place to get help on deploying juju on aws?
[21:59] <marcoceppi> unbreak-it: it would
[22:01] <unbreak-it> I can run `juju bootstrap` just fine, and an instance shows up in my EC2 management console. But when I run `juju status -v` it locks up after `INFO juju.state open.go:68 opening state; mongo addresses: ["ec2-54-226-186-205.compute-1.amazonaws.com:37017"]; entity ""`
[22:04] <unbreak-it> Any ideas what the issue could be?
[22:07] <arosales> unbreak-it, can you pastebin.ubuntu.com the output of "juju --debug status"
[22:07] <arosales> unbreak-it, also what juju version are you running?
[22:07] <arosales> juju --version