[08:00] <jamespage> adam_g, if you are in today - https://code.launchpad.net/~james-page/charms/precise/keystone/fix-requested-roles/+merge/183580
[08:00] <jamespage> that's the cause of the openstack-dashboard lack of member role stuff that jpds hit last week
[08:01] <jamespage> they are not using swift and the keystone identity-changed hook was not creating the role for services not registering endpoints....
[08:58] <raywang> helle jamespage
[13:04] <marcoceppi> kurt__: Is the unit in a dying state? RE: Before I file a bug, is it a known issue with the inability to destroy service in 1.12 with status showing stuck in "life: dying" ?
[13:04] <marcoceppi> hazmat: pong
[13:04] <kurt__> hi marcoceppi: I did file bug.  Sorry have to run
[13:06] <marcoceppi> kurt__: no worries
[13:06] <marcoceppi> kurt__: is the unit in an error state* is what I meant to ask
[13:07] <kurt__> I think so, yes
[13:15] <marcoceppi> kurt__: cool, next time you want to kill them off, just run `juju resolved <unit-in-errror-that's-dying>` a few times
[13:15] <marcoceppi> this is expected behaviour of juju
[13:50] <X-warrior> If I'm receiving relation not found, when adding a relation between 2 charms. It means that the metadata from both doesn't match?
[14:16] <marcoceppi> X-warrior: Is this in regards to your editing the metadata.yaml file after deployment?
[14:17] <jcastro> jamespage: http://askubuntu.com/questions/340465/juju-ceph-deployment
[14:20] <jamespage> jcastro, posted
[14:20] <jamespage> its a bitch
[14:20] <jamespage> second hit in three days on that one
[14:20] <jcastro> nice!
[14:21] <jcastro> jamespage: where else? should I post it somewhere?
[14:21] <jamespage> jcastro, raywang pinged me about it as well
[14:21] <jamespage> thats where I raised that bug from
[14:21]  * jcastro nods
[14:21] <jamespage> I pulled back the point release to ensure it got included
[14:41] <X-warrior`> marcoceppi: yes, I created a service but I forgot to add a 'relation joined' on it to provide the service address
[14:46] <hazmat> marcoceppi, pong
[14:46] <marcoceppi> hazmat: hey, just got your ping from a day ago
[14:46] <marcoceppi> 2 days*
[14:47] <hazmat> hmm.. that thought is paged to disk
[14:47] <hazmat> oh..
[14:47] <hazmat> marcoceppi, i was wondering about getting juju-plugins up to snuff
[14:47] <marcoceppi> hazmat: sure
[14:47] <hazmat> i'm currently tossing tangentially related plugins into deployer
[14:48] <hazmat> but some are not.. and i'm wondering if we should fold everything into something like juju-plugins
[14:48] <marcoceppi> hazmat: I've got juju-plugins already, it's really light weight, but I'm happy to beef it up in terms of adding more plugins to it
[14:48] <hazmat> some of the packaging dependencies might increase though depending on the plugin
[14:49] <marcoceppi> hazmat: I was considering doing a package per plugin, with a "juju-plugins-all" package to install all plugins
[14:49] <hazmat> marcoceppi, the juju-faststat plugin for example from the ml.. is a nice speed focused status replacement for the moment.
[14:49] <marcoceppi> hazmat: just to keep the list of dependencies down for single plugins
[14:49] <hazmat> marcoceppi, package per plugin sounds bad..
[14:49] <hazmat> er. overkill
[14:50] <marcoceppi> hazmat: okay
[14:50] <marcoceppi> well if
[14:51] <marcoceppi> well it's a trade off then, lots of deps, or bunch 'o packages
[14:51] <marcoceppi> I'm fine either way, whichever convention makes the most sense
[14:56] <marcoceppi> hazmat: right now they're just all in one package
[14:56] <marcoceppi> so we can just keep it that way
[15:26] <X-warrior`> this is my 2 metadata.yaml ( http://pastebin.com/KbXLkQ4K ), if I would like to add a relation from service to authserver, where authserver will provide it ip address ... does the authserver needs a hooks/authserver-relation-joined and the service needs a hook hooks/authserver-relation-changed. And the commmand should be 'juju add-relation authserver service'
[15:38] <marcoceppi> X-warrior`: Pretty much, you can get the IP address of a current running unit with `unit-get private-address` so your hooks/authserver-relation-joined hook would look like `relation set hostname=$(unit-get private-address)` and the authserver-relation-changed on the other service would havethe following `relation-get hostname` to recieve that value
[15:38] <marcoceppi> X-warrior`: however, unless it truely implements the HTTP protocol (which requires both a port and hostname to be set) I'd recommend naming the interface something different
[15:39] <marcoceppi> using the HTTP interface tells juju that your authserver could work with haproxy, varnish, etc. If that's not the case you'll want to use a different interface name
[15:39] <marcoceppi> If that is the case you'll want to make sure you set both the hostname and the port options in the relation-set command
[15:40] <marcoceppi> likewise, your service charm requring the http interface means it could connect to wordpress, mediawiki, and a majority of other charms and be able to handle that data properly. So, if that isn't the case, you'll want to do what I recommended above and create a new interface name (or find an existing interface that matches what you're trying to do)
[15:40] <marcoceppi> Since the interface name is what juju uses to match charms with each other
[15:43] <X-warrior`> marcoceppi: could I name it with any name as I want?
[15:43] <marcoceppi> X-warrior`: yup! Anything that makes sense to what that interface is for
[15:44] <marcoceppi> X-warrior`: so you could call it "authserver" as the interface, then the first metadata.yaml relation name could be server and the second one's relation name could client
[15:44] <marcoceppi> X-warrior`: interface could be authserver for both, but you could name the relations in a way that makese sense of what the role of the relation is to the charm
[15:44]  * marcoceppi creates an example paste
[15:45] <marcoceppi> X-warrior`: http://pastebin.com/iUVJb6Fk
[15:46] <marcoceppi> X-warrior`: I wouldn't use such a generic name as "authserver", unless you can make the interface generic, If it's a particular authentication softare, like ldap, I'd name the interface ldap or something similar
[15:46] <marcoceppi> X-warrior`: the interface should embody exactly it's purpose. So we have generic interfaces, like http, and specific ones, like mysql or pgsql
[15:47] <marcoceppi> X-warrior`: while the name is up to you, we do prefer people to name them wisely, at least for the store.
[15:47] <marcoceppi> If these are just for you, you can do whatever
[15:47] <marcoceppi> FOr the store we'd prefer it to be more specific, but again it's up to you
[15:48] <X-warrior`> for now I'm just running more tests to understand how it works
[15:48] <X-warrior`> but I know what you mean
[15:48] <X-warrior`> :D
[15:55] <X-warrior`> marcoceppi: the test worked destroying the machines and redeploying...
[15:55] <marcoceppi> X-warrior`: sweet!
[15:55] <X-warrior`> ty
[15:55] <X-warrior`> :D
[16:16] <X-warrior`> What does the 'IDEMPOTENCY' means? I mean, let's say I have a hook to a db relation changed... and this hook add the options (login, pass, dbname, etc) to a file... if it is idempotent the login, pass, dbname will not be updated. So I'm not sure I understand what does the "# IDEMPOTENCY is very important in all charm hooks, even the install hook. " means from https://juju.ubuntu.com/docs/authors-charm-writing.html
[16:17] <jrwren> it means it can run again with the same result.
[16:17] <jrwren> where same result means it doesn't hurt either.
[16:17] <jrwren> so I can run it 100 times and everything is still good. I don't have things like messed up config with 100 screwed up lines.
[16:18] <jrwren> of course that is my bad interpretation of what it means. It has a much nicer computer science definition which you are free to google.
[16:18] <X-warrior`> well the definition means it will be exactly the same.
[16:19] <X-warrior`> But on a relation-changed event... if you do it, it will preserve the values that was there before it calls the hook... so it doesn't make sense to me
[16:19] <X-warrior`> le
[16:26] <marcoceppi> X-warrior`: idempotency means with the same set of parameters, the hook will produce the same results
[16:26] <X-warrior`> marcoceppi: ty
[16:41] <m_3> bbcmicrocomputer: please mark reviews in progress when you start them this week
[16:41] <m_3> so we won't step on each others toes
[16:41] <jcastro> fwereade: heya
[16:42] <jcastro> or jam
[16:43] <bbcmicrocomputer> m_3: ok, sure
[17:20] <mrsolo> hi where does juju store ssh private-key?
[17:22] <mrsolo> nm got it
[18:40] <fwereade_> jcastro, heyhey
[18:42] <jcastro> fwereade_: hey so I was wondering when we can default to the local provider
[18:42] <jcastro> but I think we can do that at the distro level instead of upstream?
[18:43]  * jcastro needs to ask jamespage
[18:43] <fwereade_> jcastro, to be fair, I should not be trusted with anything distro-related
[18:44] <jcastro> fair enough ... James Page it is!
[19:03] <jamespage> jcastro, ?
[19:04] <jcastro> jamespage: hey so I was thinking, we should default to local in juju in the distro
[19:05] <jcastro> instead of "amazon"
[19:05] <jcastro> so when someone apt-get install's juju
[19:05] <jcastro> they can deploy right away without anything else
[19:05] <jamespage> jcastro, is that not driven by their environments.yaml?
[19:06] <jcastro> it is
[19:06] <jcastro> but by default right now it's "amazon"
[19:06] <jamespage> ah
[19:06] <jamespage> hmm
[19:06] <jcastro> jamespage: also, out of curiosity .. do we need all 61MBs of mongodb-clients?
[19:07] <jcastro> seems like a rather heavy dep ...
[19:07] <jamespage> jcastro, yeah - that does suck
[19:07] <jamespage> I'll take a look
[19:07] <jamespage> juju generate-config generates environments.yaml tho
[19:08] <jamespage> jcastro: so I think thats a change in juju-core right?
[19:08] <jamespage> we can Recommend: juju-local from juju which means by default you get the local provider
[19:08] <jcastro> ok
[19:08] <jcastro> I was unsure if this would be an upstream thing or a distro thing, the choosing of a default
[19:09] <jcastro> I think I'll just ping thumper when he comes online and ask him to do it
[19:25] <jamespage> jcastro, ack
[19:28] <jam> jamespage: recommending juju-local means that by default you end up with a mongodb-server running on your local machine (even before "juju bootstrap") because of how the mongodb-server package works
[19:28] <jam> which I *think* defaults to 3GB prealloc
[19:28] <jamespage> jam: yep
[19:28] <jamespage> ouch
[19:28] <jamespage> OK - I won't do that
[19:28] <jamespage> jcastro, that makes making local the default tricky
[19:29]  * jcastro nods
[19:29] <jam> jamespage: I'm not positive about the 3GB prealloc, but I am sure that you end up with mongodb running on a port nobody will connect to.
[19:29] <jcastro> hey so could we do it so if you install juju by itself
[19:29] <jcastro> it does what it does now
[19:29] <jamespage> jam: that rings a bell - I had issues with the DEP-8 tests I wrote because it won't start on a 2GB root
[19:29] <jcastro> but if you install juju-local we do the right thing to make it spin up local with no config other than installing the package?
[19:30] <jam> jamespage: I know you can configure with or without prealloc, I'm just not sure what the .deb default is today.
[19:30] <jamespage> realloc
[19:30] <jamespage> prealloc rather
[19:30] <jamespage> jcastro, you still get a mongodb-server running in the background that no-one is actually using...
[19:30]  * jcastro nods
[19:31] <jcastro> ah nuts ... :-/
[19:31] <jamespage> jcastro, if we had thought about this a bit harder I'd have split the binary into a monogodb-server-common package
[19:31] <jamespage> and then just install the init script in the mongodb-server package
[19:31] <jcastro> jamespage: so it's probably better to leave that an explicit decision by the user then?
[19:31] <jamespage> jcastro, I think so yes
[19:31] <jcastro> jamespage: is that something we can do post-13.10 bute pre-14.04 you think?
[19:31] <jamespage> yes
[19:32] <jcastro> ok .... /me PUNTS the ball
[19:33] <jam> jamespage: it would be nice that if you "apt-get install juju-local" you would end up with an environments.yaml that points to local
[19:33] <jamespage> jam: that involves a package manipulating user data != no go
[19:33] <jam> jcastro: I think there is a bug about switching to local by default because we know you have those creds. And if bootstrap doesn't work we could tell you about the apt-get juju-local package.
[19:34] <jam> jamespage: I did say "would be nice" but even if "juju init" does that bit
[19:34] <jcastro> I remember filing a bug with thumper @ IOM, but I haven't been able to find it all day
[19:39] <jackweirdy> Hey all; I'm entering the charm championship and I'm having trouble with Juju - I'm running 13.04 on the stable juju ppa. I'm running kvm and I was wondering if I could configure an environment to spin up a new VM in KVM when I run juju deploy? I've found docs for stuff like OpenStack, but that's a bit heavyweight for what I want :)
[19:40] <jackweirdy> (unless it's not? I'm new to all this so I may have the wrong end of the stick :) )
[20:05] <jackweirdy> Googling suggests this isn't possible :s Can I add custom environment handlers?
[20:09] <jam> jackweirdy: juju has support for LVM containers, we haven't yet implemented KVM support
[20:10] <jam> you can install "juju-local" from the ppa, and then set up a "local" environment.
[20:11] <jackweirdy> Ok; thanks anyhow :)
[20:11] <jackweirdy> Does the local environment use lxc?
[20:20] <sinzui> Hi charmers, login to manage.jujucharms.com is broken at the moment. Those already logged in can feature and QA charms. We expect a fix in a few hours
[20:48] <adam_g> hazmat, darwin merged to lp:juju-deployer
[21:14] <xnox> jam: LVM is a type of volume/disk storage, it's not a container....
[21:14] <xnox> jackweirdy: yeap local environment uses lxc.
[21:18] <thumper> morning
[21:18] <bac> hi thumper