=== rmcall_ is now known as rmcall === frankban|afk is now known as frankban [08:30] Good morning Juju world! [08:59] good morning kjackal :) [09:00] The darkside (D4RKS1D3) of #juju said good morning back to me. A hint to take the day of?! [09:01] Probably is a good option! hahaha, can I take the day off too? [09:02] * magicaltrout never gets a day off.... [09:02] oh yeah i'm paid by the hour [09:02] never mind then [09:04] Got a question for you people, how do you ensure that you can reproduce your build out put binaries? [09:04] magicaltrout: D4RKS1D3 ^ [09:04] ie, they are always the same? [09:05] magicaltrout: you can reproduce the binary you build 10 minutes ago [09:05] do you have a fork of the layers you are using? [09:06] nope... i can't :) [09:06] Because if you are building using remote layers, someone might go and change what is in the remote repo... [09:06] i did think about that a while ago, it would be cool to tag layers [09:07] there's no reason why you couldn't create a `maven central` of layers [09:08] yeap, agreed. We should have a solution to this request [09:14] magicaltrout: I am going to ask this in the list, we might get some more tracktion [09:34] 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] good thing about having them all under version control is that you can checkout which ever revision you want and build locally [09:36] SimonKLB: Yes, this is what I was hinting by saying "forking the layers used and getting them locally before charm build" [09:37] SimonKLB: You need to have a fork of the layers involved, because someone might go and change the commit history [09:37] ah yea, but thats just bad manners :) [09:38] 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] SimonKLB: Github is a crazy world, repositories get missing all the time :) [09:40] you mean if you want to build an older version of your charm? [09:41] 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] 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] 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] And I am wondering what the community is doing [09:46] SimonKLB: perhapse add a build.explain in the build output so you can later track what got in the build [09:47] SimonKLB: We could/should have done this discussion on the list [09:48] 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] 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] 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] 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] no thats correct, i just mean you can revert to a working version if you accedentally push a buggy one [09:52] but rerolling it trying to get back to the different layer versions might be tricky [09:53] it would be really neat if it created some kind of manifest during the build that stated "layer repo commithash" [12:34] kjackal, how about your the off? xD [12:35] In terms of productivity you can consider this day as good as off! :) [12:36] the norm then [12:37] But D4RKS1D3, I have some of hours left so I will make up for the lost time. [12:37] just been quoted £20k for a new bathroom kjackal [12:37] is that more than a tesla? [12:37] should i get a new bathroom, or go second hand? ;) [12:37] magicaltrout: New bathroom I hear! In LA I assume? [12:38] lol [12:38] i wish [12:39] London, 20k for a bathroom. Sounds about right! [12:39] aye [12:39] Renting it... of course! [12:39] rent my bathroom [13:07] 884157 [13:15] aisrael: I'm sure this isn't the first time you posted pin numbers into IRC [13:15] you should watch that bad habit one day someone will steal your money :P [13:16] i think that was his bank account balance actually [13:23] tvansteenburgh: he's been hanging out with you too much then [13:24] .. or maybe not enough [13:24] i'll check with cory_fu [13:34] magicaltrout: too true :/ [14:07] 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

Internal Server Error

. 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] 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] 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] deanman: aham, i'm using http://10.215.180.29:8080/ it [14:15] deanman: it's automatically generated by lxd init [14:16] deanman: if i don't put the port at the end of it, it gives me "Unable to connect", classic firefox [14:17] 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] feral: How's your `juju status --color` looking? All green ? :-) [14:23] 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] deanman: mostly yellow... [14:26] deanman: it's kinda the same picture at the mediawiki model, but mediawiki still works [14:26] Can you paste your juju status on paste.ubuntu.com ? [14:28] deanman: yup, here it is: https://paste.ubuntu.com/23420917/ [14:30] feral: You could try `juju debug-log` on a second session and try hit that URL again, maybe something interesting pop-out [14:30] feral: that status looks ok to me, I'm also new to juju !! [14:32] should the new metrics stuff be backwards compatible with juju 1 or is it a juju 2 only feature? [14:33] icey, juju 2 only [14:33] 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] mattyw: unfortunate [14:34] mattyw: it seems that you can [14:34] 't even deploy a charm that has them setup on 1? [14:35] feral: A new shell, in case you want to monitor juju logs continuously. At least this is what i usually do... [14:37] deanman: oh, yeah, but "watch" ommits the colors : )) [14:37] feral - watch -c juju status --color [14:38] feral: no watch on debug-logs [14:38] ^ the magic incantation to keep color under watch [14:40] 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] lazyPower: thanks : ) [14:40] deanman - we just release 2.0.1 stable last week [14:41] not sure where you found reference to a 2.1.0-beta2? [14:41] lazyPower: It was triaged by Anastia (https://bugs.launchpad.net/juju/+bug/1638322) [14:41] Bug #1638322: Able to bootstrap but not deploy any charm behind corporate network with proxy [14:43] deanman - ah, ok. I dont have an ETA on that release, sorry === cmagina_ is now known as cmagina [15:21] lazyPower: are you using charmbox with juju2? [15:21] tvansteenburgh yep [15:21] lazyPower: :latest or :devel? [15:21] :devel [15:21] sorry we're late to make the tag rollover :( [15:22] lazyPower: do you have a wrapper script that mounts ~/.local/share/juju or something? i don't see that in charmbox itself [15:22] tvansteenburgh - worse, i have a gnarly alias :) [15:22] haha [15:23] http://paste.ubuntu.com/23421138/ [15:23] theres my alias, as i said its gnarly. lots of stuff specific to my shell setup too [15:24] lazyPower: np, turns out i just needed :devel instead of :latest [15:24] awesome :) happy to help [15:49] 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] http://paste.ubuntu.com/23421259/ [15:49] updated* [16:02] shruthima: could you paste the output from "charm build --no-local-layers -r" in the layer-ibm-http directory? [16:02] shruthima: i'm guessing you might have a local copy of ibm-im that does not include the resources === jamespag` is now known as jamespage [16:04] kwmonroe: when we use ibm-im layer from locally resources r getting updated [16:15] kwmonroe: output of charm build --no-local-layers -r http://paste.ubuntu.com/23421387/ [16:17] 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] ya , how to resolve this ? [16:23] reactive file of im is also not getting merged [16:23] 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] ya kevin locally it is working fine [16:24] any issue with the http://interfaces.juju.solutions/layer/ibm-im/? [16:26] oooohhh.. i know what's happening shruthima [16:26] shruthima: do an "ls ~/charms/deps/layer" [16:26] i bet you see a "trunk" subdirectory there [16:27] ya trunk dir is there [16:28] 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] shruthima: i'm 99% sure cory_fu has a fix for this [16:29] and kjackal, i think you've seen it too (when charm build extracts layer deps to the same 'trunk' directory) [16:29] ohh [16:30] shruthima: original issue was opened by kjackal here: https://github.com/juju/charm-tools/issues/268 [16:30] shruthima: and the fix was merged by cory_fu here: https://github.com/juju/charm-tools/pull/269 [16:32] oh k [16:34] kwmonroe: so do we need to change anything in http://interfaces.juju.solutions/layer/ibm-im/? [16:35] 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] shruthima: for now, the best workaround you can do is the one you've been doing -- build your charms with local layers [16:35] kwmonroe, shruthima: marcoceppi said he will make a release with that fix in today [16:36] oh cool cory_fu. thx marcoceppi! [16:36] shruthima: you may not have to use the local layer workaround for long... [16:37] oh great thank you [16:37] so we have to update charm tools [16:37] He is going to a meet up now, though, so it will probably be a couple of hours, unfortunately [16:38] no worries thanks for the updates [16:38] yup shruthima, i can send you an email when the updated charm-tools package is available. [16:38] ok kwmonroe thanku :) [16:38] np === frankban is now known as frankban|afk [18:23] 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] did I miss something? [18:38] 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] aisrael, I just did in a different trusty box, problem persists for me. [18:39] marcoceppi: ^^ [18:39] bloodearnest: Hopefully that fix will be uploaded soon. [18:41] aisrael, thanks === zz_CyberJacob is now known as CyberJacob [18:46] Sorry about that! [18:47] aisrael, nw, it happens [19:52] bcsaller, cory_fu: PR for you. It's been rebased from master: https://github.com/juju-solutions/matrix/pull/11 [19:57] 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] petevg: thanks, I'll check it out === blahdeblah_ is now known as blahdeblah [23:32] hi, juju set-config changed? [23:35] it's just config now, got it === CyberJacob is now known as zz_CyberJacob