[00:31] <cmars> edsiper, sorry, was changing locations there.. is "out_mongodb" the name of your endpoint in your layer's metadata.yaml, under requires:
[00:31] <cmars> ?
[00:32] <cmars> edsiper, for example, if I had this in my layer's metadata.yaml, https://paste.ubuntu.com/15491929/, the state name would be "database.database.available"
[00:39] <stormmore> damn it something is wrong in my maas config :-/
[01:10] <stub> kwmonroe: I recommend using the leadership settings to distribute the masterhost:port rather than the peer relation, although the peer relation will work too.
[01:12] <stub> kwmonroe: With the peer relation, after leadership failover you could end up with two units advertising masterhost:port on the peer relation (eg. when the lead unit has been powered off but the unit not removed - it still exists on the peer relation)
[01:12] <stub> kwmonroe: With leadership settings, there is a single source of truth
[01:43] <kwmonroe> thx stub!  that's good info.
[02:20] <stormmore> almost got it bootstrapped, getting stuck downloading the tools :-/
[02:39] <stormmore> am I missing something or is curl -sSfw 'tools from %{url_effective} downloaded: HTTP %{http_code}; time %{time_total}s; size %{size_download} bytes; speed %{speed_download} bytes/s ' --retry 10 -o $bin/tools.tar.gz <[https://streams.canonical.com/juju/tools/agent/2.0-beta2/juju-2.0-beta2-trusty-amd64.tgz]> not a valid curl command?
[02:45] <edsiper> cmars, yes, it's out_mongodb
[02:54] <stormmore> hmmm gotten hung up twice at that point :-/
[03:05] <cmars> edsiper, back from dinner. what does the function that you're decorating with that @when look like? does it take just one argument?
[03:06] <cmars> it probably does.. in which case, i'm running out of ideas.. other than maybe checking that the latest built charm is actually what you've got deployed and are relating to
[03:22] <edsiper> cmars, yeah, one argument and basically doing a log()
[03:22] <cmars> hmm
[03:26] <edsiper> cmars, http://pastebin.com/H1eUhge7
[03:29] <cmars> edsiper, can you paste me your layer.yaml as well?
[03:29] <stormmore> ok this is messed up, how can apt-get update work but juju deploy --to 0 juju-gui cant
[03:36] <edsiper> cmars, ooops, no layer.yaml
[03:37] <cmars> edsiper, aha
[03:37] <edsiper> cmars, I will dig into it tomorrow :D , thanks for pointing the main problem
[03:37] <cmars> edsiper, add the interface, charm build, and you'll probably see that get called
[03:37] <edsiper> g'night...
[03:37] <cmars> edsiper, night
[03:37] <edsiper> yeah
[03:50] <stormmore> got love running into an ipv6 vs ipv4 confusion
[03:54] <stormmore> some days I just wonder how I go to where I am when I miss the basics
[04:17] <stormmore> oh I do like the default juju status for 2 :)
[05:55] <stormmore> OK so I just did juju deploy juju-gui and juju expose juju-gui, juju status shows that it has the right public address and yet I keep getting connection timed out errors
[09:57] <deanman> Hi, i would like to write a docker charm utilising the layer-docker charm but it is not clear to me what's the best way to do this. Do i simply clone layer-docker or can i use something from charm-tools to pass this as an argument?
[11:29] <stub> deanman: You declare the docker layer in your layer.yaml. You probably want to go over https://jujucharms.com/docs/devel/developer-getting-started and https://jujucharms.com/docs/devel/developer-layer-example (the devel branch of the docs now documents layers and how to use them)
[11:30] <deanman> stub: thank you!
[13:18] <narindergupta1> hi I am getting this issue while deploying the latest ceph charm https://bugs.launchpad.net/opnfv/+bug/1561984
[13:18] <mup> Bug #1561984: ceph-osd charm failed to deploy  <OPNFV:New> <https://launchpad.net/bugs/1561984>
[13:20] <narindergupta1> can someone help me finding the solution. it seems latest changes in ceph-osd charm http://bazaar.launchpad.net/~openstack-charmers/charms/trusty/ceph-osd/next/revision/76 is causing this issue?
[13:53] <jcastro> marcoceppi: did you forget to push your fixes to fiche? Still shows up busted for me on jujucharms.com
[13:53] <jcastro> well not busted, just with the extra stuff
[14:03] <marcoceppi> jcastro: it's pushed.
[14:03] <marcoceppi> store ingestion, probably
[14:04] <marcoceppi> jcastro: http://bazaar.launchpad.net/~charmers/charms/trusty/fiche/trunk/revision/2
[14:13] <jcastro> jrwren: which one of you guys handles ingestion?
[14:37] <jrwren> jcastro: kind of all of us?
[14:37] <jcastro> can you check fiche?
[14:49] <jrwren> jcastro: looks like its been pushed to before, so ingestion is disabled for that charm.
[14:58] <jcastro> jrwren: what does that mean?
[14:58] <jcastro> why would ingestion be disabled?
[15:00] <jrwren> jcastro: because someone uploaded it using charm push?
[15:00] <jcastro> oh, so how do we fix it to make it ingestible?
[15:02] <jcastro> jrwren: do we need to rerun a publish or something?
[15:03] <jrwren> jcastro: You cannot. Once a charm has been published using the new charm push command, that is how it is now managed. This fits with ingestion going away.
[15:04] <jcastro> ok so how do we fix it so that charm is ingested?
[15:04] <jcastro> tldr, how do we make the jujucharms.com page reflect what's actually in the vcs branch?
[15:05] <jrwren> jcastro: AFAIK we have no means to do that. You can fix the charm in the store by pushing the new version using the charm push command.
[15:05] <jcastro> marcoceppi: is that what you tried?
[15:10] <jrwren> jcastro: what is wrong with it?  https://jujucharms.com/fiche/ is fiche-3 and doesn't show the extra files that were removed in bzr rev-2
[15:11] <jcastro> huh
[15:11] <jcastro> that directory was there an hour ago
[15:11] <jcastro> but marco pushed that on 21 march, maybe I had a stale cache?
[15:12] <jcastro> jrwren: ok I guess I'm all set lol, thanks.
[15:12] <jrwren> jcastro: Sorry for the confusion.
[15:13] <jcastro> jrwren: actually, I just realized how I did that
[15:13] <jcastro> google for "fiche jujucharms"
[15:13] <jcastro> the result sends me _specifically_ to revision 2 instead of trunk
[15:16] <jrwren> msust be your tuned google. oh... 5th result for me.
[15:16] <jrwren> I rarely look down to 5th ;]
[15:17] <jcastro> is it rev 2 or 3?
[15:17] <jcastro> there's a bug on this already, we need to present google with the right bits
[15:17] <jcastro> I just should have been paying attention to the rev #
[15:17] <jrwren> latest is 3.
[15:18] <jcastro> yeah google shows me 2
[15:18] <jrwren> I'd grumble about the link that says revisions: 1 on that page, but I'm told that UI is by design, so I'm not going to grumble about it and instead suggest you not be mislead by it.
[16:01] <LiftedKilt> are there any known issues with bootstrapping Xenial on juju2/maas 1.9?
[16:02] <LiftedKilt> Maas can deploy xenial just fine by itself, but when I try to bootstrap on xenial, it fails - maas shows the install completes, but juju complains that "instance started but did not change to Deployed state"
[16:02] <LiftedKilt> juju bootstrap xenial dr --config default-series=xenial --debug
[16:03] <LiftedKilt> I can bootstrap on 14.04 just fine
[16:10] <skay> does anyone have a bash prompt that shows the current juju env
[16:10] <skay> it could be handy on one of the machines I work on
[16:25] <lazyPower> cory_fu might, i know he's a bit of a wizard at that stuff with liquid prompt
[18:22] <beisner> hi LiftedKilt, i would suspect a bootstrap timeout.  ie. it may be taking slightly longer than the 10m default.  see `juju help bootstrap` to learn how to increase the time that juju will wait for the bootstrap machine
[18:26] <LiftedKilt>  beisner - the actual OS installation only takes a couple minutes, and I can see the output on MAAS that the Xenial install was successful. Are you thinking it's the tools installation that might be holding it up?
[18:27] <beisner> LiftedKilt, it may be a separate issue, but i also had the same "instance started but did not change to Deployed state" with xenial as it was overrunning the 10m default timeout a bit.  worth noting, the machines i'm talking about are a bit slow, and take several minutes just for POST.
[18:28] <LiftedKilt> beisner: I appreciate the tip - I increased the timeout to 20 min and am redeploying. Fingers crossed that it works! I successfully bootstrapped Xenial a couple days ago, I just haven't been able to do it since. Been driving me nuts.
[18:37] <A-Kaser> Hi
[18:39] <LiftedKilt> beisner: good looking out - it deployed just fine. Thanks!
[18:39] <beisner> LiftedKilt, \o/  awesome, happy to help.
[18:45] <marcoceppi> Office Hours in about 20 mins: https://plus.google.com/hangouts/_/hoaevent/AP36tYfv6UdYcQGhr8qG33I1H0mmMK-2c5vFDcgXtVZrCEa-Tk0WuQ?hl=en - to join, otherwise tune into https://ubuntuonair.com/
[18:51] <jcastro> kwmonroe: cory_fu: you guys doing office hours?
[18:51] <jcastro> someone from juju core would be great!
[18:51] <jcastro> cherylj: how about you?
[18:53] <cherylj> jcastro: what do I need to do?
[18:53]  * cherylj has nothing prepared
[18:53] <cherylj> oh snap, we should talk about the new "admin" and "default" model stuff coming out in beta3
[18:54] <cherylj> jcastro: and when is it?
[18:54] <jcastro> just come to the hangout
[18:54] <rick_h_> jcastro: linky me please and I'll join
[18:54] <jcastro> it's in 5 minu8tes
[18:54] <jcastro> the idea is not to be prepared, just talk
[18:54] <jcastro> it's like a podcast
[18:54] <rick_h_> cherylj: yea just party for a bit
[18:54] <marcoceppi> Office Hours in about 5 mins: https://plus.google.com/hangouts/_/hoaevent/AP36tYfv6UdYcQGhr8qG33I1H0mmMK-2c5vFDcgXtVZrCEa-Tk0WuQ?hl=en - to join, otherwise tune into https://ubuntuonair.com/
[19:00] <arosales> hoa, I initially read that as home owners assocation :-)
[19:09] <bdx> office-hours: http://paste.ubuntu.com/15500937/
[19:09] <c0s> kwmonroe: I don't if you guys have seen this https://d0.awsstatic.com/whitepapers/lambda-architecure-on-for-batch-aws.pdf - looks like a decent and clean explanation of the lambda-arch
[19:12] <arosales> c0s: looks like an interesting read, thanks
[19:13] <c0s> np
[19:16] <bdx> can we attach cinder vols to nova-lxd instances?
[19:16] <bdx> sorry
[19:17] <bdx> rick_h: good to hear! thanks!
[19:18] <bdx> marcoceppi: awesome!
[19:21] <cargonza> bdx, cinder + nova-lxd is not supported yet
[19:21] <bdx> cargonza: thanks, what is the status of that?
[19:22] <cargonza> still working the priorities and plan. we're finishing up the target goals for 16.04. We'll consider it for future planning.
[19:23] <bdx> cargonza: awesome! thanks!
[19:23] <bdx> marcoceppi: great, will do!
[19:26] <jcastro> LiftedKilt: heya, have you seen the layered charm bits?
[19:26] <LiftedKilt> jcastro: I haven't
[19:26] <jcastro> https://jujucharms.com/docs/devel/developer-layers
[19:26] <jcastro> so basically
[19:26] <LiftedKilt> I've heard it mentioned a few times, but haven't seen it yet
[19:26] <jcastro> in the past, we made you do things the hard way
[19:26] <jcastro> which is horrible
[19:26] <jcastro> now you compose a charm out of layers
[19:26] <LiftedKilt> jcastro: awesome - looking at link now. Thanks
[19:27] <jcastro> http://interfaces.juju.solutions/
[19:27] <arosales> also a good link is https://d0.awsstatic.com/whitepapers/lambda-architecure-on-for-batch-aws.pdf
[19:27] <arosales> buffer!
[19:27] <jcastro> so like, you could reuse a java layer the big data team uses, for example
[19:27]  * arosales meant https://jujucharms.com/docs/devel/developer-getting-started
[19:27] <jcastro> before everyone had to do things individually
[19:27] <arosales> we should like /developer-getting-started to developer-layers
[19:27] <LiftedKilt> jcastro: this will be awesome for creating the liferay charm, for example
[19:28] <arosales> s/like/link
[19:28] <jcastro> yes
[19:28] <LiftedKilt> I can just hand this to our devs
[19:28] <jcastro> LiftedKilt: in fact, just pretend the old way doesn't exist
[19:28] <LiftedKilt> jcastro: gladly haha
[19:28] <jcastro> so basically all the old charms weren't as testable or reusable, so like say we find a bug in one the java layers
[19:29] <jcastro> you'd just pick up the bug fix
[19:29] <jcastro> instead of "hey everyone for every charm using java, please fix foo."
[19:29] <LiftedKilt> oh that's clean
[19:33] <aisrael> charm push looks awesome
[19:38]  * lazyPower raises the roof at marco's ACLs
[19:38] <lazyPower> i totally did this
[19:38] <lazyPower> haha
[19:42] <c0s> arosales: I think if you replace Kinesis in that paper with Kafka - you'll get pretty much the same result ;)
[19:42] <c0s> but not AWS-locked
[19:42] <arosales> lazyPower: do you know if on "push" if one doesn't  specify the series does it error if the charm doesn't include a series metadata?
[19:43] <lazyPower> i do not know, i haven't tried
[19:43] <arosales> c0s: ok
[19:47] <lazyPower> arosales once i'm done restoring my phone and get my MFA restored, i'll let you know :P
[19:47] <arosales> lazyPower: no rush, just wondering
[19:52] <bdx> aweee
[19:52] <lazyPower> oh no
[19:52] <lazyPower> stream cut out
[19:53] <arosales> :-)
[19:53] <arosales> hit wrong button
[19:53] <marcoceppi> haha, I pressed "stop stream" instead of "stop sharing"
[19:54] <marcoceppi> sorry everyone
[19:54] <rick_h_> we were about to wrap up, it'll be ok
[19:54] <rick_h_> we'll just give marcoceppi a hard time for a while :P
[19:54] <marcoceppi> <3
[20:06] <arosales> lazyPower: rick_h_ was saying that if you try to push a charm and it has no series in the metadata you should get an error back
[20:18] <lazyPower> ah
[20:18] <lazyPower> I've only pushed to implicit series locations in the store
[20:18] <lazyPower> so, good question and good follow up :D
[20:40] <falanx> if we were to deploy openstack with juju and use lxd for nova, would we have no persistent storage?  Is that what cargonza meant when he said cinder + nova-lxd is not supported?
[20:55] <bdx> falanx: My understanding is that it is being considered as a future feature ...
[20:55] <bdx> cargonza:^
[21:03] <bdx> falanx: see cargonza's message above
[21:17] <cargonza> falanx, the openstack lxd charm deploys ceph for storage. cinder is another type of storage that we still need to support in nova-lxd
[21:36] <LiftedKilt> cargonza: so by cinder you mean the reference architecture cinder using lvm, right?
[21:37] <LiftedKilt> cargonza: the openstack lxd charm integrates with ceph allowing containers to mount ceph volumes?
[21:41] <cargonza> LiftedKilt, yes on both
[21:43] <bdx> LiftedKilt: part of the purpose of cinder is to abstract you from the backend storage implementation
[21:44] <LiftedKilt> cargonza: awesome
[21:44] <LiftedKilt> bdx: my understanding is that cinder is both the reference lvm implementation as well as the name for the general block storage api integration for openstack.
[21:45] <bdx> LiftedKilt: It doesn't matter to the openstack instance what the underlying storage may be ...as it is just consuming a cinder storage resource ... it doesn't matter what backend you use
[21:45] <bdx> or it shouldn't at least
[21:46] <bdx> thats the whole point right?
[21:49] <LiftedKilt> indeed
[23:08] <A-Kaser> ping admcleod- coreycb kwmonroe kjackal
[23:09] <kwmonroe> pong A-Kaser
[23:09] <kwmonroe> A-Kaser: i'm about 200% sure you meant cory_fu instead of coreycb ;)
[23:09] <A-Kaser> right :)
[23:09] <A-Kaser> bad tab
[23:09] <kwmonroe> np, what's up?
[23:10] <A-Kaser> I'm trying to set my credentials to test on aws
[23:11] <A-Kaser> I would like to use eu-central-1 or eu-west-1
[23:11] <A-Kaser> with devel documentation example it seems to be ignored my default-region
[23:12] <A-Kaser> and the link to have more information credentials is https://jujucharms.com/docs/devel/credentials/ 404
[23:12] <A-Kaser> could you help this little point :)
[23:13] <kwmonroe> A-Kaser: i noticed that too with an azure deployment, but assumed i did something wonky.. i'll check again and open a bug (unless rick_h_ knows whether or not default_region is not always honored off hand).  anyway, you can force the bootstrap to use a region like this:
[23:13] <kwmonroe> (/me looks for a minute)
[23:13] <A-Kaser> and just in case, I'm the dude which sent you an email right now :)
[23:13] <A-Kaser> no pb :)
[23:15] <kwmonroe> A-Kaser: i think this will work for ya: juju set-default-region aws eu-central-1 (or west)
[23:16] <kwmonroe> A-Kaser: then proceed with your bootstrap.  alternatively, you can set the region during bootstrap with " juju bootstrap <controller name> <cloud>[/region]"
[23:17] <kwmonroe> so like, juju bootstrap kevin-is-amazing aws/eu-central-1
[23:17] <kwmonroe> or whatever...
[23:17] <magicaltrout> that would be a lie though
[23:17] <kwmonroe> dag nab it magicaltrout - i thought you'd be in bed by now.
[23:17] <arosales> I did "juju set-defatul-region" and that worked for me
[23:17] <magicaltrout> hehe
[23:18] <kwmonroe> arosales: s/defatul/default, but cool.  thx for the confirmation.
[23:18] <A-Kaser> juju like to talk : 20 x WARNING could not delete security group "juju-4520f63e-51f6-43bd-8b89-336a0190eeef-0": resource sg-15670d6d has a dependent object (DependencyViolation)
[23:19] <arosales> kwmonroe: yes what you said
[23:19] <kwmonroe> :)
[23:19] <A-Kaser> kwmonroe: default-region is ok now
[23:19] <A-Kaser> thx
[23:19] <kwmonroe> cool, np
[23:20] <kwmonroe> A-Kaser: can you tell me what page linked you to your /credentials 404?  we need to fix that up.
[23:22] <A-Kaser> https://jujucharms.com/docs/devel/getting-started
[23:22] <A-Kaser> link just before chapter 4. Bootstrap
[23:23] <A-Kaser> -> please see this guide to credentials
[23:23] <kwmonroe> ahhh, yup A-Kaser, thanks
[23:26] <A-Kaser> I suppose it's possible to have more than one controler, so how can I specify which controler used with my deploy command ?
[23:27] <A-Kaser> (i'm trying to read "juju help deploy")
[23:27] <kwmonroe> A-Kaser: firstly, we'll get the docs fixed up with this https://github.com/CanonicalLtd/jujucharms.com/issues/235, thanks for the report
[23:28] <kwmonroe> A-Kaser: secondly, you choose your controller with the "juju switch" command
[23:29] <kwmonroe> so if you have more than one, for example, an aws controller and a gce controller and an azure controller, you would "juju switch gce" to make that the controller that fulfills deployment requests.
[23:30] <A-Kaser> oh okay, so it's not recommanded to have 2 terminal using juju on the same time with different controller I suppose
[23:36] <kwmonroe> yeah A-Kaser, i don't recommend that.  you could probably do it if you were vigilient in "juju switch <foo>" before each juju interaction, but i'm not that multi-taskable.
[23:36] <A-Kaser> FYI on AWS deploy wordpress don't open 80 in security group, so it's not possible to open it in a browser
[23:37] <A-Kaser> kwmonroe: ok no problem I will have only one instance :)
[23:37] <kwmonroe> A-Kaser: i do, however, have long-running deployments and controller, so for example, once a month, i switch to my openstack controller, juju ssh over to do something, but then switch back.  it's just not something i would do very often ;)
[23:39] <A-Kaser> yes, I thought it was possible to add something like "-controler=master1" in deploy command; but switch will be fine
[23:39] <kwmonroe> A-Kaser: can you "juju expose wordpress"?
[23:39] <kwmonroe> i'm not certain about the correlation between juju expose and aws security groups, but if you expose wordpress, i'm curious if that lets you get to it in a browser.
[23:42] <A-Kaser> I have juju 1.25 and 2.0 ... my fault, i'm removing 1.25
[23:45] <kwmonroe> A-Kaser: i think they can co-exist pretty well.. just need to run 'update-alternatives --config=juju" to set whichever one you want.
[23:45] <kwmonroe> or removing 1.25 and going all-in with 2.0 is cool too :)
[23:46] <kwmonroe> or you could pull a magicaltrout and run from master every 2 hours.
[23:48] <c0s> kwmonroe: I was looking at some of the charms description like flume-kafka and whatever.... And something caught my attention
[23:48] <c0s> namely: the section on smoke testing of the deployed bundle
[23:49] <c0s> like every single bundle has it. Is there a concept of auto-smoking of a unit at the end of the deployment?
[23:51] <kwmonroe> c0s: kinda -- each charm in a bundle gets all the ./tests/* run when it is bundletested, so in that regard, each unit is smoke tested
[23:51] <kwmonroe> one sec, i'll find an ex
[23:52] <c0s> I know what you're talking about
[23:52] <c0s> I have a bit different angle: instead of asking a user to smoke test a hadoop cluster, something simple and automatic could be done by Juju itself.
[23:53] <c0s> like explained here
[23:53] <c0s> hdfs dfs -chmod -R 777 /tmp/hdfs-test
[23:53] <c0s> hdfs dfs -ls /tmp # verify the newly created hdfs-test subdirectory exists
[23:53] <c0s> hdfs dfs -rm -R /tmp/hdfs-test
[23:53] <c0s> hdfs dfs -ls /tmp # verify the hdfs-test subdirectory has been removed
[23:53] <c0s> and then for YARN, and so on
[23:53] <c0s> I think user shouldn't even see this... like ever
[23:56] <c0s> does it make sense, kwmonroe?
[23:57] <kwmonroe> yeah, i hear ya c0s
[23:58] <kwmonroe> i guess the point of that "hdfs dfs -xxx" in the readme is only there to tell the user how to manually smoke the deployment in case they didn't use a promulgated version