=== CyberJacob is now known as CyberJacob|Away
[00:23] <marcoceppi> michal_s: can you provide the logs from /var/log/juju/juju-wordpress-0.log ?
=== freeflying is now known as freeflying_away
=== freeflying_away is now known as freeflying
=== sivatharman__ is now known as psivaa
[09:03] <michal_s> marcoceppi: I will deploy clean WP today and copy logs. Thank You for replay.
[11:55] <fwereade> marcoceppi, ping
=== gary_poster|away is now known as gary_poster
[13:37] <marcoceppi> fwereade: pong
[13:42] <jcastro> marcoceppi, heya
[13:42] <jcastro> Welcome back everyone!
[13:43] <hatch> wb jcastro!
[13:44] <marcoceppi> jcastro: o/
[13:45] <jcastro> Man dude, there's a foot of snow on the ground
[13:45] <jcastro> marcoceppi, I was in the caribbean a week ago. What happened.
[13:46] <marcoceppi> jcastro: sounds like you should head back to the caribbean. It's been quite around here, most people enjoying the holidays
[13:47] <jcastro> nod
[13:48] <jcastro> hmm, did you do a tools release over the break?
[13:48] <jcastro> got a new one in the PPA
[13:53] <marcoceppi> jcastro: maybe, I don't remember. I've got a new amulet release I'm pressing right now
[13:53] <marcoceppi> and there were some updates to python-charmworldlib
[13:54]  * jcastro nods
[13:58] <fwereade> marcoceppi, hey dude
[13:58] <fwereade> marcoceppi, I wanted a quick read on https://bugs.launchpad.net/juju-core/+bug/1100076
[13:58] <_mup_> Bug #1100076: subordinate require juju-* relations should be deprecated <juju-core:Triaged> <https://launchpad.net/bugs/1100076>
[13:58] <fwereade> marcoceppi, basically I would like to claw back the "juju-*" namespace for relations
[13:58] <marcoceppi> fwereade: looks exciting, I'll take a peek
[13:59] <marcoceppi> fwereade: oh, that was a lot more straight forward then I thought
[13:59] <fwereade> marcoceppi, yeah, I didn't think it seemed *that* exciting, but who am I to judge? ;p
[14:00] <marcoceppi> fwereade: so, I noticed a lot of charms doing this already. Just specifying a different interface name then having the scope variable set (or whatever it is)
[14:00] <fwereade> marcoceppi, yeah, it's really just a bunch of trivial name changes
[14:00] <marcoceppi> fwereade: My question, what about subordinates that don't share any inheritance?
[14:00] <fwereade> marcoceppi, but it's all more work for busy people
[14:00] <marcoceppi> fwereade: like the rsyslog-frowarder charm
[14:01] <fwereade> marcoceppi, not sure -- restate please?
[14:01] <marcoceppi> fwereade: so juju-info is used to say "this is the fallback interface, if there is no matching interface name on the parent charm of the relation"
[14:02] <marcoceppi> that way the charm the sub is attaching to doesn't have to have an interface for a subordinate, juju-info is the implicit interface name for that matching
[14:02] <marcoceppi> How would that be handled in a 2.0 where juju-* were removed?
[14:03] <fwereade> marcoceppi, we'd still be providing juju-info, that'd just require (say) "info" -- and still require the juju-info *interface*, and it should keep working just fine
[14:03] <fwereade> marcoceppi, the falling back happens anyway
[14:03] <fwereade> marcoceppi, juju only matches implicit relation when it can't match an explicit one
[14:04] <marcoceppi> fwereade: right, so what's the question here?
[14:04] <marcoceppi> What's the goal of the bug, if juju-info will remain an option?
[14:05] <marcoceppi> maybe I missed something, it's still still early in the year :)
[14:05] <fwereade> marcoceppi, the goal is to prevent people from naming things "juju-"
[14:05] <fwereade> marcoceppi, so that we have that namespace to play in ourselves
[14:05] <marcoceppi> fwereade: as a relation name?
[14:05] <fwereade> marcoceppi, without fear of collision
[14:05] <fwereade> marcoceppi, yeah
[14:05] <marcoceppi> oh, yeah that's totally cool then
[14:06] <marcoceppi> I can add that as a proof item, just an INFO output, so we can start tailoring people away from that now
[14:06] <marcoceppi> fwereade: but it makes sense
[14:06] <fwereade> marcoceppi, that would be *great*, yes please
[14:06] <fwereade> marcoceppi, and I'll throw the bug over the wall at arosales and leave the getting-it-scheduled to him, I guess?
[14:07] <marcoceppi> fwereade: I can add it to our board, and I'll just generate a new bug on charm-tools with a reference to this one
[14:07] <marcoceppi> fwereade: as it firms up and becomes an actually reserved relation name in juju we'll move the status of the proof item from I to E
[14:08] <fwereade> marcoceppi, that's fantastic -- can you think of a good way to make us remember to actually disallow it in juju when your side of the bug is fixed?
[14:09] <fwereade> marcoceppi, ie the fix-existing-charms side
[14:09] <marcoceppi> fwereade: once it's in proof, it'll get caught during our audit that's on going
[14:09] <marcoceppi> so the majority of charms should be addressed with this
[14:10] <marcoceppi> fwereade: I'll make a note about the bug to have you pinge/comment on the bug once the audit is over
[14:10] <fwereade> marcoceppi, ok, awesome
[14:11] <fwereade> marcoceppi, I'll drop this one to "low" then with a note that it's an easy fix once the ecosystem is updated
[14:13] <marcoceppi> fwereade: https://bugs.launchpad.net/charm-tools/+bug/1265524
[14:13] <_mup_> Bug #1265524: juju-* relation names to be depreciated <Juju Charm Tools:Triaged by marcoceppi> <https://launchpad.net/bugs/1265524>
=== dannf` is now known as dannf
[16:48] <manjiri> Happy New Year! Just by trying it out, I was able to use "local": "cassandra" in the juju-deployer json configuration file. Where is "local" documented? (only "branch" is documented as far as I can tell).
[16:49] <rick_h_> manjiri: https://juju.ubuntu.com/docs/charms-deploying.html#local might be a good start.
[16:51] <manjiri> rick_h_: I am referring to "juju-deployer" for which the documentation is here: http://pythonhosted.org/juju-deployer/
[16:51] <rick_h_> manjiri: right, but it's just doing a deploy of those services specified
[16:51] <rick_h_> manjiri: so understanding how to deploy a local charm fits into the usage you're doing
[16:53] <manjiri> rick_h_: I think I understand how to use the documentation for "juju deploy", but it is not clear to me how to map that to juju-deployer. I feel like I am missing a link between the two.
[16:53] <rick_h_> manjiri: what are you trying to do that you're not sure about?
[16:55] <manjiri> rick_h_: juju-deployer documentation mentions "branch: lp:charms/precise/wordpress". There is no mention of "local: <charm>". Yet, when I tried it, it worked! That seems mysterious.
[16:56] <rick_h_> manjiri: ah, well there's some limitations currently. The juju gui, which accepts deployer files, does not work with local charms.
[16:56] <rick_h_> manjiri: I'm not sure where the docs on the deployer are as far as up to date-ness. A bug on that might be worthwhile.
[16:57] <manjiri> rick_h_: Actually, what I am saying is, that it DID work. It works but there is no documentation about it. (I am aware that the charm icon won't show).
[16:57] <rick_h_> manjiri: right, understand.
[16:58] <rick_h_> manjiri: I'd suggest filing a documentation bug https://bugs.launchpad.net/juju-deployer
[16:59] <manjiri> rick_h_: I will file a bug. I have already filed one for "weights" which is not documented either. Thanks!
[17:00] <manjiri> rick_h_: About the icon not showing, I was aware that an icon that has not been reviewed will not show. But even ones that are officially published e.g. keystone do not show if juju-deployer is used. I have filed a bug for that as well.
[17:01] <rick_h_> manjiri: it will only show if it's the official reviewed version of the charm.
[17:01] <rick_h_> manjiri: from the charm store itself
[17:01] <rick_h_> manjiri: otherwise, a forked charm, local charm, etc, it will not
[17:02] <rick_h_> manjiri: note that only one has the icon https://jujucharms.com/fullscreen/search/?text=keystone
[17:03] <manjiri> rick_h_: The configuration file for juju-deployer says "branch": "lp:charms/keystone" - I got this file from https://help.ubuntu.com/community/UbuntuCloudInfrastructure/JujuBundle
[17:04] <rick_h_> manjiri: hmm, yea that's via the lp branch name and not the cs: url. I wonder if that's the issue then.
[17:05] <rick_h_> manjiri: since it's not the cs:precise/keystone url I don't think it'll show.
[17:07] <manjiri> rick_h_: I have tried to ask the person - jorge.castro@canonical.com  - who last updated that configuration questions about it - but I have not received any response. I am not sure what is expected to work and how well.
[17:08] <manjiri> rick_h_: All of the bugs I have filed against juju/juju-deployer/openstack are based on that configuration file. But those bugs have yet to be looked at. Perhaps the holiday season is why the progress has been slow. I am looking forward to more information on that configuration file!
[17:09] <rick_h_> manjiri: definitely, most people were well away and slowly getting back
[17:10] <jcastro> manjiri, hi, can you reforward me your mail? I don't see a mail about the openstack bundle, maybe I missed it?
[17:11] <manjiri> jcastro: Sure thing. You can ignore the particular question in that email - I found a bug that suggests that console support is known to be lacking in the nova compute charm.
[17:12]  * jcastro nods
[17:12] <manjiri> jcastro: I have re-sent the email.
[17:13] <manjiri> rick_h_: jcastro:  Btw, I am working with Kapil, Adam and few others on this project. They suggested that IRC and Bugs are the way to get answers to my questions.
[17:14]  * jcastro nods
[17:14] <rick_h_> manjiri: definitely.
[17:16] <jcastro> manjiri, most of us got back to work today; we're not normally slow
[17:16] <jcastro> well, not _too_ slow anyway. :)
[17:17] <manjiri> jcastro: rick_h has helped me out a couple of times... Its all good.
[17:18] <jcastro> sweet!
[17:38] <manjiri> rick_h_: Just tried cs:precise/keystone with juju-deployer. Does not like it. Only likes "lp:"
[17:38] <rick_h_> manjiri: ah, did you use hte branch: keyword?
[17:38] <rick_h_> manjiri: I think it only works with charm: cs:precise/keystone. /me goes to check
[17:39] <rick_h_> manjiri: yea, see http://bazaar.launchpad.net/~jorge/charms/bundles/mediawiki-scalable/bundle/view/head:/bundles.yaml for an example
[17:42] <manjiri> rick_h_: jcastro: It would be nice to know what in https://help.ubuntu.com/community/UbuntuCloudInfrastructure/JujuBundle is expected to work and what is not.
[17:50] <manjiri> rick_h_: charm: keyword didn't work either
=== gary_poster is now known as gary_poster|away
=== gary_poster|away is now known as gary_poster
[18:18] <marcoceppi> manjiri: where did you get juju-deployer from, what version is the package?
[18:19] <manjiri> marcoceppi: 0.2.5-0ubuntu1~ubuntu12.04.1~juju1
[18:20] <marcoceppi> manjiri: huh, yeah that's the lastest
[18:23] <manjiri> marcoceppi: My biggest concern is the documentation on juju-deployer. The icon issue is negligible at this time.
[18:24] <marcoceppi> manjiri: have you checked this? http://bazaar.launchpad.net/~juju-deployers/juju-deployer/trunk/files/head:/doc/
[18:25] <marcoceppi> manjiri: possibly a bit out of date
[18:26] <manjiri> marcoceppi: Sorry, but I don't see the "manual" doc here
[18:26] <marcoceppi> manjiri: config.rst
[18:30] <manjiri> marcoceppi: Ah! That does not mention "local" or "weight" keywords. I tried "local" on a hunch and it worked (!) and "weight" is actually used in https://help.ubuntu.com/community/UbuntuCloudInfrastructure/JujuBundle. I am not stuck at the moment, but knowing that "latest" documentation isn't complete warns me that future issues will be hard to figure out.
[18:30] <marcoceppi> manjiri: dev seems to be going faster than docs on this
[18:31] <marcoceppi> manjiri: so, IRC is probably your best bet, and other people's examples
[18:31] <manjiri> marcoceppi: Sounds like it. Thanks for your help!
[18:32] <marcoceppi> manjiri: I saw you mentioned keystone, here's a few openstack examples in deployer format: http://bazaar.launchpad.net/~james-page/charms/bundles/openstack-on-openstack/bundle/view/head:/bundles.yaml
[18:36] <manjiri> marcoceppi: It appears that yaml is more popular that json for deployer? Is that correct?
[18:36] <marcoceppi> manjiri: it's subjective. both are supported equally given one is a subset of the other
[18:37] <marcoceppi> manjiri: yaml is generally preferred and used without the juju project (environments.yaml, config.yaml, etc)
[18:37] <marcoceppi> as such deployer uses yaml and most of the examples are in yaml
[18:37] <marcoceppi> but I know json is def supported if you're more comfortable with that format
[18:38] <manjiri> marcoceppi: My starting point was json file posted on https://help.ubuntu.com/community/UbuntuCloudInfrastructure/JujuBundle, but since then I have only seen yaml examples... I will switch to yaml.
[18:39] <marcoceppi> manjiri: huh, interesting
=== CyberJacob|Away is now known as CyberJacob
[20:28] <bic2k> If I wanted to move the juju CLI configs from my personal machine to a more central machine, what would I do? I have copied over the contents of my ~/.juju but it insist on wanting to bootstrap still
=== cmagina_ is now known as cmagina
=== gary_poster is now known as gary_poster|away
=== kentb is now known as kentb-away