[08:30] <kjackal> Good morning Juju world!
[08:59] <D4RKS1D3> good morning kjackal :)
[09:00] <kjackal> The darkside (D4RKS1D3) of #juju said good morning back to me. A hint to take the day of?!
[09:01] <D4RKS1D3> Probably is a good option! hahaha, can I take the day off too?
[09:02]  * magicaltrout never gets a day off....
[09:02] <magicaltrout> oh yeah i'm paid by the hour
[09:02] <magicaltrout> never mind then
[09:04] <kjackal> Got a question for you people, how do you ensure that you can reproduce your build out put binaries?
[09:04] <kjackal> magicaltrout: D4RKS1D3 ^
[09:04] <magicaltrout> ie, they are always the same?
[09:05] <kjackal> magicaltrout: you can reproduce the binary you build 10 minutes ago
[09:05] <kjackal> do you have a fork of the layers you are using?
[09:06] <magicaltrout> nope... i can't :)
[09:06] <kjackal> Because if you are building using remote layers, someone might go and change what is in the remote repo...
[09:06] <magicaltrout> i did think about that a while ago, it would be cool to tag layers
[09:07] <magicaltrout> there's no reason why you couldn't create a `maven central` of layers
[09:08] <kjackal> yeap, agreed. We should have a solution to this request
[09:14] <kjackal> magicaltrout: I am going to ask this in the list, we might get some more tracktion
[09:34] <SimonKLB> kjackal: if you want to make sure that the layers doesn't change, why not clone them and build your charm using local layers?
[09:35] <SimonKLB> good thing about having them all under version control is that you can checkout which ever revision you want and build locally
[09:36] <kjackal> SimonKLB: Yes, this is what I was hinting by saying "forking the layers used and getting them locally before charm build"
[09:37] <kjackal> SimonKLB:  You need to have a fork of the layers involved, because someone might go and change the commit history
[09:37] <SimonKLB> ah yea, but thats just bad manners :)
[09:38] <kjackal> SimonKLB: Aslo, checking out specific versions does not solve your problem, you will also need to take a note of "for charm revision 123 layer-xyz was on commit 1234521AE .... "
[09:39] <kjackal> SimonKLB: Github is a crazy world, repositories get missing all the time :)
[09:40] <SimonKLB> you mean if you want to build an older version of your charm?
[09:41] <kjackal> SimonKLB: Yes, lets say you realise you introduced a bug and you need to do a binary search on the release binaries to find out when was that introduced
[09:42] <SimonKLB> yea thats more tricky! would actually be nice if the build process would tag up each layer at which revision they were on
[09:44] <kjackal> Or another example, you want to push an emergency fix (you have a client on the phone) and you realise the charm is currently failing tests. How would you go back to a working version and patch just your own layer. It is just akward.
[09:44] <kjackal> And I am wondering what the community is doing
[09:46] <kjackal> SimonKLB: perhapse add a build.explain in the build output so you can later track what got in the build
[09:47] <kjackal> SimonKLB: We could/should have done this discussion on the list
[09:48] <SimonKLB> ill let the folks with more indepth knowledge of the build system give a proper response on the list, i just think its an interesting topic to discuss
[09:48] <SimonKLB> reverting a version in the charmstore isnt problematic though, is it? or are you talking about going back to a working version in your own CI?
[09:50] <SimonKLB> because i do agree with you that its not easy to roll back your charm to an earlier state by re-building all the layers etc
[09:50] <kjackal> SimonKLB: From the charmstore you can get the build revision number of the charm. I am not aware of a way to pinpoint the commit hash of each layer used based on the charm's revision number.
[09:51] <SimonKLB> no thats correct, i just mean you can revert to a working version if you accedentally push a buggy one
[09:52] <SimonKLB> but rerolling it trying to get back to the different layer versions might be tricky
[09:53] <SimonKLB> it would be really neat if it created some kind of manifest during the build that stated "layer repo commithash"
[12:34] <D4RKS1D3> kjackal, how about your the off? xD
[12:35] <kjackal> In terms of productivity you can consider this day as good as off! :)
[12:36] <magicaltrout> the norm then
[12:37] <kjackal> But D4RKS1D3, I have some of hours left so I will make up for the lost time.
[12:37] <magicaltrout> just been quoted £20k for a new bathroom kjackal
[12:37] <magicaltrout> is that more than a tesla?
[12:37] <magicaltrout> should i get a new bathroom, or go second hand? ;)
[12:37] <kjackal> magicaltrout: New bathroom I hear! In LA I assume?
[12:38] <magicaltrout> lol
[12:38] <magicaltrout> i wish
[12:39] <kjackal> London, 20k for a bathroom. Sounds about right!
[12:39] <magicaltrout> aye
[12:39] <kjackal> Renting it... of course!
[12:39] <magicaltrout> rent my bathroom
[13:07] <aisrael> 884157
[13:15] <magicaltrout> aisrael: I'm sure this isn't the first time you posted pin numbers into IRC
[13:15] <magicaltrout> you should watch that bad habit one day someone will steal your money :P
[13:16] <tvansteenburgh> i think that was his bank account balance actually
[13:23] <magicaltrout> tvansteenburgh: he's been hanging out with you too much then
[13:24] <magicaltrout> .. or maybe not enough
[13:24] <magicaltrout> i'll check with cory_fu
[13:34] <aisrael> magicaltrout: too true :/
[14:07] <feral> yo, the django bundle, the one with python-django, postgresql and gunicorn in it doesen't seem to be working. if i access the public ip of the exposed python-django, it spits out <h1>Internal Server Error</h1>. I set the mediawiki site with haproxy and mariadb from the tutorials and that one works... it's all on my localhost. what do yall think?
[14:11] <feral> is there configuration, prior to exposing to be made? i just heard about juju last night, so i don't really know much
[14:12] <deanman> feral: What exactly URL are you using? I've noticed from personal experience that some bundles although expose HTTP you have to also append a valid path to work, e.g. http://10.0.3.1/wiki
[14:15] <feral> deanman: aham, i'm using http://10.215.180.29:8080/ it
[14:15] <feral> deanman: it's automatically generated by lxd init
[14:16] <feral> deanman: if i don't put the port at the end of it, it gives me "Unable to connect", classic firefox
[14:17] <feral> deanman: that's how django works if i set it up locally, it works out of the box with ip:port as url
[14:20] <deanman> feral: How's your `juju status --color` looking? All green ? :-)
[14:23] <feral> deanman: nah, at the App/Status column, all: gunicorn, django and postgress are "unknown" and the same at the Unit/Workload, the Unit/Agent-s are "idle" and the Machine/State-s are "started"
[14:23] <feral> deanman: mostly yellow...
[14:26] <feral> deanman: it's kinda the same picture at the mediawiki model, but mediawiki still works
[14:26] <deanman> Can you paste your juju status on paste.ubuntu.com ?
[14:28] <feral> deanman: yup, here it is: https://paste.ubuntu.com/23420917/
[14:30] <deanman> feral: You could try `juju debug-log` on a second session and try hit that URL again, maybe something interesting pop-out
[14:30] <deanman> feral: that status looks ok to me, I'm also new to juju !!
[14:32] <icey> should the new metrics stuff be backwards compatible with juju 1 or is it a juju 2 only feature?
[14:33] <mattyw> icey, juju 2 only
[14:33] <feral> deanman: yeah... it should be fine, i still think it's something wrong with the python-django charm, what do you mean by "on a second session"?
[14:34] <icey> mattyw: unfortunate
[14:34] <icey> mattyw: it seems that you can
[14:34] <icey> 't even deploy a charm that has them setup on 1?
[14:35] <deanman> feral: A new shell, in case you want to monitor juju logs continuously. At least this is what i usually do...
[14:37] <feral> deanman: oh, yeah, but "watch" ommits the colors : ))
[14:37] <lazyPower> feral - watch -c juju status --color
[14:38] <deanman> feral: no watch on debug-logs
[14:38] <lazyPower> ^ the magic incantation to keep color under watch
[14:40] <deanman> lazyPower: Any idea when 2.1.0-beta2 is due? Got a really annoying bug filled which limits me from having a juju workshop inside our company :(
[14:40] <feral> lazyPower: thanks : )
[14:40] <lazyPower> deanman - we just release 2.0.1 stable last week
[14:41] <lazyPower> not sure where you found reference to a 2.1.0-beta2?
[14:41] <deanman> lazyPower: It was triaged by Anastia (https://bugs.launchpad.net/juju/+bug/1638322)
[14:41] <mup> Bug #1638322: Able to bootstrap but not deploy any charm behind corporate network with proxy <lxd> <proxy> <juju:Triaged by rharding> <https://launchpad.net/bugs/1638322>
[14:43] <lazyPower> deanman - ah, ok. I dont have an ETA on that release, sorry
[15:21] <tvansteenburgh> lazyPower: are you using charmbox with juju2?
[15:21] <lazyPower> tvansteenburgh yep
[15:21] <tvansteenburgh> lazyPower: :latest or :devel?
[15:21] <lazyPower> :devel
[15:21] <lazyPower> sorry we're late to make the tag rollover :(
[15:22] <tvansteenburgh> lazyPower: do you have a wrapper script that mounts ~/.local/share/juju or something? i don't see that in charmbox itself
[15:22] <lazyPower> tvansteenburgh - worse, i have a gnarly alias :)
[15:22] <tvansteenburgh> haha
[15:23] <lazyPower> http://paste.ubuntu.com/23421138/
[15:23] <lazyPower> theres my alias, as i said its gnarly. lots of stuff specific to my shell setup too
[15:24] <tvansteenburgh> lazyPower: np, turns out i just needed :devel instead of :latest
[15:24] <lazyPower> awesome :) happy to help
[15:49] <shruthima> hi kevin, when we are making use of  ibm-im layer(from http://interfaces.juju.solutions/layer/ibm-im/ )as base layer  in the other charms we observed reactive file and resources of ibm-im layer are  not geting updates. Can u please suggest ?
[15:49] <shruthima> http://paste.ubuntu.com/23421259/
[15:49] <shruthima> updated*
[16:02] <kwmonroe> shruthima: could you paste the output from "charm build --no-local-layers -r" in the layer-ibm-http directory?
[16:02] <kwmonroe> shruthima: i'm guessing you might have a local copy of ibm-im that does not include the resources
[16:04] <shruthima> kwmonroe: when we use ibm-im layer from locally  resources r getting updated
[16:15] <shruthima> kwmonroe: output of charm build --no-local-layers -r http://paste.ubuntu.com/23421387/
[16:17] <kwmonroe> yup shruthima, i just verified that on my machine too.  it looks like the resources and terms metadata keys are not being merged during charm build.  instead, they are being overwritten.
[16:20] <shruthima> ya , how to resolve this ?
[16:23] <shruthima> reactive file of im is also not getting merged
[16:23] <kwmonroe> shruthima: just verified the other thing you said works for me too.. if i charm build *without* --no-local-layers, it works as expected
[16:24] <shruthima> ya kevin locally it is working fine
[16:24] <shruthima> any issue with the http://interfaces.juju.solutions/layer/ibm-im/?
[16:26] <kwmonroe> oooohhh.. i know what's happening shruthima
[16:26] <kwmonroe> shruthima: do an "ls ~/charms/deps/layer"
[16:26] <kwmonroe> i bet you see a "trunk" subdirectory there
[16:27] <shruthima> ya trunk dir is there
[16:28] <kwmonroe> so, when 'charm build' tries to fetch layers stored in bzr, it does a 'bzr branch lp:~foo/trunk" in the ~/charms/deps/layer directory.  This is bad because it would branch "ibm-im" to the ./trunk directory first, and the it will branch "ibm-base" to the ./trunk directory when it goes to process the base layer.
[16:28] <kwmonroe> shruthima: i'm 99% sure cory_fu has a fix for this
[16:29] <kwmonroe> and kjackal, i think you've seen it too (when charm build extracts layer deps to the same 'trunk' directory)
[16:29] <shruthima> ohh
[16:30] <kwmonroe> shruthima: original issue was opened by kjackal here:  https://github.com/juju/charm-tools/issues/268
[16:30] <kwmonroe> shruthima: and the fix was merged by cory_fu here:  https://github.com/juju/charm-tools/pull/269
[16:32] <shruthima> oh k
[16:34] <shruthima> kwmonroe: so do we need to change anything in http://interfaces.juju.solutions/layer/ibm-im/?
[16:35] <kwmonroe> no shruthima: there is nothing to do for your layers.  any charm that includes 2 layers from bzr will be affected.   i just checked the latest charm-tools package (2.1.5), and the fix has not landed there yet.
[16:35] <kwmonroe> shruthima: for now, the best workaround you can do is the one you've been doing -- build your charms with local layers
[16:35] <cory_fu> kwmonroe, shruthima: marcoceppi said he will make a release with that fix in today
[16:36] <kwmonroe> oh cool cory_fu.  thx marcoceppi!
[16:36] <kwmonroe> shruthima: you may not have to use the local layer workaround for long...
[16:37] <shruthima> oh great thank you
[16:37] <shruthima> so we have to update charm tools
[16:37] <cory_fu> He is going to a meet up now, though, so it will probably be a couple of hours, unfortunately
[16:38] <shruthima> no worries thanks for the updates
[16:38] <kwmonroe> yup shruthima, i can send you an email when the updated charm-tools package is available.
[16:38] <shruthima> ok kwmonroe thanku :)
[16:38] <kwmonroe> np
[18:23] <bloodearnest> using the new charm-tools 2.1.5, charm build is broken for me on trusty, complaining about needing pip>=7.1.2
[18:23] <bloodearnest> did I miss something?
[18:38] <aisrael> bloodearnest: That's a bug in the new release. Did you just apt-get update and upgrade? I think this was fixed yesterday
[18:39] <bloodearnest> aisrael, I just did in a different trusty box, problem persists for me.
[18:39] <aisrael> marcoceppi: ^^
[18:39] <aisrael> bloodearnest: Hopefully that fix will be uploaded soon.
[18:41] <bloodearnest> aisrael, thanks
[18:46] <aisrael> Sorry about that!
[18:47] <bloodearnest> aisrael, nw, it happens
[19:52] <petevg> bcsaller, cory_fu: PR for you. It's been rebased from master: https://github.com/juju-solutions/matrix/pull/11
[19:57] <petevg> bcsaller, cory_fu: the one outstanding issue is that the new changes from master break tests/glitch/test_glitch (complains about waitname being referenced before assignment). Glitch works fine in the other tests, though.
[19:58] <bcsaller> petevg: thanks, I'll check it out
[23:32] <MrDanDan> hi, juju set-config changed?
[23:35] <MrDanDan> it's just config now, got it