[01:02] <lazyPower> x58 - yeah you're finding some rough edges with charmhelpers vs reactive
[01:03] <lazyPower> really sorry about that too :( We've been moving kind of fast, and its left a trail in the tooling that we haven't been able to circle back and get either updated, or deprecated, just yet.
[07:51] <kjackal> hello juju world
[08:47] <gnuoy> hey stub, I see that https://code.launchpad.net/~stub/charms/trusty/nrpe/py3/+merge/300153 has a prereq branch which isn't proposed yet. Is that an oversight? I assume that the normal workflow here is to merge the prereq branch then this one.
[10:35] <neiljerram> Morning
[10:36] <neiljerram> Does anyone happen to know if I can control the names of the machines that Juju creates when I ask it to deploy a bundle?
[10:37] <neiljerram> In other words, I'd prefer something more meaningful than 'juju-466b6192-d900-4e7a-8fa4-e3935e5c25f5-machine-0' or 'juju-26a5f7-0'
[13:39] <bryan_att> gnuoy: ping
[13:40] <bryan_att> any charm experts here that can help with a layer question?
[13:41] <marcoceppi>  bryan_att ask away
[13:42] <bryan_att> marcoceppi: I have an issue where a value is not getting set in one of the config templates. It seems that the "layer"  is not passing the right value, or the value name changed. How do I debug this?
[13:43] <marcoceppi> bryan_att: is this a layer.yaml option or a config.yaml option?
[13:43] <bryan_att> https://github.com/blsaws/charm-congress - see https://github.com/blsaws/charm-congress/blob/master/src/templates/liberty/congress.conf
[13:43] <bryan_att> the value "connection = {{ shared_db.uri }}" is not getting set
[13:44] <bryan_att> this comes from I think includes: ['layer:openstack-api'] in https://github.com/blsaws/charm-congress/blob/master/src/layer.yaml
[13:44] <bryan_att> But I don't know how to check this "layer" to see if the variable has changed somehow.
[13:46] <bryan_att> I further need to document this dependency (if the root of my current build/deploy issue) if it can result in CI/CD failure - so I need to know what is the root issue here and how to debug such (potential) issues with layers
[13:46] <marcoceppi> bryan_att: ah, so shared_db.uri comes from the mysql-shared interface layer
[13:48] <marcoceppi> bryan_att: the openstack-api layer pulls in interface:mysql-shared: https://github.com/openstack/charm-layer-openstack-api/blob/master/layer.yaml
[13:49] <marcoceppi> bryan_att: I don't see a .uri key for that library though
[13:50] <bryan_att> marcoceppi: sorry, I don't know what a .uri key is, and can't see from the file what is being referenced (or at least where to find the real code)
[13:51] <marcoceppi> bryan_att: sorry, is shared_db.uri a key in your template or a key in the openstack-api template?
[13:51] <bryan_att> I don
[13:51] <bryan_att> I don't know
[13:51] <jamespage> bryan_att, hey - can you join #openstack-charms please
[13:52] <bryan_att> sure
[15:29] <acovrig> I get this error running conjure-up openstack: cannot find network interface "lxdbr0": route ip+net: no such network interfaceERROR invalid config: route ip+net: no such network interface
[15:29] <stokachu> acovrig: try running lxd init
[15:31] <acovrig> stokachu: still get the error...
[15:31] <acovrig> and I don’t see lxdbr0 in ifconfig
[15:31] <stokachu> acovrig: ugh, such a pain point for users
[15:32] <acovrig> stokachu: what if I install docker first?
[15:32] <stokachu> acovrig: that has nothing to do with lxd
[15:33] <stokachu> acovrig: sec
[15:33] <acovrig> yea, but wasn’t sure if it would configure the if, but I guess it uses docker0 so I guess not
[15:33] <stokachu> acovrig: what does, sudo ifup lxdbr0 do?
[15:33] <acovrig> stokachu: Unknown interface lxdbr0
[15:33] <stokachu> acovrig: that bridge is socket activated so something has to touch it to turn on
[15:34] <stokachu> stub: one sec
[15:34] <stokachu> acovrig: one sec
[15:34] <stokachu> stub: disregard
[15:35] <stokachu> acovrig: try running 'lxc list' as a normal user
[15:35] <stokachu> see if that activates the bridge
[15:36] <acovrig> stokachu: it doesn’t show anyting in the list, would a reboot help?
[15:36] <lazyPower> stokachu - wasn't there a bit where if you had lxc prior, you had to dpkg-reconfigure to get the proper bridge?
[15:36] <stokachu> acovrig: now what does `ifconfig` show
[15:36] <stokachu> lazyPower: yea we do that for them but sometimes it doesn't active the new bridge :(
[15:36] <lazyPower> :|
[15:36] <acovrig> stokachu: 2 physical, lo, and openstack0
[15:37] <stokachu> acovrig: :((((
[15:37]  * stokachu sad
[15:37] <stokachu> acovrig: ok give me another second
[15:38] <stokachu> acovrig: for kicks try running `conjure-up openstack` again
[15:38] <stokachu> acovrig: what about `ifconfig -a`
[15:39] <acovrig> stokachu: same as ifconfig; should I pick OpenStack or OpenStack with Nova-LXD?
[15:39] <stokachu> acovrig: if youre doing it on a single machine go with novalxd
[15:39] <acovrig> stokachu: intend to run on a cluster of 3 machines (once I get an update to fix a bug in maas)
[15:40] <stokachu> acovrig: the other openstack spell requires i think 4-5 machines
[15:40] <acovrig> stokachu: same error… (cannot find network interface "lxdbr0")
[15:41] <stokachu> acovrig: bah
[15:41]  * acovrig sudo reboot pending
[15:41] <stokachu> acovrig: yea try that :|
[15:47] <acovrig> stokachu: ifconfig shows lxdbr0, running conjure now
[15:47] <stokachu> acovrig: yay
[15:47] <stokachu> acovrig: it shouldn't be this difficult to start that bridge
[15:48] <stokachu> we may try to handle it better in conjure-up
[15:48] <stokachu> acovrig: are you running the pre-release?
[15:48] <acovrig> lol, yea; also, when installing it added me to the lxd group, but I had to logout and back in to get it to accept that, I wonder if I should have rebooted then
[15:48] <acovrig> stokachu: I’m running ubuntu 16.04
[15:48] <stokachu> acovrig: yea or log completely out
[15:49] <stokachu> acovrig: what does dpkg -l conjure-up show
[15:49] <acovrig> stokachu: 0.1.2 and juju 2.0~beta7-0ubuntu1.16.04.1
[15:49] <acovrig> still bootstrapping
[15:49] <stokachu> acovrig: ok, do you want to test the latest stuff?
[15:50] <stokachu> acovrig: if you're curious https://www.irccloud.com/pastebin/91OmlH1S/
[15:53] <acovrig> stokachu: I presume that last line should be “conjure-up openstack” instead of “conjure-up openstack|”
[15:53] <stokachu> yea sorry
[15:55] <acovrig> I may look at it myself, I’m currenlty setting this up at work to compare an openstack cluster w/an windows hyper-v cluster so I may set it up at the servers at my house to tinker w/it.
[15:56] <acovrig> stokachu: this looks promising, it’s deploying 17 services and is ~1/2 done
[15:56] <stokachu> acovrig: cool, should be good to go
[15:56] <acovrig> stokachu: yup, now if I can get a bug fixed in maas, I’d scale this out across 3 machines lol
[15:57] <stokachu> :D
[15:57] <stokachu> what bug in maas?
[15:57] <acovrig> stokachu: https://bugs.launchpad.net/maas/+bug/1604128
[15:57] <mup> Bug #1604128: [2.0RC2] Unable to add a public SSH Key due to lp1604147 <cdoqa-blocker> <verification-done> <MAAS:Fix Committed by allenap> <MAAS 2.0:Fix Committed> <MAAS trunk:Fix
[15:57] <mup> Committed by allenap> <maas (Ubuntu):Fix Released> <maas (Ubuntu Xenial):Fix Released> <maas (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1604128>
[15:58] <stokachu> ah ok rc2
[15:58] <stokachu> shouldnt be long for that
[15:58] <acovrig> stokachu: yea, I’m talking to someone on #maas and they said it’s fixed in -updates, I apt upgrade’d and got 2.0.0~rc2+bzr5156-0ubuntu2~16.04.2, but it still isn’t letting me put a key in...
[15:59] <stokachu> hmm
[16:00] <acovrig> yea, and I think they’re AFK (~1hr)
[16:00] <stokachu> acovrig: is this just putting the key in the UI
[16:00] <stokachu> copy and pasting?
[16:03] <acovrig> stokachu: yup
[16:03] <stokachu> acovrig: that is weird
[16:03] <acovrig> a differnet install (VM) (I think it was the same version) accepted this key
[16:55] <acovrig> lol, was about to ask how long I should expect this to take (conjure-up openstack), but then I looked at top…44% iowait, 12% idle… *sigh* slow hardware...
[16:58] <geetha> Hi, My IBM WAS Base charm needs 2 fixpack packages, when fixpack already installed and user wants to upgarde using latest fixpack packages, I have written code like this : http://paste.ubuntu.com/20056926/. But when I run juju attach command for latest fixpacks, upgrade_charm hook will be triggered and comparing checksum values for existing fixpack packages and new fixpack packages. Here 2nd packges is not getting updated with the lates
[17:00] <geetha> when I try to verify checksum , for second package it's showing same checksum value for old and new fixpack package
[17:01] <stokachu> acovrig: yea it takes a toll on the hardware for a single install
[17:01] <stokachu> acovrig: we usually recommend at least 16G ram for that spell
[17:01] <geetha> could any one please suggest me how to check whether the packages are old or new in multiple package scenario
[17:01] <acovrig> stokachu: lol, yea I have exactly 16
[17:01] <stokachu> acovrig: ok yea, should take about 45 minutes
[17:04] <acovrig> stokachu: yea, it’s been going for ~1.25hr, it’s done with 9/18, 8 installing apt packages, 1 incomplete relations: identity
[17:06] <stokachu> acovrig: ok
[17:06] <stokachu> acovrig: if it takes that long i would kill it and try the latest from our ppa
[17:06] <stokachu> update juju to beta12 as well
[17:07] <stokachu> tons of fixes
[17:07] <acovrig> stokachu: “our ppa” being “ppa:juju/devel” and “ppa:conjure-up/next”?
[17:07] <stokachu> acovrig: yea
[17:08] <acovrig> stokachu: apt purge juju conjure-up && apt install juju conjure-up or just upgrade? (I.E. will there be any broken leftovers if I ^c the current conjure process)
[17:09] <stokachu> shouldn't be any leftovers if you ^c
[17:09] <stokachu> acovrig: your first one would work
[17:09] <stokachu> or apt dist-upgrade
[17:10] <acovrig> stokachu: apt upgrade? wouldn’t dist-upgrade upgrade my distribution of ubuntu?
[17:10] <x58> Any guides on publishing stuff to the charm store?
[17:11] <magicaltrout> https://insights.ubuntu.com/2016/04/16/charm-charm-tools-2-0/
[17:11] <magicaltrout> the docks currently are a bit lousy because it changes
[17:12] <magicaltrout> d
[17:12] <magicaltrout> you need to charm push
[17:12] <magicaltrout> charm publish
[17:12] <magicaltrout> charm grant
[17:12] <magicaltrout> the help on the cli is pretty useful
[17:15] <x58> I'm logged into the charmstore and there is a button that says "create new" but clicking it does all of nothing.
[17:16] <magicaltrout> dunno what that is
[17:16] <magicaltrout> on the command line
[17:16] <magicaltrout> charm login
[17:16] <magicaltrout> then you can interact with the CS from the cli
[17:16] <magicaltrout> and push your stuff
[17:16] <x58> Found some docs, will follow, will report back if I fail.
[17:16] <magicaltrout> you don't need to setup anything on the web
[17:19] <x58> https://jujucharms.com/docs/devel/authors-charm-store
[17:19] <x58> This tells me I need to login to the charm store in my browser.
[17:19] <magicaltrout> yeah
[17:19] <magicaltrout> but then login on the CLI
[17:20] <magicaltrout> oh yeah they were the docs I was grepping for
[17:29] <x58> Published my first charm =)
[17:29] <x58> https://jujucharms.com/u/bertjwregeer/staticroutes
[17:30] <x58> I read the docs, and the README could be a rst file, yet it is not being rendered correctly :-(
[17:30] <magicaltrout> woop
[17:30] <magicaltrout> change rst to md
[17:30] <magicaltrout> ignore the lies!
[17:31] <x58> I'm a python dev... rst is my life.
[17:31] <magicaltrout> sad times!
[17:32] <magicaltrout> better than this crazy go stuff :)
[17:33] <x58> configuration also loses my formatting (specifically newlines that make it readeable and understandable :-()
[17:34] <magicaltrout> okay 2 things a) not sure https://jujucharms.com/u/spicule/pentahodataintegration/trusty/8 thats one of mine, the formatting is acceptable
[17:34] <magicaltrout> b) you've not granted public read writes
[17:34] <magicaltrout> so I can't see it and have no clue :)
[17:35] <x58> How do i grant it?
[17:35] <x58> I can see it, clearly I am the most important person ;-)
[17:36] <magicaltrout> charm grant cs:~spicule/wily/dcos-master --acl=read everyone
[17:36] <x58> magicaltrout: done.
[17:37] <x58> charm grant cs:~bertjwregeer/staticroutes everyone (from the docs)
[17:38] <magicaltrout> yeah
[17:38] <magicaltrout> not sure how rst works
[17:38] <magicaltrout> but for blocks
[17:38] <magicaltrout> just indent 4
[17:38] <magicaltrout> and headings use #, ##
[17:38] <magicaltrout> usual markdown stuff
[17:39] <x58> Yeah, that's markdown... rst has headings, so ------- underneath a line is a top-level, heading <h1>, ~~~~~~ underneath a ------- heading is a <h2>
[17:39] <x58> .. code:: is valid rst.
[17:39] <magicaltrout> yeah, but rst has never rendered for me on the charms store
[17:39] <x58> See rendering here: https://gitlab.com/bertjwregeer/juju_staticroutes
[17:39] <x58> Ah
[17:39] <magicaltrout> so unless you're magic, it'll be broke :)
[17:39] <x58> That's a different story. I followed docs. Docs said md or rst.
[17:39] <magicaltrout> yeah i have no clue
[17:40] <magicaltrout> the samepl charm is .rst file
[17:40] <magicaltrout> but it never formats when its deployed
[17:40] <x58> Where can I file bugs against the charmstore?
[17:40] <magicaltrout> https://github.com/juju/charmstore
[17:40] <magicaltrout> probably
[17:40] <lazyPower> https://github.com/CanonicalLtd/jujucharms.com/issues
[17:41] <magicaltrout> i lied
[17:41] <lazyPower> x58 - link is in the footer of the page :)
[17:41] <magicaltrout> there be no bugs
[17:41] <magicaltrout> its written by professionals
[17:41] <jrwren> where do docs say RST? that is incorrect and has never been supported AFAIK.
[17:42] <lazyPower> jrwren - RST was a supported format back in the juju 1.x days, in the old store. Kapil made heavy use of RST
[17:42] <magicaltrout> jrwren: the charm template creates you a RST
[17:42] <magicaltrout> or it did last time i tried
[17:42]  * jrwren is disappointed.
[17:46] <x58> Well I just filed two bugs in the wrong place :P
[17:47] <magicaltrout> lol
[17:47] <x58> https://jujucharms.com/docs/devel/authors-charm-policy#readme.md
[17:47] <x58> that is where .rst is mentioned.
[17:49] <magicaltrout> lies all round
[17:50] <magicaltrout> chatting with Bill on Thursday lazyPower, got most of my PDI charm done.. and then I get sidetracked writing a maven plugign for snappy *boom*
[17:50] <magicaltrout> I really need to stop doing new stuff
[17:50] <lazyPower> Whats the fun in that?
[17:50] <magicaltrout> hopefully still get DC/OS polished off this week
[17:51] <x58> People tend to complain when people DON'T read docs, and now I read the docs and it's wrong...
[17:51] <x58> That just hurts.
[17:51] <lazyPower> x58 we apologize, and will take steps to address the bug
[17:51] <magicaltrout> blame it on evilnickveitch
[17:51]  * magicaltrout runs for the hills
[17:52] <magicaltrout> lazyPower: well there is no fun in that, but apparantly no one had thought of adding snapcraft to existing build chains
[17:52] <magicaltrout> which seems rather weird
[17:52] <magicaltrout> so i'm taking some steps to address that
[17:52] <lazyPower> :D
[17:52] <lazyPower> thats phenomenal
[17:53] <magicaltrout> well if you have a build setup like a big maven multi module project or something, why would you replace that with a snapcraft maven weird thing?
[17:53] <magicaltrout> especially if you've got CI, reporting etc
[17:53] <magicaltrout> and I'm sure its not just me in java world
[17:53] <magicaltrout> but it seems reasonable to build artifacts then programatically create a snap definition to create your image post build
[17:54] <magicaltrout> a bit like with juju where you might want to replace specific bits of infrastructure but not replace all your nicely crafted puppet scripts or  cookbooks
[18:02] <x58> lazyPower: I
[18:02] <x58> lazyPower: lol. I've filed bugs :-)
[18:02] <lazyPower> x58 thank you, sincerely :) i appreciate the effort
[18:02] <x58> lazyPower: I maintain WebOb (python request/response library) and work heavily with the Pylons project on Pyramid. I understand that docs can be out of date or wrong. No-one likes writing docs.
[18:02] <magicaltrout> see the funny thing is if i said a sentence like that i'd be taking the piss
[18:03] <magicaltrout> lazyPower is being honest though I think
[18:03] <x58> magicaltrout: haha
[18:04] <magicaltrout> x58: where you based?
[18:05] <lazyPower> i am :) I have no idea how many users come by and dont file bugs when we're just plain wrong on something
[18:05] <lazyPower> to see someone take a couple minutes and file a bug, which makes us better makes me happy
[18:06] <magicaltrout> see there's the american sincerity shining through
[18:06] <magicaltrout> you don't get that in the uk ;)
[18:06] <magicaltrout> we might think it, we just don't articulate it in that manner ;)
[18:07] <lazyPower> magicaltrout - i appreciate you too sir
[18:07] <lazyPower> :D
[18:07] <magicaltrout> lol
[18:07] <magicaltrout> *cringe*
[18:23] <x58> magicaltrout: Denver, CO. Currently got a mattrae sitting next to me working on our production deployment.
[18:23] <x58> magicaltrout: I am from The Netherlands though. So we like to tell people how it is, Dutch Directness.
[18:24] <magicaltrout> hehe
[18:24] <magicaltrout> maybe but the dutch isn't as scary as german
[18:24] <magicaltrout> s/isn't/aren't
[18:24] <x58> Germans are scary because their language always sounds angry. Even when expressing love.
[18:24] <x58> We Dutch have toned down that "anger" in our language.
[18:25] <magicaltrout> yeah i'm sat in a bar now, and every 10 minutes the woman walks past and shouts "1 more?" at me
[18:25] <magicaltrout> i feel like i should say yes everytime
[18:26] <x58> magicaltrout: Where do you work? Found an email address on one of your charms and the bare naked domain takes me to an ESXi welcome screen :P
[18:27] <magicaltrout> does that still happen?
[18:27] <x58> analytical-labs.com
[18:27] <magicaltrout> I don't even know who owns that box :)
[18:28] <magicaltrout> i'm part self employed data guy based in London, part NASA JPL data scientist based in Pasadena and part time Juju/Snappy hacker
[18:31] <magicaltrout> did apachecon in denver a few years ago, jesus christ, i'm never drinking in denver again
[18:35] <x58> magicaltrout: Welcome to alttitude.
[18:35] <x58> Learn to drink up here, and you can drink like a fish at sea level.
[18:35] <magicaltrout> lol
[18:35] <magicaltrout> i'm sure
[18:36] <magicaltrout> the only place i've switched on a satnav in a hotel basement parking lot and it warns me I should get lower
[18:36] <x58> I don't drink anymore, but in Denver I could put away a fair bit. Ended up in Vegas for DEF CON... let's just say I spent a lot of money.
[18:36] <magicaltrout> hehe
[19:14] <petevg> cory_fu: I'm chewing on a thing with the interaction between puppet and juju in the Bigtop charms.
[19:15] <petevg> The idea behind puppet is that it should be safe to run arbitrarily on a running system. It will reset config files that you've manually modified, but that's expected -- you're supposed to change the puppet config if you want stuff to change.
[19:16] <petevg> So the question is: I have a config value that I may want to set at deploy, or may want to change while my server is running.
[19:17] <petevg> What's the best practice for handling that situation?
[19:18] <petevg> Basically, I want to wind up in a situation where I can do juju upgrade, and have the value stay set.
[19:19] <petevg> cory_fu: you mentioned having a juju action manually update the juju config on the host machine. Do I have to worry about updating the config locally, too? Or will juju respect the config on the host if it's re-run?
[19:21] <cory_fu> petevg: I did not mention having an action update config.  I mentioned having a config option update the config.  ;)  But yes, the puppet scripts ought not wipe out any data but c0s suggested that they might (for HDFS, at least).  If they do, the most correct (if perhaps not the most expedient) solution would be to fix the Bigtop puppet scripts
[19:21] <cory_fu> For the case of Kakfa, it seems unlikely that the scripts will wipe out any data, but it's worth verifying
[19:23] <petevg> cory_fu: Got it. So the charming way to do things would be to update your config and re-run juju deploy, but there may be broken behavior in Bigtop. I'll try to test for it. Thx.
[19:23] <cory_fu> petevg: I assume you mean re-run puppet apply?
[19:24] <petevg> cory_fu: no, I didn't. But that's why I typed it -- I wanted to make sure that I wasn't walking away with wrong things to do :-)
[19:25] <petevg> What I'm intending to do is to have a layer option that sets the "bind" address for kafka.
[19:25] <petevg> If I want to change that, I can update the layer option, but then what command do I want to run to tell juju to update the config on the host?
[19:26] <petevg> *sets should be "specifies"
[19:26] <cory_fu> petevg: No, no.  Not a layer option, a config option.  Those can be changed after deployment (and on a per-deployment basis), while layer options cannot
[19:27] <petevg> cory_fu: got it. So I do juju deploy --config <some config>.yaml kafka
[19:27] <petevg> ... and then later, I change my mind about the config. What do I run to update it?
[19:28] <stokachu> cory_fu: just making sure you saw some PR's i created https://github.com/juju-solutions/bundle-apache-processing-mapreduce/pulls
[19:29] <cory_fu> petevg: juju set-config listener=0.0.0.0
[19:29] <cory_fu> petevg: juju set-config kafka listener=0.0.0.0
[19:29] <petevg> cory_fu: Ah, cool. And then we call the config-changed handler, which I believe runs puppet, and all is good.
[19:29] <petevg> Cool. Thank you :-)
[19:30] <cory_fu> stokachu: Yeah, sorry, I saw it.  It seems fine to me, but I'm still a bit unclear about the drive behind conjure.  Also, we're deprecating that bundle in favor of hadoop-processing, which lives in Apache Bigtop
[19:31] <stokachu> cory_fu: if you run the instructions in the PR it'll give you a better idea
[19:32] <stokachu> is apache bigtop a different repo?
[19:33] <stokachu> cory_fu: im guessing this is it https://github.com/juju-solutions/bigtop/tree/master/bigtop-packages/src/charm
[19:33] <stokachu> cory_fu: and what hoops do i have to jump through to make contributions?
[19:35] <petevg> stokachu: juju-solutions/bigtop our fork apache/bigtop. You can make and push branches off of it, but you want to make your pull requests against apache/bigtop. (github will do that by default).
[19:35] <petevg> As for hoops, there are a few more :-)
[19:35] <magicaltrout> will you get sucked up into apache/bigtop without an ICLA etc signed?
[19:36] <petevg> No.
[19:36] <stokachu> i just care about the charms, is opening a PR against that repo enough?
[19:36] <petevg> Hang on. Typing up an explanation :-)
[19:37] <petevg> Basically, the Bigtop folks will be happiest if you first file a ticket in their Jira: https://issues.apache.org/jira/browse/BIGTOP/
[19:37] <petevg> Then when you create your PR, you want it to have a title exactly in the following format:
[19:38] <petevg> BIGTOP-<ticket number> <Ticket Title>
[19:38] <petevg> ... where <ticket number> is the four digit (so far) ticket number, and the title is the same string as you put in the title of your ticket.
[19:39] <petevg> That way, the PR will get slurped up automatically into the Jira issue, and people will be able to find it easily.
[19:39] <stokachu> ok
[19:39] <magicaltrout> just caring about charms makes the apache software foundation sad.....
[19:39] <magicaltrout> ;)
[19:40] <petevg> They actually seem to be pretty happy about charms ... so long as we play nicely with their Jira automagic github integration thing :-)
[19:41] <cory_fu> stokachu: Also, even though new dev is focused on Bigtop, the vanilla Apache bundle isn't going to go away, so we can accept the PR into that in the meantime
[19:41] <magicaltrout> petevg: i can speak as an insider its pretty important else you just end up with a bunch of unclosable pull requests
[19:41] <magicaltrout> and its a right pain in the balls
[19:42] <stokachu> so just to clarify, a new contributor will need to first learn charm development with the reactive layer, then try to figure out where the charms live under different projects and learn their submission process?
[19:42] <stokachu> obviously the charmstore doesn't show this information
[19:42] <magicaltrout> well there is talk of making charms live with their parent projects
[19:42] <magicaltrout> with the new push mech
[19:42] <petevg> stokachu: when you put it that way ... :-/
[19:42] <magicaltrout> doubt that flies with cory_fu
[19:42] <stokachu> right, where do you go to find all this out?
[19:43] <magicaltrout> but you know, technically the charms could live in the BigTop
[19:43] <stokachu> right now im going to 3 different places to figure out how to make a contribution to a charm
[19:43] <magicaltrout> well if you found the source, and they live with their projects, you're in the right place?
[19:43] <stokachu> https://jujucharms.com/apache-processing-mapreduce/
[19:43] <stokachu> thats not the source of bigtop which seems to be where development is heading, right?
[19:43] <magicaltrout> yeah, it is true, but its also legacy
[19:44] <magicaltrout> this stuff will iron itself out over time
[19:44] <stokachu> how do i know that
[19:44] <magicaltrout> well you don't
[19:44] <stokachu> :\
[19:44] <magicaltrout> but
[19:44] <magicaltrout> since the new charm push/charm publish stuff is available now
[19:44] <magicaltrout> it makes charms in their respective projects much easier
[19:45] <stokachu> just b/c you dont have to push to launchpad first before it gets in the charmstore doesn't make discovery easier
[19:45] <stokachu> for people who want to contribute
[19:45] <petevg> stokachu: I'm definitely paying attention and thinking about it ...
[19:45] <magicaltrout> no, but if you go to a charm, it will give you a like to the source (doesn't it?)
[19:45] <stokachu> https://jujucharms.com/apache-processing-mapreduce/
[19:45] <stokachu> is that the same source as bigtop??
[19:45] <petevg> Putting stuff in the bigtop repo is meant to centralize the big data charms and make them easier to find.
[19:45] <magicaltrout> oooh
[19:45] <petevg> But you are having to deal with two separate communities, which is a little tricky.
[19:46] <magicaltrout> jujucharms directs me to LP
[19:46] <stokachu> so you have 2 big barries, getting people to learn charm layers, then having them go through a potential new process everytime they want to submit something
[19:46] <stokachu> barriers*
[19:46] <magicaltrout> okay thats a bit shit
[19:46] <magicaltrout> the charm layer contains a repo path
[19:46] <magicaltrout> (i may just have not filled mine in)
[19:47] <magicaltrout> it should direct you to the source
[19:47] <magicaltrout> and if you manage the source of the charm with the source of the project then thats fine
[19:50] <stokachu> petevg: a start would be to update the README in the toplevel dir about how to contribute a charm
[19:50] <petevg> stokachu: That's an excellent idea.
[19:51] <petevg> I'm also going to badger the big data team about updating our metadata so that there's always a link to click to view source from the charm store.
[19:51] <stokachu> petevg: ok thanks
[19:51] <petevg> No problem. Thank you for the feedback!
[19:52] <stokachu> petevg: the readme could be as simple as what you told me here on irc
[19:52] <stokachu> cory_fu: ok, give that PR a test run and let me know if you have questions
[19:52] <stokachu> cory_fu: once you run it once it'll give you a good idea what conjure-up does
[19:55] <magicaltrout> on a more useful note... i ask my colleagues if my diet of beer and hotel peanuts will kill me
[19:55] <magicaltrout> http://www.ncbi.nlm.nih.gov/pubmed/12119580
[19:55] <magicaltrout> i got sent that as a response
[20:00] <petevg> it sounds like the paper says eat as many peanuts as you want: you won't even get tired of them. I approve of these findings :-)
[20:01] <magicaltrout> hehe
[20:01] <magicaltrout> i'm working on an authentic conclusion
[20:04] <lazyPower> "The effects of hotel peanuts and beer on magicaltrout over a decade, as computed by apache-realtime-streaming"
[20:04] <lazyPower> "and visualized with zepplin"
[20:05] <magicaltrout> i think it would likely show a sharp decline in something
[20:05] <magicaltrout> productivity probably
[20:06] <magicaltrout> that said, i've been sat here doing nothing whilst waiting on infra for about 3 hours
[20:06] <magicaltrout> luckily
[20:06] <magicaltrout> i'm paid by the hour
[20:06] <lazyPower> or, you consistently reach the ballmer peak and you gain superhuman coding powers for 4 hours a day, and manage to charm all the things, thus rendering the rest of us puny mortals insignificant in your charming wake
[20:06] <lazyPower> clearly i've thought about this...
[20:06] <magicaltrout> well... yesterday i tested my pdi <-> hdfs tweaks to the charm
[20:07] <magicaltrout> and they worked first time
[20:07] <lazyPower> banking on unnatural phenomenon
[20:07] <magicaltrout> so maybe you have a point
[20:07] <lazyPower> see?
[20:07] <lazyPower> may the lesson be:  feed magicaltrout more beer
[20:07] <lazyPower> and hotel peanuts*
[20:07] <magicaltrout> oh i can vouch for the beer part
[20:07] <magicaltrout> I did all my coding at uni whilst drunk and that was one of the few modules i passed with a 1st
[20:08] <magicaltrout> and lets face it, i work a lot for NASA in the evenings.....
[20:08] <lazyPower> anecdotal evidence is still evidence right?
[20:08] <magicaltrout> indeed
[20:08] <magicaltrout> of the highest order