[01:45] <tvansteenburgh> stub: do you have an example of the config needed to deploy the postgresql charm using 9.4? my latest attempt was this http://paste.ubuntu.com/16121963/
[01:45] <tvansteenburgh> stub: ala `juju deploy postgresql --config /tmp/pg.yaml`
[02:11] <tvansteenburgh> stub: i had a typo in that. removed the leading "deb" from the install_sources. problem now is that when apt-get update tries to download the postgres index files, they 404
[02:12] <tvansteenburgh> stub: not the charm's fault obviously, i'm just not sure how to fix.
[02:14] <tvansteenburgh> stub: i don't know how apt-get update creates its urls. i gave it "http://apt.postgresql.org/pub/repos/apt/ trusty-pgdg main" and it's trying to fetch "http://apt.postgresql.org/pub/repos/apt/dists/trusty/trusty-pgdg/binary-amd64/Packages" and "http://apt.postgresql.org/pub/repos/apt/dists/trusty/main/binary-amd64/Packages", neither of which exist
[02:36] <tvansteenburgh> stub: uh, nevermind. i just destroyed the model and redeployed everything and now it's working...
[02:36]  * tvansteenburgh blinks
[03:09] <stub> tvansteenburgh: If you use the most recent charm (or review it and stuff it in the charm store) you don't need the updated key, and can just set the pgdg boolean config option.
[03:10] <stub> tvansteenburgh: launchpad.net/postgresql-charm
[03:11] <tvansteenburgh> stub: ah, cool, didn't know there was a newer charm
[03:11] <stub> tvansteenburgh: Yeah, complete rewrite in reactive, lots of bugs fixed.
[03:11] <stub> tvansteenburgh: Its what we use for production deploys
[03:12] <tvansteenburgh> sweet
[03:12] <stub> https://code.launchpad.net/postgresql-charm has the branches - you want 'built'.
[03:12] <tvansteenburgh> stub: is it in the store under your namespace or something?
[03:13] <stub> tvansteenburgh: tribaal uploaded a copy to his namespace the other day. I can't log in myself (open bug on charmstore-client)
[03:14] <tvansteenburgh> stub: ack, i'll take it for a spin
[05:02] <veebers> Hi all, so trying to install juju from scratch as per https://github.com/juju/juju/blob/master/README.md (i.e. go get -d -v github.com/juju/juju/...) but fails on github.com/Azure/azure-sdk-for-go. A quick look at the build status for that project shows it's been failed for 17 days. Is this a known issue
[05:09] <stub> Is there a blessed way of knowing what sort of a hook environment is in play? I think JUJU_HOOK_NAME now gets reliably set in hooks, but I'm not sure since what version. I also can't see anyway of determining if I'm running an action or in a juju-run context, apart from sniffing the process command line (which is error prone due to symlinks, but I could cope I think)
[05:11] <stub> I guess I could rely on action-get to fail hard if I'm not in an action, which will cause log spam but should be reliable.
[05:14] <admcleod-> id ilke to iterate through each unit in a service, in an amulet test, but not sure what the best way is
[05:14] <admcleod-> (and action_do(unit))
[05:24] <veebers> so instructions found here fixed my issue: https://github.com/juju/juju/blob/master/CONTRIBUTING.md#dependency-management (godeps etc.)
[05:30] <stub> admcleod-: for unit_data in deployment.sentry['servicename']
[05:33] <stub> unit_names = [i.info['unit_name'] for i in deployment.sentry['myservice']] if you just want the unit names for action_do(unit_name)
[05:33] <admcleod-> ah ok cool, i was close
[05:34] <admcleod-> but that saved me a bit of work i think :}
[10:36] <Mo0O> hello
[10:37] <Mo0O> do you know if it's possible to use juju to deploy with any given linux distro, like alpine linux for example
[10:37] <Mo0O> ?
[10:38] <Mo0O> or we can use it only with ubuntu and centos
[10:40] <magicaltrout> hey Mo0O, currently I think thats it
[10:40] <magicaltrout> the tools need to be compatible with the different linux flavours
[10:40] <magicaltrout> so its not like its impossible it just depends on where the tooling has been developed
[10:41] <Mo0O> magicaltrout: do you know which part of the source juju source code needs to be modified to support other distro?
[10:42] <Mo0O> I can contribute
[10:42] <magicaltrout> i don't but i'm sure marcoceppi can point you in the right direction when he arrives
[10:42] <magicaltrout> you'll probably have to wait an hour for the east coasters to wake up
[10:43] <Mo0O> no problem, I'm connected constantly
[10:43] <Mo0O> ;)
[12:22] <DavidRama> hello trying to get started with juju ans maas but can't bootstrap my environment here's my configenvironments:
[12:22] <DavidRama>     # https://juju.ubuntu.com/docs/config-maas.html
[12:22] <DavidRama>     maas:
[12:22] <DavidRama>         type: maas
[12:22] <DavidRama>         maas-server: 'http://172.17.6.253/MAAS/'
[12:22] <DavidRama>         maas-oauth: 'XMepSnQvpPeNgDFEMH:D22wnKekvCg3mgWpAm:kRctQA9wXSW38VxRw7uqNhkNpsQxYpF8'
[12:22] <DavidRama>         bootstrap-timeout: 1800
[12:22] <DavidRama>         authorized-keys-path: /home/rama/.juju/ssh/rama.pub
[12:22] <DavidRama> bootstraping leads to this
[12:22] <DavidRama> rama@Maas:~$ juju-1.25 bootstrap
[12:22] <DavidRama> WARNING ignoring environments.yaml: using bootstrap config in file "/home/rama/.juju/environments/maas.jenv"
[12:22] <DavidRama> ERROR cannot determine if environment is already bootstrapped.: could not access file 'eec82963-60e7-480e-8ff3-888844ddab96-provider-state': Requested map, got <nil>.
[12:23] <DavidRama> don't know where to find this provider-state file/erase it
[12:23] <marcoceppi> DavidRama: delete the .jenv file it references, bootstrap again
[12:24] <DavidRama> other provider state message:
[12:24] <DavidRama> Bootstrap failed, destroying environment
[12:24] <DavidRama> ERROR the environment could not be destroyed: destroying instances: Requested array, got <nil>.
[12:24] <DavidRama> ERROR cannot determine if environment is already bootstrapped.: could not access file '68370e49-7eaa-4fdb-88b6-924856105d3a-provider-state': Requested map, got <nil>.
[13:18] <shruthima> Hi kwmonroe, I have pushed the IBM-IM charm, but we are unable to see in review queue and even in charm store...  can u please let us know if anything we need to do...!!!
[13:21] <magicaltrout> shruthima: the review queue spends more time broken than not, ask marcoceppi if its working or not ;)
[13:21] <magicaltrout> also the launchpad ingestion is broken afaik, so if you're not using the new charm publish commands you won't see it land in jujucharms.com either
[13:23] <shruthima> oh k thanks <magicaltrout>
[13:32] <lazyPower> cory_fu - thanks for landing those charms. I've revv'd our namespace revisions and i'm wrapping up testing the bundle
[13:41] <jcastro> lazyPower: ok firing up your cluster again, you still at rev 0?
[13:41] <lazyPower> Yep trying to land beats-core atm
[13:42] <lazyPower> all teh charms are revv'd, just need to land the bundle and get these prom'd and we're up and running w/ the new logging stack
[13:42] <jcastro> oh ok so I should wait a bit then
[13:42] <lazyPower> yeah give me a bit to have someone drive this to landing and i'll have another bundle for you
[13:42] <jcastro> shruthima: have you seen the new publishing documentation to publish to the store directly?
[13:43] <shruthima> yes i have seen will try to push in new way
[13:44] <jcastro> we have tim working full time on the new review queue so we should have something working soon, sorry for the inconvenience
[13:45] <tvansteenburgh> woo woo
[13:47] <shruthima> np , thanks for the information jcastro
[13:56] <shruthima> Hi Cory, With ibm-base layer we have one issue. In layer.yaml we have seen a comment  #Setting options for the basic layer(http://bazaar.launchpad.net/~ibmcharmers/layer-ibm-base/trunk/view/head:/layer.yaml)  due to these when layer options are called charm deployment is getting failed. so we have tested with removing comment and it is working fine. can you suggest on same ..???
[14:59] <jcastro> lazyPower: status?
[14:59] <lazyPower> jcastro on?
[14:59] <jcastro> you were revving the bundle no?
[15:00] <lazyPower> i'm deploying beats bundle tests
[15:00] <lazyPower> trying to land the new logging stack. kwmonroe is reviewing the beats promulgation, mbruzek is reviewing my kibana mp
[15:01] <lazyPower> I'm about 20 minutes out from having finished this bundletester run on the beats-core bundle... which is running tests on stuff in precise: series (?!)
[15:01] <lazyPower> i'll have new swarm revs for you closer to EOD
[15:02] <lazyPower> storage incoming shortly after lunch/standup
[15:02] <jcastro> ack
[15:02] <lazyPower> jcastro - i think we'll have a beats k8s bundle for you shortly
[15:02] <jcastro> no worries
[15:02] <lazyPower> "observeable kubernetes"
[15:03] <jcastro> hey so ~charmers
[15:03] <jcastro> nm, I'll ask on the list
[15:13] <DavidRama> hi how can I fix this ?? ERROR MAAS 2 is not supported unless the 'maas2' feature flag is set
[15:48] <tvansteenburgh> jamespage: do you have a charm that uses the experimental rabbitmq interface?
[15:48] <jamespage> tvansteenburgh, yah
[15:48] <jamespage> tvansteenburgh, one sec
[15:49] <jamespage> tvansteenburgh, https://code.launchpad.net/~openstack-charmers/charms/+source/charm-aodh/+git/charm-aodh
[15:50] <tvansteenburgh> jamespage: ta!
[15:50] <jamespage> tvansteenburgh, specifically https://git.launchpad.net/~openstack-charmers/charms/+source/charm-aodh/tree/charm/reactive/aodh_handlers.py
[15:50] <tvansteenburgh> jamespage: yah, perfect, thanks
[15:51] <jamespage> tvansteenburgh, thedac, tinwood and gnuoy are working on unit tests across our interfaces as well
[15:51] <tvansteenburgh> jamespage: you might consider linking to this example from a readme in the rabbitmq interface repo
[15:51] <jamespage> tvansteenburgh, docs etc.. on the list...
[15:52] <tvansteenburgh> roger
[16:16] <marcoceppi> lazyPower: https://github.com/juju/charm-tools/pull/197
[16:25] <TheMue> :q!
[16:25] <TheMue> Ooops :)
[16:44] <tvansteenburgh> cory_fu: @when('foo', 'bar') is the same as @when('foo')\n@when('bar') right?
[16:45] <cory_fu> Yes
[17:01] <lazyPower> jcastro  if you have a minute, this could use your wordsmithing https://github.com/juju-solutions/bundle-observable-swarm
[17:21] <jcastro> lazyPower: on it.
[17:22] <jcastro> lazyPower: from now on when you need a bundle README'ed, open an issue on it and assign it to me
[17:22] <jcastro> and then I'll just do them all
[17:24] <magicaltrout> aww everyone needs someone like jcastro working with them....
[17:26] <jcastro> magicaltrout: I will also document your incredible soon-to-be-finished gitlab. :p
[17:26] <magicaltrout> hehe
[17:26] <magicaltrout> well
[17:27] <magicaltrout> i'm waiting on what marcoceppi called a "much larger Pull Request"
[17:27] <magicaltrout> that never appeared ;)
[17:27] <marcoceppi> magicaltrout: it's still in flight, I've been talking to jcastro a lot about it
[17:28] <magicaltrout> aye everyones been a bit busy, you guys with 2.0 and me with 2 jobs and ApacheCon. I should have some spare time post apachecon to finish a bunch of my charms off
[17:29] <jcastro> I hope there are videos from apachecon
[17:30] <magicaltrout> I don't
[17:30] <magicaltrout> the main rooms get videoed, the others get recorded and slides and stuff posted
[17:30] <magicaltrout> (audio)
[17:31] <magicaltrout> or thats how it went the last 3 years, I doubt it will change
[17:32] <kwmonroe> note tvansteenburgh, @when(foo, bar); def doinit(foo, bar)....  @when(foo)\n@when(bar); def doinit(bar, foo).
[17:33] <tvansteenburgh> kwmonroe: yah
[18:42] <jamespage> marcoceppi, hey - can you help dig us out of a gate break?
[18:43] <jamespage> marcoceppi, paramiko just released a 2.0.0 which introduces a dep on cryptography, which in a trusty virtualenv explosed with setuptools version mismatches
[18:43] <jamespage> marcoceppi, could you upper bound the paramiko dep in charm-tools to <2.0.0 ?
[18:43] <jamespage> that would help hugely for now
[18:43] <jcastro> lazyPower: out of curiosity why are you doing kibana on precise? Keeping the old version on purpose I take it?
[18:44] <lazyPower> jcastro - if you're referring to the tests, that was inhereted.
[18:45] <lazyPower> oooo wait i see it now
[18:45] <lazyPower> and no that was a mistake
[18:45] <jcastro> ok, heh
[18:46] <jamespage> marcoceppi, ignore me apparently I'm beeing stoooppid today.,..
[18:46] <jcastro> lazyPower: it's not obvious from the bundle format, but where do the filebeat and topbeat services live?
[18:46] <jcastro> on each node?
[18:46] <lazyPower> correct. they are subordinate units
[18:47] <lazyPower> jcastro https://github.com/juju-solutions/bundle-observable-swarm/pull/1 ta for pointing that out
[18:47] <jcastro> how can I determine where subordinates live in the bundle format?
[18:47] <LiftedKilt> having trouble with the openstack-lxd bundle - can't save any images to glance
[18:48] <lazyPower> by relating them over the "beats-host" relation
[18:48] <LiftedKilt> any pointers on where to look? juju things everything is peachy
[18:48] <lazyPower> jcastro other than that i'm not aware of any obvious hints
[18:48] <LiftedKilt> ceph reports all the pgs being stuck inactive
[18:50] <jcastro> lazyPower: ok, also, beats supercedes logstash right?
[18:50] <lazyPower> Beats work with logstash
[18:51] <lazyPower> logstash for the most part wont be required unless you need ot stream to multiple data-sorces, or do even more transformations on the data before ingest
[18:51] <lazyPower> pardon typos
[18:51] <jcastro> oh I see in their docs, it replaces logstash-forwarder
[18:51] <lazyPower> correct. beats are the new shipping agent for all sorts of data
[18:51] <lazyPower> the traditional ELK stack has been turned on its head
[18:51] <bsod90> Hey everyone! I'm getting this error http://d.pr/i/jPVn when trying to open openstack-lxd bundle from ui (juju2). Other bundles seem to open fine. What would that mean?
[18:53] <tvansteenburgh> stub: don't suppose you're around?
[19:00] <jcastro> lazyPower: PR incoming
[19:00] <lazyPower> jcastro ta
[19:07] <jamespage> marcoceppi, tvansteenburgh, lazyPower: https://github.com/juju/charm-tools/pull/199
[19:07] <jamespage> we need digging out of a hole pls :-)
[19:08] <marcoceppi> jamespage: lgtm, where do you pull charm-tools from in ci?
[19:08] <jamespage> marcoceppi, pypi
[19:09] <jamespage> via tox/venv
[19:10] <marcoceppi> jamespage: you can also fix this by just installing libssl-dev and libffi-dev in your testing env
[19:10] <jamespage> marcoceppi, we need to review our dependency management to ensure we upper bound, but I did not want todo that during a gate break
[19:10] <jamespage> marcoceppi, that's not actually the problem - once you install those, cryptography wants >=11.2 of setuptools
[19:10] <jamespage> trusty virtualenv installs 2.2
[19:10] <marcoceppi> jamespage: ah, that fixed it on xenial
[19:10] <marcoceppi> jamespage: tbh, I'm not even sure why paramiko is in there
[19:11] <marcoceppi> I think I added it becaues it was needed by launchpadlib
[19:11] <marcoceppi> jamespage: this is going to be a bit awkward for a release, but I will get on this right away
[19:14] <jamespage> marcoceppi, thankyou very much appreciated...
[19:17] <marcoceppi> jamespage: I'm not sure how, but your branch has merge conflicts
[19:18] <marcoceppi> jamespage: don't worry about it, I know it's getting late over there, I'll sort them out and cut the release tonight
[20:00] <bsod90> How can I debug networking for container created by juju? I see from logs that internet if unreachable from 3/lxc/1 for some reason. I can ssh to machine 3, but how can I see how the things look like from inside lxc/1 ?
[20:04] <tvansteenburgh> bsod: lxc exec <container name> --mode=interactive /bin/bash
[20:04] <tvansteenburgh> bsod90: ^
[20:05] <bsod90> tvansteenburgh: thank you!
[20:05] <tvansteenburgh> so ssh to machine 3, run `lxc list` to get container name
[20:05] <tvansteenburgh> np
[20:10] <marcoceppi> tvansteenburgh: what the heck
[20:10] <marcoceppi> tvansteenburgh: `lxc exec <container> bash` is all you need
[20:10] <tvansteenburgh> i went above and beyond
[20:10] <magicaltrout> hehe
[20:10] <marcoceppi> bsod90: also, you probably have lxc1.0 if so, `sudo lxc-ls --fancy` and then ssh ubuntu@<ip-container>
[20:11] <bsod90> it actually turned out to be "sudo lxc-attach juju-machine-3-lxc-1"
[20:11] <bsod90> :)
[20:11]  * tvansteenburgh shrinks into the corner
[20:11] <LiftedKilt> in lxc1 you can lxc-attach --name container
[20:11] <magicaltrout> direct amulet questions at tvansteenburgh he loves them ;)
[20:12] <tvansteenburgh> ha
[20:12] <tvansteenburgh> i got so many it drove me to write docs, of all things
[20:12] <magicaltrout> hehe
[20:12] <magicaltrout> it you could make it psychic that would be better
[20:13] <bsod90> "subprocess.CalledProcessError: Command '['unit-get', '--format=json', 'private-address']' returned non-zero exit status 1
[20:13] <magicaltrout> actually that would be cool, a bit like the Selenium test builders for FF and stuff
[20:13] <bsod90> oops
[20:14] <magicaltrout> create a test harness that just lets you replay juju commands though it with minor tweakage for assetions
[20:14] <magicaltrout> +r
[20:14] <tvansteenburgh> magicaltrout: cool idea, let me know when you have it ready!
[20:14] <magicaltrout> lol
[20:14] <magicaltrout> remind me in a few months when the rest of my life is in order and I'll consider it ;)
[20:15] <tvansteenburgh> i hear ya
[20:31] <bsod90> what would 'private address not found' error comming from unit-get mean?
[21:27] <cory_fu> Is there any way to set list values for action results?
[21:33] <barry> cherylj: hi :)
[21:33] <cherylj> hi barry :)
[21:33] <barry> cherylj: oh, i'm having so much trouble :)
[21:33] <cherylj> I'm sorry to hear that :(
[21:34] <barry> cherylj: if it helps make juju + charms better, it's okay!  if i'm just being dumb, maybe that's okay too :)
[21:35] <cherylj> barry: did you try juju resolved?
[21:35] <barry> i did, and it returned without any output
[21:36] <cherylj> that's expected.  It will retry the failing hook on the unit
[21:36] <cherylj> so you'll need to look at the status again
[21:36] <barry> oh wow... juju status is very unhappy:
[21:36] <cherylj> oh no
[21:36] <barry> % juju status
[21:36] <barry> WARNING discarding API open error: connecting with cached addresses: unknown model: "8d79af51-015a-4283-8d87-8ab0bf1f68a3" (not found)
[21:36] <barry> ERROR connecting with bootstrap config: unknown model: "8d79af51-015a-4283-8d87-8ab0bf1f68a3" (not found)
[21:36] <barry>  
[21:37] <cherylj> barry: did you happen to remove a model and add a new one of the same name?
[21:37] <cherylj> (see bug 1576359)
[21:37] <mup> Bug #1576359: Cannot talk to a new model with a reused name <juju-release-support> <switch> <juju-core:Triaged> <https://launchpad.net/bugs/1576359>
[21:37] <barry> cherylj: pretty sure i didn't try to add a new one.  in my flailing about i did try to destroy the model
[21:38] <cherylj> oh you might still be in there as your current model
[21:38] <cherylj> 'juju switch' will show you what model you're working in
[21:39] <barry> ah yes, i'm still using local.mailman3-test:default
[21:39] <barry> (admin is the only model shown by juju list-models)
[21:39] <cherylj> ah, yeah that would do it
[21:39] <cherylj> if it doesn't exist anymore
[21:39] <barry> okay, gotcha
[21:39] <cherylj> so did you destroy the model that was having the unit failures?
[21:39] <barry> cherylj: i did
[21:40] <cherylj> used the big hammer :)
[21:40] <cherylj> heh heh
[21:40] <barry> yeah, nothing else seemed to be working.  maybe i was impatient, but i did wait 5 minutes or so
[21:40] <barry> cherylj: btw, am i helping by reporting bugs on the github projects, or should i use launchpad?
[21:40] <cherylj> barry: I was just about to tell you that you should be using lp
[21:40] <cherylj> :)
[21:40] <cherylj> mind reader
[21:41] <cherylj> the juju mailing list is also a good way to get help
[21:41] <cherylj> if you're not sure how to do something
[21:41] <barry> yeah, i should probably join the mailing list.  i just dread the inbox filling ;)
[21:42] <cherylj> it's actually not so bad
[21:42] <cherylj> and I'm all ALL the juju lists :)
[21:42] <barry> :)
[21:42] <barry> i wonder if it's on gmane...
[21:42] <cherylj> https://lists.ubuntu.com/mailman/listinfo/juju
[21:43] <barry> \o/
[21:44] <cherylj> barry: you can ping me if you run into the issue again.  Hopefully we can figure it out :)
[21:44] <barry> awesome, thanks!
[22:50] <bsod90> does juju deal with dhcp somehow? I'm trying to understand how container interfaces are getting their IPs.. I thought they supposed to get IPs from whatever DHCP is running in bridged network, but I just observed the situation where one container got a gateway IP, which means it certainly did not get it from DHCP. At least not from one it supposed to get it from..