=== natefinch-afk is now known as natefinch
[02:04] <geekgonecrazy> Greetings everyone.  Does anyone know of a mongodb 3.2 charm?  Looks like the "mongodb" one is 2.4 only
[02:08] <geekgonecrazy> or even a mongo 2.6 version :D
[03:07] <lazyPower> geekgonecrazy: Are you looking for one thats ready to use or are you looking for something thats still wip but on its way to being better than the 2.4 charm we have available today?
[03:08] <lazyPower> geekgonecrazy: if you're looking for the former, we dont have anything more recent than whats in the charm store. There's a layer that has been under dev and put on hold for other priorities that you could reasonably pick up and help complete
[03:11] <geekgonecrazy> lazyPower: i'm not necessarily looking for better.  :)  Rocket.Chat due to meteor underneith needs at least Mongodb 2.6 to function.
[03:12] <geekgonecrazy> After wasting several hours trying to get our charm working, I finally realized that the mongodb charm is only at 2.4
[03:12] <geekgonecrazy> :D
[03:14] <geekgonecrazy> I ended up taking the juju 1.x type approach instead of 2.0 so no layers.  Mainly because I was looking to get done quickly and had absorbed enough information prior to your suggestion that it was just easier to go this way for a quick and dirty first version
[03:14] <geekgonecrazy> https://github.com/RocketChat/juju-charm
[03:18] <geekgonecrazy> lazyPower: but I have a team mate very urgently wanting to try it.  So if you know where abouts I can find the wip version we'd gladly take a look
[03:18] <geekgonecrazy> I assume its one that would have to be built and not already in the charm store in some beta form :)
[03:50] <lazyPower> geekgonecrazy: correct, let me fish that repository up
[03:51] <lazyPower> geekgonecrazy: https://github.com/marcoceppi/layer-mongodb
[03:51] <lazyPower> no readme, but the gist is clone that repository, run `charm build` and give it a whirl.
[03:52] <geekgonecrazy> lazyPower: sweet! much appreciated!
[03:52]  * lazyPower hat tips
[07:53] <kjackal> Good morning Juju world!
=== frankban|afk is now known as frankban
[09:15] <jacekn> what's the process to get this charm into xenial? It should work just fine from what I can see
[09:34] <kjackal> jacekn: what charm is this?
[09:42] <jacekn> kjackal: I forgot to paste it didn't I? https://jujucharms.com/apache2/trusty/20
[09:42] <jacekn> from what I can see it's just simple upload + publish
[09:44] <kjackal> jacekn: yeap, sounds simple. You should ping the maintainer of the charm
[09:46] <jacekn> kjackal: what's charmers' IRC nick?
[09:46] <kjackal> let me check
[09:47] <kjackal> jacekn:  the maintainer should be gnuoy if I am not mistaken
[09:47] <jacekn> gnuoy: so hello! I want to use https://jujucharms.com/apache2/trusty/20 on xenial, I think it shoudl work just fine but needs to be pushed to jujucharms.com
[09:48] <jacekn> gnuoy: is this somethig you can help your IS colleagues with?
[09:50] <gnuoy> jacekn, I haven't touched that charm in years
[09:50] <gnuoy> jacekn, happy to help out however I can though
[09:50] <gnuoy> Maybe transfer of ownership is the best longterm thing?
[09:50] <jacekn> gnuoy: if you're not active maintainer that's fine, I'm just tryihng to figure out who to talk to abou tit
[09:51] <jacekn> the problem here is that I can probably push it but it's promulgated charm and it would end up in xenial without any review
[10:52] <kjackal> Hey marcoceppi the jenkins charm on github.com/jenkinsci is using some interfaces that are outside the jenkinsci org. I can add them to the the jenkinsci org if i get added there or we could pull the jenkins charm in juju-solutions along with the review-queue etc.
=== wolverin_ is now known as wolverineav_
[13:25] <marcoceppi> kjackal: what?
[13:44] <kjackal> marcoceppi: the jenkins charm (https://github.com/jenkinsci/jenkins-charm) uses layers (https://github.com/jenkinsci/jenkins-charm/blob/master/layer.yaml) that are  in free's github repos (eg https://github.com/freeekanayaka/interface-jenkins-extension.git)
[13:44] <marcoceppi> kjackal: that's fine
[13:45] <kjackal> marcoceppi: wouldn't it be better if we move the interfaces with the charm; under the same org?
[13:46] <kjackal> marcoceppi: Free does not object to that
[13:47] <marcoceppi> kjackal: sure, but we don't own that org, jenkins does, and it takes a bit of time
[13:47] <marcoceppi> i'd rather just move the interface to github.com/charms for now, as a central location
[13:48] <kjackal> marcoceppi: that would be an improvement, I could move to juju-solutions
[13:48] <marcoceppi> no
[13:48] <marcoceppi>  /charms would be better
[13:49] <kjackal> marcoceppi: we are talking about https://github.com/orgs/charms/people ? With three people?
[13:59] <deanman> j #ubuntu
[13:59] <kjackal> marcoceppi: (I thought we owned jenkinsci)
[14:00] <marcoceppi> kjackal: no, jenkins.org owns it
[14:00] <marcoceppi> it's their upstream org
=== mup_ is now known as mup
[14:30] <kjackal> kwmonroe: are yo around?
=== jamespag` is now known as jamespage
[14:48] <marcoceppi> rick_h: btw, stop editing your yaml files for $JUJU_HOME, `juju help set-default-region` ;)
[14:49] <rick_h> marcoceppi: oh! you're right!
[14:49]  * rick_h hangs head in shame
[14:49] <mgz> marcoceppi: some old habits are very hard to break
[14:50] <mgz> I almost like hand editing yaml now...
[14:53]  * rick_h thinks mgz is nuts...but ok
[14:54] <rick_h> SimonKLB: ok, got one going with released 2.0.1 http://paste.ubuntu.com/23563553/
[14:54] <rick_h> SimonKLB: same thing, no volume in the output
[14:58] <SimonKLB> rick_h: odd...
[14:59] <SimonKLB> rick_h: we seem to diverge at the user data, the size is different and after that i get 'destroying model "controller"'
[14:59] <SimonKLB> while you get 'started instance "47d92c..'
[15:00] <marcoceppi> rick_h: what's the api endpoint for bundle file? https://api.jujucharms.com/v5/bundle/canonical-kubernetes/file/bundle.yaml
[15:00] <marcoceppi> rick_h: I keep trying variations of that, and can't get it to work
[15:00] <rick_h> marcoceppihttps://api.jujucharms.com/v5/bundle/canonical-kubernetes/archive/bundle.yaml:
[15:00] <rick_h> marcoceppi: s/file/archive
[15:00] <marcoceppi> bleh, thanks!
[15:01] <SimonKLB> rick_h: are you running on the public or private cloud?
[15:01] <rick_h> marcoceppi: there's a link on the charm details page as well
[15:01] <rick_h> SimonKLB: public
[15:01] <SimonKLB> also the same then
[15:01] <rick_h> SimonKLB: are you on private? I don't think the provider works on the private cloud becuase it's so different
[15:01] <SimonKLB> nope, public here as well
[15:01] <SimonKLB> this is really strange :D
[15:03] <magicaltrout> marcoceppi: is developer.juju.solutions still the place for CDP signups?
[15:03] <marcoceppi> magicaltrout: yup
[15:04] <magicaltrout> ta
[15:05] <SimonKLB> rick_h: ah, i'm actually running 2.1-beta1 if that could make any difference
[15:06] <SimonKLB> rick_h: http://paste.ubuntu.com/23563595/
[15:07] <SimonKLB> see if you can make any sense of it
[15:18] <SimonKLB> rick_h: 2.1-beta2 fixed it :)
=== frankban is now known as frankban|afk
=== scuttle|afk is now known as scuttlemonkey
=== frankban|afk is now known as frankban
=== frankban is now known as frankban|afk
[19:22] <cholcombe> lazyPower, if i'm making a subordinate that needs to access both reactive and non reactive charms is best practice to keep it non reactive for now?
[19:22] <lazyPower> cholcombe i'm not sure i understand the question. if its remote charms, it doesn't matter what its built with.
[19:23] <cholcombe> my question is i'm making a subordinate to attach to other charms like ceph, gluster, vault, etc.  some of them are old style and some of them are reactive.  icey mentioned that mixing a reactive subordinate with a non reactive charm causes problems
[19:23] <lazyPower> ah i haven't run into that. i cant see why it would cause a problem tho
[19:23] <lazyPower> just make sure you have your subordinate in a virtualenv
[19:24] <lazyPower> which can be controlled by the layer.yaml, see layer-basic's readme for that one.
[19:24] <cholcombe> the subordinate needs to access the filesystem of the parent charm
[19:24] <cholcombe> it's going to be backing up directories from the parent charm
[19:24] <lazyPower> should be fine
[19:24] <cholcombe> ok
[19:35] <magicaltrout> marcoceppi: if I rewrote the Solr Charm in reactive and pulled the lastest solr stuff, is it worth me submitting a PR to the existing charmers solr charm? or just publishing a new one?
[19:36] <magicaltrout> i'm working with the JPL/USC guys to bring a web crawler to juju but it requires a newer solr
[20:01] <kwmonroe> bbcmicrocomputer: i didn't see you here (hence the PM).  anyway, you're the current maintainer of https://jujucharms.com/solr/.  would you like magicaltrout to submit PRs to you, or push a new solr charm?
[20:01] <bbcmicrocomputer> kwmonroe, magicaltrout: I'd just push a new charm
[20:03] <kwmonroe> magicaltrout: fwiw, bigtop's solr is 4.9.0 (https://ci.bigtop.apache.org/job/Bigtop-1.1.0/BUILD_ENVIRONMENTS=ubuntu-14.04,label=docker-slave/lastSuccessfulBuild/artifact/output/solr/).  if that's recent enough, i can work with you to create a bigtop-solr charm.
[20:03] <magicaltrout> thanks chaps. No kwmonroe we need to target solr6, solrcloud etc
[20:04] <magicaltrout> i've just migrated a bunch of stuff off of 4, 4 is like the stone age ;)
[20:04] <kwmonroe> heh -- roger that magicaltrout
[20:23] <justicefries> hey all. is the OSX binary for juju building with Go 1.7 yet?
[20:41] <marcoceppi> geekgonecrazy: hey, re-mongodb, most everything is there wrt to newer versions. Just needs replicasets
[20:41] <marcoceppi> justicefries: no idea, rick_h ^
[20:41] <rick_h> justicefries: marcoceppi sorry, don't think so yet. /me goes to check what go version is available in the ubuntu OS
[20:48] <rick_h> huh, did golang move package names in recent ubuntu versions?
[20:49] <justicefries> dunno. the main reason I ask is we're still suffering a bit from the Go 1.6 MacOS Sierra issue with the juju client, and it makes it hard to distribute around our team.
[20:49] <jrwren> rick_h: not afaik.  still 1.2 everywhere.
[20:49] <justicefries> i'm working off the version I compiled.
[20:50] <jrwren> err, 1.6
[20:50]  * rick_h is on the hunt now, wtf
[20:50] <jrwren> justicefries: any reason you can't give them your juju binary and tell them to put it in ~/bin or /usr/local/bin ?
[20:50] <marcoceppi> justicefries: what's the sierra issue?
[20:50] <marcoceppi> jrwren: well we should probably fix the issue
[20:51] <rick_h> oooh, they moved to the golang-$version
[20:51] <rick_h> https://launchpad.net/ubuntu/+source/golang-1.7 and https://launchpad.net/ubuntu/+source/golang-1.6
[20:52] <rick_h> justicefries: so no, we're not using 1.7 at the moment, but looks like 1.7 is available in zesty/yakkety so something for us to consider at some point.
[20:52] <justicefries> jrwren: mostly the natural nervousness of "here, take this thing I compiled and run it. ;)". I'll probably make my own internal build CI job.
[20:52] <jrwren> yes, fix the issue. I only suggest work arounds.
[20:52] <jrwren> justicefries: its funny how folks will trust things from strangers off the internet before they trust their own coworkers. :)
[20:52] <justicefries> i know right?
[20:53] <magicaltrout> yeah but i put keyloggers in all binaries i ship to my coworkers....
[20:53] <justicefries> in reality, they trust it just fine, though I don't want them to trust it unless there's a clear source -> binary build that's automated and auditable.
[20:54] <vmorris> you're more likely to get scammed from someone you know... that's what i hear repeated all the time anyways
[20:58] <rick_h> justicefries: I'm sorry, is there a bug/note on the sierra issue?
[20:59] <rick_h> justicefries: I assume we're not on top of it because it needs go 1.7?
[20:59] <justicefries> hmm, I think there's a closed bug I saw somewhere but it hadn't been rolled out for builds.
[20:59] <lazyPower> magicaltrout - i know, and i wiresharked your traffic :|
[21:00] <justicefries> i'll have to dig it up, but basically, Go 1.7 fixes some (I think ABI?) changes for MacOS Sierra. Go 1.6 and prior has weird, unexpected failures - random panics, random networking issues, etc.
[21:00] <rick_h> justicefries: random networking issues?
[21:00] <justicefries> specifically on MacOS Sierra.
[21:00] <rick_h> justicefries: ok, if you can find that I'd love to see what's up. We'd like it to work and I'm not aware of us pressing on 1.7 so if we should be it'd be good to know.
[21:00] <justicefries> https://github.com/golang/go/issues/16579
[21:01] <justicefries> basically any binary will just unexpectedly fail. let me find the launchpad issue for Juju..
[21:02] <justicefries> juju-core encompasses everything yeah?
[21:02] <lazyPower> justicefries - i know these symptoms well. i feel them on kubectl
[21:02] <justicefries> i could've sworn there was an issue.
[21:02] <justicefries> lazyPower: how are you installing kubectl today? its fixed! unless you grab the gcloud components install version.
[21:02] <lazyPower> justicefries https://bugs.launchpad.net/juju/+bug/1633495
[21:02] <mup> Bug #1633495: Panic MacOS Sierra <osx> <juju:Fix Released by cox-katherine-e> <https://launchpad.net/bugs/1633495>
[21:02] <justicefries> brew install kubernetes-cli will give you a good version. :) I fixed that sucker.
[21:02] <justicefries> ya, that's it.
[21:02] <lazyPower> justicefries - i'm using what was shipping in brew
[21:03] <lazyPower> i haven't updated brew recently though
[21:03] <justicefries> ah yeah, do that.
[21:03] <justicefries> so yeah, that's the launchpad issue. for juju, short lived commands you just repeat.
[21:03] <justicefries> but long running ops you're guaranteed a panic just about.
[21:04] <justicefries> kat-co's fix too fixes the issue with creating controllers from MacOS which is sweet.
[21:05] <geekgonecrazy> marcoceppi: ok awesome.  Colleague is giving it a shot.  Said he ran into an error where it said "missing implementation of provides interface"
[21:06] <rick_h> justicefries: ouch! "First, doing so would give the appearance of support for Go 1.6 when in fact Go 1.6 is now unsupported." well wtf
[21:06] <marcoceppi> geekgonecrazy: yeah, you'll need my fork of the mongodb interface, https://github.com/marcoceppi/interface-mongodb
[21:06] <justicefries> rick_h: yeaaaah. :|
[21:06] <marcoceppi> geekgonecrazy: if you create an INTERFACE_PATH environment variable and clone that into it you'll get past the error
[21:07] <marcoceppi> geekgonecrazy: basically INTERFACE_PATH=$JUJU_REPOSITORY/interfaces; mkdir -p $INTERFACE_PATH; git clone https://github.com/marcoceppi/interface-mongodb $INTERFACE_PATH/mongodb
[21:07] <justicefries> rick_h: that's the Go team's weird cognitive dissonance around LTS versions, as if everybody should re-compile and re-deploy everything every 6 months, and replace all of their binaries.
[21:07] <rick_h> thanks justicefries I didn't realize it wasn't a supported release. Like someone else mentions in https://github.com/golang/go/issues/17234 it's been listed as supported
[21:07] <rick_h> but guess that fell off...
[21:07] <jrwren> justicefries: we should probably reopen 1633495. I'm adding a comment.
[21:07] <rick_h> justicefries: so this is what i mean I guess, I'll have to bring up to the release team what our plan is with 1.7 and see what we can do.
[21:08] <jrwren> i'm trying to add a comment, but LP will not let me :{
[21:08] <justicefries> yeah that makes sense. I've got a manual workaround over here for the moment, which I'll probably end up just creating my own matching CI pipeline to cut Sierra releases for us.
[21:09] <justicefries> or maybe its not worth it, and I just distribute the juju binary I've added a bunch of spyware to. ;)
[21:10] <marcoceppi> justicefries rick_h could we maybe just update the homebrew recipe to use go-1.7?
[21:11] <rick_h> marcoceppi: yea, I'll bring it up with the release team in our sync later today
[21:11] <marcoceppi> <3
=== jhobbs_ is now known as jhobbs