go test github.com/juju/juju/state takes > 10 minutes to run

2016-05-16 Thread David Cheney
Testing this package takes 16 minutes on my machine*; it sure didn't use to take this long. What happened ? * yes, you have to raise the _10 minute_ timeout to make this test run. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at:

Re: Promulgated charms (production readiness)

2016-05-16 Thread Marco Ceppi
I think a layer:nrpe isn't the right choice, but a layer:monitoring might be. Esp with the layer/interface/subordinate model now, it seems that we could actualize an abstract means to declare what to monitor and have nrpe/zabbix-agent/promethous translate that. Marco On Mon, May 16, 2016 at

Re: Promulgated charms (production readiness)

2016-05-16 Thread David Britton
On Mon, May 16, 2016 at 11:06:32AM +, Charles Butler wrote: > > If we can enable this to be a short-story for every charm author, we should > run this down and tackle it, throw money at it, and make it the best > experience for "instant monitoring" ever. I'd like to provide a bit of

Re: Promulgated charms (production readiness)

2016-05-16 Thread Cory Johns
I think this is a strong argument for creating an interface:nrpe layer to make supporting this as easy as possible. There was also discussion a long time ago about creating a translation layer of sorts for supporting multiple different monitoring solutions (like in the Puppet example). I think

Re: Promulgated charms (production readiness)

2016-05-16 Thread Tom Barber
NRPE can be related as well, this is true. Maybe I misstated it a bit, I'll blame the jetlag ;) Put it this way, if a user is implementing a to-be promulgated charm, as a minimum (for those who expose such a thing) why not ensure the port is up and listening, not just the host ping, for those who

Re: Great week for Juju in big data

2016-05-16 Thread Mark Shuttleworth
On 16/05/16 03:11, Tom Barber wrote: > In fact one guy told me, he actually believed you less because of how > compelling a keynote you gave, and how it all just seemed to work ;) Maybe > break it next time! At the European version of this conference the main question I got afterwards was "how

Re: Promulgated charms (production readiness)

2016-05-16 Thread Charles Butler
I love it when you support my arguments and I'm too dense to pick up on it Tim :D -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju

Re: incorrect private address when using manual provider

2016-05-16 Thread Andrew McDermott
Hi Matt, For the manual provider the preferred public and private addresses are taken from the initial bootstrap host address. Once set, they don't change. I'm assuming, as you mention private addresses, that a charm is getting the wrong address from `unit-get private-address'. You can force a

Re: Promulgated charms (production readiness)

2016-05-16 Thread Tim Van Steenburgh
Right, but NRPE can be related to any charm too. My point was just that the charm doesn't need to explicitly support monitoring. On Mon, May 16, 2016 at 9:35 AM, Charles Butler < charles.but...@canonical.com> wrote: > Thats only monitoring the host's ssh connection/heartbeat. If you want >

Re: Promulgated charms (production readiness)

2016-05-16 Thread Charles Butler
Thats only monitoring the host's ssh connection/heartbeat. If you want application specific monitoring, you'll need the NRPE agent or to implement it on the charm so it knows what to check. It does the bare minimum by default which i believe to be: "is the host still alive?" On Mon, May 16, 2016

Re: Promulgated charms (production readiness)

2016-05-16 Thread Tom Barber
Dunno, if you write a charm that provides service X, how would Nagios know what to monitor? -- Director Meteorite.bi - Saiku Analytics Founder Tel: +44(0)5603641316 (Thanks to the Saiku community we reached our Kickstart

Re: Promulgated charms (production readiness)

2016-05-16 Thread Tim Van Steenburgh
On Mon, May 16, 2016 at 6:44 AM, Tom Barber wrote: > I should be able to say "hey, I'm gonna install this new charm" and know > that I can hook it into our monitoring infrastructure without doing > anything too crazy. > > Isn't this already true? After seeing this

Re: Promulgated charms (production readiness)

2016-05-16 Thread Tom Barber
I agree its a bit of an ask, but that also being said, if you turned round to a sys admin and said "hey look at this tomcat charm, you can scale it to 100 nodes" and they say "how do I monitor it?" and you reply "well you can't", they'll say, "I'll use x,y,z other tool instead then thanks". First

Re: Promulgated charms (production readiness)

2016-05-16 Thread Charles Butler
> should it not be a requirement for all promulgated charms to have a monitoring endpoint A bit of a nit, but i strongly disagree with the verbiage here. This should be a best practice. Not every charm developer is going to know Nagios, and its unlikely they are going to spend the time figuring

Promulgated charms (production readiness)

2016-05-16 Thread Tom Barber
There was a chat we had over dinner at ApacheCon that I figure would be worth bringing up on the list, which was todo with what makes charms "production ready" Charms that have been signed off in the review queue are generally accepted to be of higher quality than ones that haven't(or at least

Re: Great week for Juju in big data

2016-05-16 Thread Tom Barber
Thanks for showing up Mark, I know from chatting to various people who hadn't come into contact with Juju before they were certainly impressed and we have a few other projects interested in coming onboard which I'll be working with over the next few weeks to try and facilitate. In fact one guy