[06:27] <lazyPower> stub: http://bazaar.launchpad.net/~lazypower/charms/bundles/sentiment-analysis/bundle/view/head:/bundles.yaml
[06:35] <jcastro_> tvansteenburgh, can we kick off tests for this? http://review.juju.solutions/review/1087
[06:36] <jcastro_> I tried to click the button but it didn't do anything for me
[06:36] <jcastro_> robert would like to test his latest pushes
[06:37] <tvansteenburgh> jcastro: kicked
[07:38] <jcastro_> bcsaller, https://askubuntu.com/questions/611564/how-does-juju-get-the-private-address-of-a-node
[07:59] <mbruzek> jamespage Please send me a link to the actions document.
[08:15] <Bardhi> Hello everyone. I am new with juju and maas and im trying to get that installed and running in our company. I managed to get installed maas and juju, but when i want to deploy a service with juju it gets stucked in "allocating units" and it doesnt advance from there. It remains yellow it doesnt become green. If someone could help me how to solve this i wold appreciate it. Thank you
[09:15] <mwak> hi
[09:20] <ludvigx> anyone got a sec to help me out ? Trying to deploy the latests trusty/ceph-36 via juju, and it returns a agent-state-info: 'hook failed: "mon-relation-changed"' every single time.
[09:21] <ludvigx> or is this more just a ceph related question ? not sure :)
[09:34] <lazyPower> cory_fu: another fyi re: sync-watch - i'm getting consistent errors when watching subordinates
[09:47] <lazyPower> https://github.com/juju/plugins/issues/56
[09:53] <Bardhi|2> ello i am trying to deploy some services with juju but it gets stucked on allocating units and services are not deployed. i just started using juju and i am not an expert in using it and i dont know very well how it all works but i
[09:58] <g3naro> hello! is anyone here able to help noob
[09:59] <g3naro> root@falcon:~/.juju# juju deploy apache
[09:59] <g3naro> ERROR environment is not bootstrapped
[10:04] <hazmat> lazyPower: any presentation deck you recommend for giving a presentation on juju?
[10:07] <lazyPower> hazmat: i do, 1 sec
[10:07] <lazyPower> do you want the raw deck, pdf, or speakerdeck link?
[10:07] <lazyPower> hazmat: https://speakerdeck.com/chuckbutler/service-orchestration-with-juju
[10:08] <hazmat> lazyPower: looking, thanks
[10:10] <hazmat> lazyPower: that looks solid, thanks
[10:10] <hazmat> i'm giving a presentation on juju in a few hrs, and my decks are moldy ;-)
[10:12] <lazyPower> :) want the .odp file to make tweaks?
[10:12] <hazmat> lazyPower: that would be great
[10:12] <lazyPower> hazmat: the biggest change is juju is the modelling language, and not "the orchestrator" - we're enabling orchestration through the language model
[10:13] <lazyPower> https://www.dropbox.com/s/cvh31c2vrjbsrgm/service-orchestration.odp?dl=0
[10:13] <lazyPower> hazmat: ^
[10:13] <hazmat> g3naro: you have to bootstrap an environment before deploying
[10:14] <hazmat> lazyPower: that distinction seems subtle, so juju is not an orchestrator but a language runtime for orchestrator?
[10:14] <lazyPower> yeah, basically its a universal language to describe your infra as SOA
[10:24] <cory_fu> lazyPower: You and your damned subordinates.  ;)  Thanks for opening the issue
[10:25] <lazyPower> :3
[10:25] <cory_fu> marcoceppi: Where was that tool you showed for rendering a bundle svg?
[10:25] <marcoceppi> cory_fu: svg.juju.solutions
[10:26] <cory_fu> Hrm.  No form?  How do you post the bundle?
[10:26] <lazyPower> (۶ૈ ᵒ̌ Дᵒ̌)۶ૈ=͟͟͞͞ ⌨  GIVE US THE KNOWLEDGE MARCO
[10:27] <marcoceppi> cory_fu: read the instructions?
[10:27] <cory_fu> It says post, but there's no form to post
[10:27] <cory_fu> What am I, a wizard?
[10:27] <marcoceppi> yes, use HTTP to post to it
[10:27] <marcoceppi> or http://svg.juju.solutions/?bundle-file=http://bazaar.launchpad.net/~bigdata-dev/charms/trusty/apache-analytics-sql-hue/trunk/download/head:/bundles.yaml-20150420030716-vycsb0pcenhst8wt-1/bundles.yaml
[10:27] <marcoceppi> cory_fu: I thought you knew kung fu
[10:27] <marcoceppi> cory_fu: or http://svg.juju.solutions/?bundle=cs:bundle/openstack-telemetry-31
[10:28] <marcoceppi> https://github.com/marcoceppi/svg.juju.solutions
[10:28] <marcoceppi> no instructions, sorry, forgot I didn't write them yet
[10:28] <marcoceppi> still a WIP
[10:28] <cory_fu> Fair enough
[10:29] <marcoceppi> cory_fu: I'll be adding caching and faster processing (plus embedding SVG so it downloads more cleanly) soon
[10:31] <rogpeppe> jam: hiya
[10:31] <jam> rogpeppe: /wave
[10:32] <rogpeppe> jam: just wanted to give you a head's up regarding some changes we intend to make to the juju/charm repo
[10:32] <jam> sure, what's up?
[10:32] <rogpeppe> jam: we've had some cyclic dependency issues between the charm repo and charmstore
[10:32] <rogpeppe> jam: i made a little doc to explain things to ourselves: https://docs.google.com/document/d/10Ol5g2T688fih2wBTDk6ZO5h2I8dXjVI3hWTSpMaUew/edit
[10:33] <rogpeppe> jam: after some discussion, we've decided that solution 3 is the best way forward
[10:34] <rogpeppe> jam: YMMV so any feedback would be good
[10:35] <rogpeppe> jam: essentially this means moving the charmrepo package into a new repository. for juju-core, the implication should just be a simple import path rewrite with no other code changes required
[10:36] <jam> rogpeppe: what is "publicly depends on" vs "depends on" ?
[10:36] <jam> (it has a public API that uses a type defined in the other repo?)
[10:36] <rogpeppe> jam: yes
[10:36] <rogpeppe> jam: you said it much more neatly than i was trying to :)
[10:38] <rogpeppe> jam: this is also a possible precedent for a pattern that we might use more generally and eventually something that might be worthwhile for juju-core to use (so that juju Go clients don't have to incur all juju-core's dependencies)
[10:39] <jam> rogpeppe: so I'd like to understand why cycles in tests is ok
[10:39] <jam> because you have to set up the underlying objects to test against?
[10:40] <rogpeppe> jam: because it's possible to make forward progress even when there are cycles in tests
[10:40] <rogpeppe> jam: in the worst case, you might need to temporarily disable some tests
[10:41] <rogpeppe> jam: whereas in the situation we were in (with cycles in exported APIs) we literally couldn't make forward progress without some really nasty hackery (including charm.v6 needing to import charm.v5 in tests)
[10:41] <jam> rogpeppe: so its not *actually* possible to upgrade a version and have all the tests pass
[10:42] <rogpeppe> jam: it should be in most cases
[10:42] <rogpeppe> jam: you'll end up with the tests importing two versions of the package, but that is usually ok
[10:43] <jam> So charmstore is the actual server internals code, csclient is a consumer of the public API, what is charmrepo ?
[10:43] <jam> "charm" is the core data structure, right?
[10:44] <rogpeppe> jam: charmrepo is the API that juju uses, that layers onto csclient
[10:44] <rogpeppe> jam: yeah
[10:44] <rogpeppe> jam: charmrepo implements local repository handling too
[10:45] <jam> and params is shared implementation of types exported and imported between the server and clients?
[10:45] <rogpeppe> jam: charmrepo already exists, BTW: http://godoc.org/gopkg.in/juju/charm.v5/charmrepo
[10:45] <rogpeppe> jam: yes
[10:45] <rogpeppe> jam: similar to juju-core's params package
[10:49] <rogpeppe> jam: ha, this probably isn't the right channel for this discussion - i had intended #juju-dev
[10:55] <philip_stoev> Hello, how does one deploy a charm using uncommitted changes in a local bzr repository?
[10:55] <philip_stoev> I am using this command:
[10:55] <philip_stoev>  juju deploy --repository=. --config galera.yaml local:trusty/galera-cluster
[10:55] <philip_stoev> and the charm being deployed does not contain the local uncommitted changes
[11:08] <rogpeppe> philip_stoev: AFAIK the juju deploy command doesn't know about the bzr repo at all
[11:08] <rogpeppe> philip_stoev: so it should just see all the files as they are (including uncommitted changes)
[11:09] <rogpeppe> philip_stoev: what does it do if you try to deploy the charm when there's no .bzr directory at all (for instance, move it out of the way or make a copy of the charm dir without it) ?
[11:09] <rogpeppe> philip_stoev: it's possible that this is an existing bug with juju deploy with respect to local charms actually
[11:10] <rogpeppe> philip_stoev: have you already previously deployed that charm to the environment?
[11:10] <philip_stoev> I found out that it is safer to destroy the environment every time. Otherwise it seems I am always getting a cached version of the charm
[11:11] <philip_stoev> Actually committing to the local repository did not help
[11:12] <philip_stoev> so, with a fresh environment
[11:12] <philip_stoev> I am still getting files from the Charm Store
[11:12] <philip_stoev> Even though I provided  --repository=. local:trusty/galera-cluster to juju deploy
[11:13] <philip_stoev> Does juju have some local cache that I need to purge?
[11:14] <philip_stoev> I have no ~/.juju/charmcache on the local machine
[11:17] <philip_stoev> --upgrade has been deprecated
[11:17] <philip_stoev> so what is left apart from committing every revision to the charm store?
[11:22] <rogpeppe> philip_stoev: i think the problem is the revision number of the local charm
[11:23] <rogpeppe> philip_stoev: i encountered this problem with gocharm, and worked around it
[11:23] <philip_stoev> I think I got what the problem is, for some reason I had multiple copies of the charm locally, so --repository=. was picking the wrong directory
[11:23] <rogpeppe> philip_stoev: if you create a "revision" file and increase the revision number in it each time, it may fix your issue
[11:23] <philip_stoev> thanks
[11:24] <rogpeppe> philip_stoev: ah, that can also be a problem
[11:24] <rogpeppe> philip_stoev: the local repository logic is weird
[11:24] <rogpeppe> philip_stoev: it ignores the name of the directory and just looks at the charm name in the metadata.yaml
[11:25] <rogpeppe> philip_stoev: and then takes the one with the highest revision, or the last alphabetically by directory name
[11:25] <philip_stoev> I was able to make it pick up the right files ...
[11:25] <philip_stoev> so I am good
[11:25] <rogpeppe> philip_stoev: cool
[11:25] <philip_stoev> thanks for the help
[11:26] <philip_stoev> I have a more conceptual question regarding Juju
[11:27] <philip_stoev> Assuming I have started a service, e.g. MySQL , is it a strict juju requirement for other services to connect to it only through juju relations and interfaces?
[11:28] <philip_stoev> If not, then it seems it is difficult for the user to simply obtain the IP of the service and then use that IP as needed
[11:28] <philip_stoev> juju status seems to be the easiest way
[11:28] <philip_stoev> as it is difficult to have juju create a database and spit out the complete connection URL
[11:28] <philip_stoev> unlesss relations are used
[13:18] <lukasa_work> Is there any way I can force Juju to run a hook?
[13:18] <lukasa_work> neutron-api seems to have rendered an incorrect neutron.conf, and I'd like it to re-render
[13:25] <cory_fu> lukasa_work: Easiest way would be to change and reset a config value.  If you don't want to do that, you *might* be able to manually run the config-changed hook using `juju run`
[13:26] <cory_fu> But I'm not at all certain that won't cause you more issues
[13:26] <cory_fu> It depends heavily on how the charm is implemented.
[13:47] <plars> So I got python-jujuclient upgraded and now juju-deployer tries to run at least, but I'm hitting this now. Any ideas?
[13:47] <plars> https://www.irccloud.com/pastebin/VUvzEJIo
[14:55] <g3naro> juju deploy apache
[14:55] <g3naro> ERROR cannot resolve charm URL: "cs:apache"
[14:55] <g3naro> any ideas?
[14:55] <lukasa_work> The charm is called apache2. =)
[14:55] <g3naro> ohhh
[14:55] <g3naro> :D
[14:56] <g3naro> what what!! first lxc-local deployed
[14:58] <jcastro_> g3naro, \o/
[15:18] <g3naro> but what is the defualt user/pass :(
[15:22] <roadmr> g3naro: use juju authorised-keys to add an ssh key to your containers, then you can ssh into them, no need to use user/password
[15:22] <roadmr> g3naro: https://jujucharms.com/docs/stable/howto-authorised-keys
[15:33] <g3naro> roadmr, thanks! looking now
[15:34] <g3naro> i found in .juju/environments/local.jenv
[15:34] <g3naro> it has correct ssh key but still giving me denied
[15:35] <roadmr> g3naro: how are you doing ssh into the container?
[15:40] <g3naro> ssh -i ssh -i juju_id_rsa.pub juju@10.0.3.167
[15:40] <g3naro> also without the juju@
[15:40] <g3naro> anhd without .pub of course
[15:41] <g3naro> ssh -i juju_id_rsa 10.0.3.167
[15:41] <g3naro> ohh its ubuntu@
[15:41] <g3naro> what hwat :D
[15:42] <jrwren> juju ssh is your friend :)
[15:42] <g3naro> juju ssh ?
[15:43] <g3naro> oh leet
[15:43] <g3naro> is anyone running juju for prod
[15:43] <stub> tvansteenburgh: I will need to add Adam's actions in a separate branch, as it needs to be taught how to connect to a cluster with authentication enabled.
[16:32] <tvansteenburgh> stub: ack
[17:32] <Aligner> Hi, if I upgrade charms with juju upgrade-charm, do I need to redeploy everything for the upgraded version to take affect?  I am trying to upgrade some charms but I can't tell if the applications are newer version