[00:47] <mwhudson> are there many charms for trusty yet?
[00:48] <mwhudson> or does that sort of thing wait until after trusty is out?
[00:56] <Kupo24z> Hey all, is it possible to select a MAAS node when running the first 'juju bootstrap' to setup the juju environment? I have pre-defined nodes and I'd like to make sure it provisions on the right one
[01:08] <davecheney> mwhudson: the latter
[01:10] <mwhudson> davecheney: is the cheat in the mean time branching all the precise repos to $localcharmrepo/trusty or however you do that?
[01:11] <rick_h_> mwhudson: do you need them to run on trusty? You can just juju deploy precise/mysql for instance?
[01:11] <davecheney> mwhudson: correct
[01:11] <mwhudson> rick_h_: i am mostly interested in architectures that are only supported in trusty :-)
[01:12] <davecheney> rick_h_: that is the main rason
[01:12] <rick_h_> mwhudson: if you download zip of a charm you can drop it on the gui and pick the series to use
[01:12] <rick_h_> mwhudson: ah gotcha
[01:12] <mwhudson> well i guess armhf was in precise but i still want to be closer to the bleeding edge
[01:12] <mwhudson> rick_h_: ok, bit tedious when dealing with a gigantic bundle
[01:12] <mwhudson> (unless there is a trick for that too)
[01:13] <rick_h_> mwhudson: definitely, no trick until we get fat bundles and the like
[01:13] <mwhudson> ah ok
[08:12] <melmoth> hola juju people ! With juju 1.18.0 i have been told one can tell juju, when using openstack provider, to use a given neutron network for vms (so it does not die when the current tenant as several available networks).
[08:12] <melmoth> any idea actually how to tell juju wich net to use ?
[08:24] <melmoth> ahhh, most probably the new network setting that is in environment.yaml
[08:31] <frankban> rbasak: morning. the new quickstart package(in your ppa)  seems to work very well
[09:02] <rbasak> frankban: great, thanks! I'll upload.
[09:03] <frankban> rbasak: cool thank you
[09:08] <rbasak> (done)
[11:35] <noodles775> I'm having to `sudo pkill mongod` each time I re-bootstrap a local environment. Is this known, or the same issue as bug 1208430 ?
[11:35] <_mup_> Bug #1208430: mongodb runs as root user <mongodb> <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1208430>
[13:58] <melmoth> i m experiencing problem with juju 1.18.0 tyring to use it behind a proxy.
[13:58] <melmoth> https://pastebin.canonical.com/108082/
[13:58] <melmoth> if anyone has an idea, you are welcome
[14:16] <mgz> melmoth: can you access the maas API directly using HTTP_PROXY envvar and wget say? doesn't seem like a juju related error
[14:17] <melmoth> i dont need a proxy to access MAAS, and the proxy had no access to MAAS directly
[14:18] <melmoth> (all my boxes, MAAS as well are vm in a hypervisor;hosted on some libvirt network). The proxy is a real proxy that my main hypervisor must use to access external boxes
[14:18] <melmoth> so if i try to access the maas box via the proxy, it will not work.. is it what is going on here ?
[14:20] <mgz> melmoth: printenv?
[14:21] <melmoth> mgz http://pastebin.com/UsBbLR5u
[14:21] <melmoth> (i m using juju directly from the box where maas is installed)
[14:26] <mgz> melmoth: that's odd. what about /home/ubuntu/.profile and /home/ubuntu/.juju-proxy? running juju from inside of the maas... that it's using itself? seems shakey.
[14:26] <melmoth> i always did it that way.
[14:26] <melmoth> i mean, juju is just a client, it should be ran from...anywhere
[14:27] <melmoth> i could fire up yet a new vm just for it, but, i never had to, nor do i see the point
[14:27] <melmoth> lets have a look at the profile
[14:28] <melmoth> http://pastebin.ubuntu.com/7226462/
[14:29] <mgz> well, I have no idea where your juju client is getting the proxy setting from then.
[14:29] <melmoth> well, from the nevironement most probably, i did set juju set http-proxy
[14:29] <melmoth> because i need the new machine to use the proxy
[14:29] <melmoth> that was the whole point of the exercice
[14:30] <melmoth> but i dont need communication from the juju box or the bootstrap node to MAAS to be proxyed
[14:30] <melmoth> hmmm
[14:30] <melmoth> may be i should set no-proxy for the maas box ?
[14:30] <mgz> well, you are telling the bootstrap node to use a proxy with that
[14:30] <mgz> affecting the local client when uploading a charm is a little odd
[14:31] <mgz> melmoth: you probably should
[14:31] <melmoth> i m just not sure what name to use or wich actual machine it s trying to cennect to
[14:32] <melmoth> let s try with 192.168.101.2
[14:34] <melmoth> \o/
[14:34] <melmoth> thanks mgz :-)
[14:34] <mgz> workies?
[14:35] <melmoth> looks like it did. At least i have a prompt. it s a subordinate so nothing happened, that s normal. let s continue deployment
[14:37] <melmoth> yeah, mysql seems to be under deployment
[14:40] <mgz> ace.
[16:06] <cory_fu> So, I'm new to bzr.  If I want to submit a (set of) change(s) for review on charm-helpers, do I just do bzr push lp:~johnsca/charm-helpers/name-for-branch in my local copy?
[16:08] <timrc> arosales, Hey I pushed a fix for: https://bugs.launchpad.net/charms/+source/jenkins/+bug/1272520 -- but it's pushed to a +junk branch so I can submit an MP
[16:08] <_mup_> Bug #1272520: Unable to relate to jenkins-slave: hook failed: "master-relation-changed" <audit> <jenkins (Juju Charms Collection):Confirmed for lazypower> <https://launchpad.net/bugs/1272520>
[16:09]  * timrc really doesn't want any responsibilities associated with being a member of ~charmers, but this particular bug has bit us, and thought I would kill it with fire
[16:09] <marcoceppi> cory_fu: yes, then do a bzr lp-propose lp:charm-helpers
[16:09] <lazyPower> timrc: right on. I'll take a look closer to EOB unless you need it landed immediately.
[16:09] <lazyPower> and follow marco's directive ^
[16:09] <timrc> lazyPower, Nah, take your time.  Not hugely critical.  We are deploying from a branch atm... there is some weirdness around authentication too but I think that's separate
[16:10] <timrc> lazyPower, Right-o.  Thanks
[16:10] <arosales> timrc: thanks for the mp. I think I had filled a abug against jenkins . . .
[16:11] <arosales> timrc: https://bugs.launchpad.net/charms/+source/jenkins/+bug/1272520 was the bug I was hitting did you see something similiar?
[16:11] <_mup_> Bug #1272520: Unable to relate to jenkins-slave: hook failed: "master-relation-changed" <audit> <jenkins (Juju Charms Collection):Confirmed for lazypower> <https://launchpad.net/bugs/1272520>
[16:12] <timrc> arosales, Well I didn't see any logs, so I can't be 100% sure but my master-relation-changed problem was due to the fact that the master-relation-changed hook was expecting the slave-relation-joined hook (run by jenkins-slave) to set 'slaveaddress' which it wasn't
[16:12] <timrc> arosales, so master-relation-changed was assigning an empty string and passing that to hooks/addnode and causing breakage
[16:13] <arosales> timrc: sounds promissing that your branch may resolve this issue
[16:14] <arosales> timrc: thanks for taking the time to contribute the fix back into the juju community :-)
[16:43] <timrc> marcoceppi, Just to confirm my lp-propose should be:
[16:43] <timrc> Source: lp:~timrchavez/charm-helpers/jenkins-slave-fix-slave-relation-joined
[16:43] <timrc> Target: lp:charm-helpers
[16:44] <timrc> should result in* rather
[16:44] <marcoceppi> timrc: is this a fix in charm-helpers or the jenkins charm?
[16:45] <timrc> marcoceppi, it's a fix to a jenkins charm... when I attempted to propose my branch for merge against the actual charm I got a little hate :(
[16:45] <timrc> bzr: ERROR: exceptions.Exception: lp:~timrchavez/charm-helpers/jenkins-slave-fix-slave-relation-joined is not mergeable into lp:charms/jenkins-slave
[16:46] <marcoceppi> timrc: you should push your branch to lp:~timrchavez/charms/precise/jenkins/jenkins-slace-fix-slave-relation-joined
[16:46] <marcoceppi> timrc: you're trying to merge not only across projects, but across distros
[16:46] <timrc> marcoceppi, muhaha
[16:47] <timrc> if I could push to charms/ I would have..
[16:47] <marcoceppi> timrc: you can
[16:47] <marcoceppi> timrc: it's charms in your namespace
[16:47] <marcoceppi> anyone can push to lp:~user/charms/...
[16:47] <timrc> marcoceppi, Ah, I had some problem... maybe my path was bad
[16:48] <timrc> marcoceppi, Ah, I attempted bzr push lp:~timrchavez/charms/precise/jenkins-slave-fix-slave-relation
[16:48] <marcoceppi> timrc: yeah, since charms is a distro, you have to put a branch name in there and jenkins becomes the project name
[16:50] <timrc> Makes sense.  Thanks for working around my obtuseness and helping me :)
[16:50] <marcoceppi> timrc: np! once it's all pushed, you can just do `bzr lp-propose lp:charms/jenkins-slave`
[17:03] <timrc> lazyPower, Okay stumbled my way through :) https://code.launchpad.net/~timrchavez/charms/precise/jenkins-slave/jenkins-slave-fix-slave-relation-joined/+merge/214994
[18:24] <tvansteenburgh> anyone ever successfully configured sticky sessions on the haproxy charm?
[18:32] <marcoceppi> tvansteenburgh: people in IS probably have
[18:34] <tvansteenburgh> marcoceppi: thanks, will check there
[19:03] <Jeffrey_> Is there anyway to start a service on the juju agent machine? Or is there a way to deploy to a specific machine number in juju status?
[19:06] <marcoceppi> Jeffrey_: yes, you can use deploy --to
[19:07] <Jeffrey_> marcocappi: Then I get "Added charm "local:percise/rethinkdb-2" to the environment. ERROR cannot assign unit "rethinkdb/0" to machine 0: series does not match" and the machine type of number 0 is "series: percise"
[19:08] <marcoceppi> Jeffrey_: is this a local provoder?
[19:08] <Jeffrey_> Yes from a directory on the juju client computer.
[19:11] <Jeffrey_> Also if I add a charm it creates a new machine that stays in the pending state. How can I start it?
[19:11] <marcoceppi> Jeffrey_: the bootstrap node isn't a real cloud VM, it's your actual machine
[19:11] <marcoceppi> you'll need to add another machine
[19:11] <Jeffrey_> marcoceppi: Ok so the bootstrap node can only be for the agent?
[19:11] <marcoceppi> Jeffrey_: only on local provider
[19:12] <marcoceppi> Jeffrey_: all other real clouds you can deploy --to 0
[19:12] <Jeffrey_> marcoceppi: I'm sorry I meant I am running a MaaS provider.
[19:12] <Jeffrey_> I am running from a local repository
[19:13] <Jeffrey_> Charm is from a local repository
[19:13] <marcoceppi> Jeffrey_: show me your juju status
[19:14] <Jeffrey_> marcoceppi:
[19:14] <Jeffrey_> http://pastebin.ubuntu.com/7227684/
[19:17] <Jeffrey_> marcoceppi: Even when I just do a normal deploy the new machine that is allocated for the charm doesn't start. Is there any way for force it?
[19:18] <marcoceppi> Jeffrey_: something else is wrong, it should start up eventually
[19:19] <Jeffrey_> marcoceppi: This is the status: http://pastebin.ubuntu.com/7227701/
[19:22] <Jeffrey_> macroceppi: I think I figured it out.
[21:06] <avoine> I'm thinking about changing some configuration variables for the django charm like: requirements_pip_files
[21:06] <avoine> in your opinion what would be better:?
[21:06] <avoine> 1) having a configuration option with a default but ignoring if the results fail
[21:06] <avoine> 2) a configuration variable with empty default and triggering errors if the file is not there
[21:12] <marcoceppi> avoine: the latter, in my opinion
[21:23] <tvansteenburgh> `juju deploy local:trusty/haproxy --repository=.`
[21:23] <tvansteenburgh> is the --repository=. needed there?
[21:24] <tvansteenburgh> i'm hacking on haproxy and my code changes aren't getting deployed to new units
[21:24] <tvansteenburgh> not using --repository and wondering if i need to
[21:25] <tvansteenburgh> marcoceppi: ^
[21:25] <marcoceppi> tvansteenburgh: pretty sure you always need to specify a repository
[21:25] <tvansteenburgh> or else?
[21:26] <tvansteenburgh> maybe it's pulling from lp everytime and i haven't noticed
[21:26] <marcoceppi> no, it wont do that
[21:27] <tvansteenburgh> yeah i dunno what it's doing then
[21:36] <marcoceppi> tvansteenburgh: you can try with the --debug flag
[21:36] <marcoceppi> see what's happening
[21:36] <tvansteenburgh> well --repository=. fixed my immediate prob, so i'm moving on
[22:25] <arosales> mbruzek: marcoceppi does charm-help-test work for you?
[22:25] <arosales> on charm-tools 1.2.10 its not giving me the help
[22:26] <arosales> sorry I meant to state, charm-help test
[22:26] <arosales> charm help test, also isn't working for me.
[22:27] <mbruzek> no I get a usage when I try those commands
[22:27] <arosales> http://paste.ubuntu.com/7228396/
[22:27] <arosales> I'll file a bug
[22:28] <arosales> mbruzek: thanks for confirming I was hoping to look at what the valid outputs are for charm tests
[22:28] <mbruzek> arosales, does "charm test" not work for you?  It appears that the help is broken for me
[22:29] <arosales> mbruzek: 'charm test' does work for me
[22:29] <arosales> mbruzek: just that 'charm help test' does not or as the usage suggests 'charm-help test'  also doesn't work
[22:29] <mbruzek> sure
[22:29] <mbruzek> That is a bug
[22:32] <marcoceppi> avoine: charm test -h
[22:32] <marcoceppi> should give you output
[22:32] <arosales> https://bugs.launchpad.net/charm-tools/+bug/1305337
[22:32] <_mup_> Bug #1305337: charm help test does not work on 1.2.10 <Juju Charm Tools:New> <https://launchpad.net/bugs/1305337>
[22:32] <arosales> marcoceppi that does work
[22:33] <arosales> perhaps it just the usage that needs updating then
[22:33] <marcoceppi> arosales: charm help <cmd> doesn't ever work?
[22:33] <marcoceppi> i guess it could
[22:33] <arosales> it didn't work for me in the commands I tried it with, list, test, get, etc.
[22:35] <arosales> cory_fu: fyi http://paste.ubuntu.com/7228419/
[22:35] <arosales> which I finally got to give me from charm test -h
[22:35] <arosales> cory_fu: pass, fail, skip, and timout, so were hitting timeout