[00:08] <bdx> Are there any plans for an official trove charm?
[00:11] <bdx> :jamespage - I would like to know if there are future plans for a trove charm? If not, I would like to request an official trove charm....I am willing to help out in anyway possible.
[02:06] <lazyPower> marcoceppi_: i just had a thought - and it might be completely ludacris.. but what if we had a pattern as follows
[02:06] <marcoceppi_> lazyPower: go on
[02:07] <lazyPower> if we deploy a charm that requires a build environment to assemble itself from code (in teh instance of flannel for docker) - what if it added container on the host, fetched the build env + source code, ran the buidl routine, and then the artifacts were pulled from the container, and the container destroyed leaving only a job log of the build process - to prevent polluting the host with the build tools
[02:08] <lazyPower> i could get arm64/ppc64el/x86 artifacts in the host (assuming it has net access) - and not leave build tools on the machine.. it does add some layers for failure in there.. but i think it has interesting possibilities.
[02:08] <lazyPower> (and those arch targets are respective to what environment i'm deploying to - as this is a golang bin artifact thats produced)
[02:08] <marcoceppi_> lazyPower: how quickly could you create a container?
[02:09] <marcoceppi_> seems like a good idea, but only if you could prevent having to spin up a build container for each unit
[02:09] <lazyPower> Depends, am i fetching a bin image from dockerhub or am i fetching a cloud image and using LXC
[02:09] <lazyPower> I was considering shipping a dockerfile with a base ubuntu 14.04 image to run the trial on this
[02:10] <lazyPower> as flannel-docker wont be deployed to a non-docker host. that much is specific in the relationship
[02:10] <lazyPower> i mean, you can co-lo it on one, but it noops
[02:14] <lazyPower> I'll run this by whit and mbruzek tomorrow to see if they think its interesting enough to devote a couple hours to prototyping the process.  Thanks for being a sounding board
[03:50] <marcoceppi_> lazyPower: you still around?
[08:07] <jamespage> bdx, no plans for a trove charm from my team
[14:02] <lazyPower> marcoceppi_: back now
[15:52] <lazyPower> tvansteenburgh: there's a thread going on the list right now about makefile targets that i think you had cautioned me about before wrt bundletester behavior and running integration tests multiple times
[15:52] <lazyPower> tvansteenburgh: might want to poke your head in and take a look and give a quick reply on behavior here. Thread name is: Makefile target names
[15:57] <tvansteenburgh> lazyPower: yeah that was started at my suggestion :) i'll comment, just wanted to see others' ideas
[16:05] <jamespage> gnuoy`, pushed rabbitmq charm up for next branch and merged wolsen's changes
[16:05] <gnuoy`> jamespage, tip top, thanks
[16:27] <wolsen> thanks jamespage
[16:35] <jamespage> marcoceppi_, hey around?
[16:35] <marcoceppi_> jamespage: o/
[16:36] <jamespage> marcoceppi_, sooooo
[16:36] <jamespage> mysql charm
[16:37] <jamespage> marcoceppi_, how would you feel about putting that under the three month release cycle alongside the openstack charms?
[16:37] <marcoceppi_> jamespage: Sounds like a great idea
[16:37] <jamespage> I want todo the same with rabbitmq and percona-cluster as well - but I feel os-charmers already has quite a bit of ownership their
[16:38] <jamespage> marcoceppi_, OK so we are about to finish up a cycle - 15.01 release is out next week - I suggest that we create the next branch then and switch all merges to the next branch for the 15.04 release
[16:39] <marcoceppi_> jamespage: sounds good, if it makes iterating quicker, next branch should live under os-charmers
[16:39] <marcoceppi_> jamespage: then just perform merges to ~charmers branch per typical?
[16:42] <jamespage> marcoceppi_, that sounds good to me
[16:43] <jamespage> marcoceppi_, we need a good way to signal to contributors where they should propose merges against - I'd like that to be the next branch
[16:43] <jamespage> marcoceppi_, I thought maybe  a README.dev or HACKING.md
[16:43] <marcoceppi_> jamespage: either sounds fine, README probably has the most exposure
[16:44] <jamespage> marcoceppi_, OK - sounds good to me
[16:44] <marcoceppi_> jamespage: how does this problem handle patches for bugs to released version?
[16:44] <marcoceppi_> should they still land in /next ?
[16:44] <marcoceppi_> s/problem/process/
[16:45] <jamespage> marcoceppi_, next first and then cherry pick to the stable branch
[16:45] <jamespage> so that we don't regress on the next release of next
[16:46] <marcoceppi_> jamespage: okay, lmk when you've got that setup, we should mail the list on this change so it's documented and reviewers know what's up
[16:46] <jamespage> marcoceppi_, ack will do
[17:31] <lazyPower> tvansteenburgh: on the subject of bundletester, do you have a second to help me debug some weirdness? its failing on a charm for no lint target, yet the makefile has one implicitly
[17:32] <lazyPower> http://paste.ubuntu.com/9822358/ <-- traceback
[17:32] <tvansteenburgh> lazyPower: looking
[17:32] <lazyPower> http://paste.ubuntu.com/9822371/
[17:32] <lazyPower> makefile for flannel-docker
[17:33] <tvansteenburgh> lazyPower: does `make lint` succeed on its own?
[17:33] <lazyPower> sure does
[17:34] <lazyPower> http://paste.ubuntu.com/9822406/
[17:34] <tvansteenburgh> what about `make -s lint`
[17:35] <lazyPower> same output
[17:36] <lazyPower> tvansteenburgh: i think i see the problem, i have a sudo apt-get install python-virtualenv in the venv target, and i bet its hanging on that sudo and failing the test
[17:42] <tvansteenburgh> lazyPower: i see it's bundle, i wonder if the cwd is wrong at the time lint is called
[17:42] <lazyPower> possible, is there a debug trace i can spit out that would be helpful?
[17:43] <tvansteenburgh> -l DEBUG -v
[17:43] <lazyPower> already doing that :(
[17:43] <tvansteenburgh> yeah figured
[17:44] <lazyPower> I'll circle back to this - right now i'm interested in making sure the tests i have in the bundle are passing. Its going to fail in CI though with this. its a consistent result when running bundletester
[17:45] <tvansteenburgh> lazyPower: i'm occupied at the moment but will take a look as soon as i can
[17:45] <lazyPower> np, just a heads up really :)
[17:45] <lazyPower> cheers
[17:45] <tvansteenburgh> cheers man
[22:33] <lazyPower> whit: https://bugs.launchpad.net/charms/+bug/1413775
[22:33] <mup> Bug #1413775: New Charm - Docker <Juju Charms Collection:New> <https://launchpad.net/bugs/1413775>
[22:33] <whit> lazyPower, w00t
[22:36] <lazyPower> whit: ready for number 2?   https://bugs.launchpad.net/charms/+bug/1413776
[22:36] <mup> Bug #1413776: New Charm: flannel-docker <Juju Charms Collection:New> <https://launchpad.net/bugs/1413776>
[22:36] <whit> :D
[22:40] <lazyPower> The final keystone to those charms: https://bugs.launchpad.net/charms/+bug/1413779
[22:40] <mup> Bug #1413779: New Bundle: docker-core <Juju Charms Collection:New> <https://launchpad.net/bugs/1413779>