Re: Promulgated charms (production readiness)

[Simon Davy]

On Mon, May 16, 2016 at 2:49 PM, Tim Van Steenburgh
 wrote:
> Right, but NRPE can be related to any charm too. My point was just that the
> charm doesn't need to explicitly support monitoring.

It totally does, IMO.

process count, disk, mem usage are all important, and should be
available out of the box.

But alerts (driven by monitoring) are all about specific context.

When I'm alerted, I want as specific info as possible as to what is
wrong and hints as to why.  Generic machine monitoring provides little
context, and if that's all you had, would increase your MTTR as you go
fish.

I want detailed, application specific, early alerts that can only be
written by those with application knowledge. These belong in the
charm, and need to be written/maintained by the charm experts.

I've been banging on about this idea for while, but in my head, it
makes sense to promote the idea of app-specific health checks (a la
snappy) in to juju proper, rather than a userspace solution with
layers. Then, you *don't* need specific relation support in your charm
- you just need to write a generic set of health checks/scripts.

Then, these checks are available to run as an action (we do this
pre/post each deploy), or show via juju status, or via the GUI[1]. A
monitoring service can just relate to the charm with the default
relation[2], and get a rich app specific set of checks that it can
convert to its own format and process. No need for relations for each
specific monitoring tool you wish to support. Makes monitoring a 1st
class juju citizen.

Juju could totally own this space, and it's a compelling one.
Monitoring is a mess, and needs integrating with everything all the
time. If we do 80% of that integration for our users, I think that
would play very well with operations folks. And I don't think the
tools in the DISCO[3] orchestration space can do this as effectively -
they by design do not have a central place to consolidate this kind of
integration.


[1] Want a demo that will wow a devops crowd, IMO? Deploy a full demo
system, with monitoring exposed in GUI out of the box. I've said it
before (and been laughed at :), but the GUI could be an amazing
monitoring tool. We might even use it in production ;P

[2] or even more magically, just deploy a monitoring service like
nagios unrelated in the environment, and have it speak with the
model's controller to fetch checks from all machines. Implicit
relations to all, which for monitoring is maybe what you want?

[3] Docker Inspired Slice of COmputer,
https://plus.google.com/+MarkShuttleworthCanonical/posts/W6LScydwS89


-- 
Simon

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Promulgated charms (production readiness)

[Tom Barber]

I agree with a lot of that, I don't puport to be a monitoring expert, but
at the same time, as a service writer I know what ports it functions on, I
know what services it provides and I know how to tell if it falls over.

Similarly as a consumer, I'd also like to TFDI and draw some lines and have
at least some functional monitoring in place for services I don't
understand. which is more than "is my node active", but I agree, its not
necessarily the complete solution, but its better than nothing especially
on stuff im unfamiliar with but need to deploy.

But there is also a clear need for users to be able to tweak and deploy
their own monitoring out of band, which for me introduces an interesting
juju design quirk... the platform is designed for users to be able to
design services quickly and "easily". If I were deploying puppet modules
for example, you just git clone everything you need to a modules directory,
hack it around to fit your needs and deploy, Juju doesn't follow that
paradigm where stuff stays in the charm store apart from local deployment
copies, unless you want to fork it. So you are right there needs to be a
way of doing this that is separate to charms. But I also think there should
be a "preferred way" of rolling this stuff out, because to people who don't
understand how it works fully, rolling some custom script, when everything
else is controlled by juju gui seems to break away from what Juju is good
at.

So I guess in summary, I agree about out of band changes and extensions to
logging, but I still think charms should provide "extended logging" because
the developers understand the services they are building.

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 17 May 2016 at 09:42, Samuel Cozannet 
wrote:

> Just bringing in a bit of work I've been doing with a few monitoring
> (/logging) solutions such as Zabbix, Telegraf, Fluentd...
>
> I have taken the opposite approach as what is mostly proposed here. I'm
> from a more ops background, which means my devs usually had no clue
> whatsoever of how I would manage their stuff. Also, even if they did most
> of the job, I would probably need my own ops features.
> So I had a bunch of questions for them, would deploy their stuff for them,
> add the magic ingredient, and everyone would be happy.
>
> My point is if I was a CTO somewhere using Juju right now, I wouldn't
> expect my developers to actively write monitoring or logging entry points.
> Also, I would expect an ops team to redo it anyway.
> So I would rather create a "mynamespace-basic-layer", essentially
> extending the base layer with the tooling I need (eventually even
> incorporating Config management).
> At this point I would expect my monitoring and logging **installed**
>
> Then I use a "self assessment" listing the charms installed locally
> function like :
>
> function charm::lib::self_assessment() {
> [ -z ${JUJU_CONTEXT_ID+x} ] && \
> echo 0 || \
> {
> METADATA="$(find "${JUJU_CHARM_DIR}/../.." -name "metadata.yaml")"
> for FILE in ${METADATA}
> do
> CHARM+=" $(cat "${FILE}" | grep 'name' | head -n1 | cut -f2 -d' ')"
> done
> }
> echo "${CHARM}"
> }
>
> Essentially, I'm giving my supporting charms the ability to understand the
> local environment at the unit level and adapt, even without an explicit
> relation.
>
> I store all monitoring/logging templates centrally which gives me the
> ability to update them out of band, as you would for an antivirus DB. If I
> was to store them in-charm, I'd need a charm upgrade to update them, which
> can be cumbersome, especially if that is in the application charm.
>
> In the end, I am building very intelligent supporting charms for
> monitoring and logging, that understand the target logic based on their own
> knowledge of the charm world, and adapt and evolve over time.
> Anyone and everyone can then improve the templates, so it's even more
> goodness even from people not using Juju.
>
> My first experiment with Zabbix just used self assessment, added that to
> the agent metadata, and the server would have a specific list of templates,
> react to auto-discovery of the agents by looking up the metadata and
> associate the proper templates automagically. It would also create groups
> of machines, and eventually autoscaling rules.
>
> Now I'm doing the same with fluentd (logging), storing the list of
> templates in github and the agent downloads the templates it needs at
> install time, and also for Telegraf (InfluxDB)
>
> From a user perspective, it's really "let's add monitoting", creating a
> "juju add-relation all" feature like :
>
> juju status --format json | jq '.services | keys[]' | tr -d '"' | xargs -I

Re: Promulgated charms (production readiness)

[Samuel Cozannet]

Just bringing in a bit of work I've been doing with a few monitoring
(/logging) solutions such as Zabbix, Telegraf, Fluentd...

I have taken the opposite approach as what is mostly proposed here. I'm
from a more ops background, which means my devs usually had no clue
whatsoever of how I would manage their stuff. Also, even if they did most
of the job, I would probably need my own ops features.
So I had a bunch of questions for them, would deploy their stuff for them,
add the magic ingredient, and everyone would be happy.

My point is if I was a CTO somewhere using Juju right now, I wouldn't
expect my developers to actively write monitoring or logging entry points.
Also, I would expect an ops team to redo it anyway.
So I would rather create a "mynamespace-basic-layer", essentially extending
the base layer with the tooling I need (eventually even incorporating
Config management).
At this point I would expect my monitoring and logging **installed**

Then I use a "self assessment" listing the charms installed locally
function like :

function charm::lib::self_assessment() {
[ -z ${JUJU_CONTEXT_ID+x} ] && \
echo 0 || \
{
METADATA="$(find "${JUJU_CHARM_DIR}/../.." -name "metadata.yaml")"
for FILE in ${METADATA}
do
CHARM+=" $(cat "${FILE}" | grep 'name' | head -n1 | cut -f2 -d' ')"
done
}
echo "${CHARM}"
}

Essentially, I'm giving my supporting charms the ability to understand the
local environment at the unit level and adapt, even without an explicit
relation.

I store all monitoring/logging templates centrally which gives me the
ability to update them out of band, as you would for an antivirus DB. If I
was to store them in-charm, I'd need a charm upgrade to update them, which
can be cumbersome, especially if that is in the application charm.

In the end, I am building very intelligent supporting charms for monitoring
and logging, that understand the target logic based on their own knowledge
of the charm world, and adapt and evolve over time.
Anyone and everyone can then improve the templates, so it's even more
goodness even from people not using Juju.

My first experiment with Zabbix just used self assessment, added that to
the agent metadata, and the server would have a specific list of templates,
react to auto-discovery of the agents by looking up the metadata and
associate the proper templates automagically. It would also create groups
of machines, and eventually autoscaling rules.

Now I'm doing the same with fluentd (logging), storing the list of
templates in github and the agent downloads the templates it needs at
install time, and also for Telegraf (InfluxDB)

>From a user perspective, it's really "let's add monitoting", creating a
"juju add-relation all" feature like :

juju status --format json | jq '.services | keys[]' | tr -d '"' | xargs -I
'{}' juju add-relation ntp {}

and off you go...

Thoughts?

++
Sam














--
Samuel Cozannet
Cloud, Big Data and IoT Strategy Team
Business Development - Cloud and ISV Ecosystem
Changing the Future of Cloud
Ubuntu   / Canonical UK LTD  / Juju

samuel.cozan...@canonical.com
mob: +33 616 702 389
skype: samnco
Twitter: @SaMnCo_23
[image: View Samuel Cozannet's profile on LinkedIn]


On Mon, May 16, 2016 at 10:10 PM, Marco Ceppi 
wrote:

> 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 11:19 AM Cory Johns 
> wrote:
>
>> 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 with layers and layer APIs that's now more possible than ever.
>>
>> Once we have a simplified interface, I do think that the review process
>> should strongly recommend that monitoring support be included, though I
>> don't think we'll be able to make it a hard requirement.
>>
>> On Mon, May 16, 2016 at 10:06 AM, Tom Barber 
>> wrote:
>>
>>> 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 have capability
>>> already in Nagios for a more in depth NPRE make sure its available for
>>> those who want to monitor it, procrunning as well for alarms.
>>>
>>> My point being, I guess, is considering how much Juju tries to do at an
>>> application 

Re: Promulgated charms (production readiness)

[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 11:19 AM Cory Johns 
wrote:

> 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 with layers and layer APIs that's now more possible than ever.
>
> Once we have a simplified interface, I do think that the review process
> should strongly recommend that monitoring support be included, though I
> don't think we'll be able to make it a hard requirement.
>
> On Mon, May 16, 2016 at 10:06 AM, Tom Barber 
> wrote:
>
>> 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 have capability
>> already in Nagios for a more in depth NPRE make sure its available for
>> those who want to monitor it, procrunning as well for alarms.
>>
>> My point being, I guess, is considering how much Juju tries to do at an
>> application level for sys admins, why shouldn't monitors.yaml be required
>> OOTB?
>>
>> Don't get me wrong this was just a brief convo we had and I'm sure there
>> are plenty of reasons against it, but monitoring, which is more than just
>> "is my box alive" type monitoring, would seem pretty important and having
>> people tack stuff on manually to a NPRE setup seems to get away from the
>> Juju ethos somewhat.
>>
>> Tom
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> On 16 May 2016 at 14:52, Charles Butler 
>> wrote:
>>
>>> 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
>>
>>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Promulgated charms (production readiness)

[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 motivation and a charm consumer anecdote:

When the Openstack Autopilot incorporated nagios and related it to all
openstack charms (16.03 release), I personally saw the magic of juju at
play.

You went from having a lot of unrealized monitoring potential in your
juju deployed cloud to having a fully functioning monitoring solution
deployed, and ready to go, just an add-relation away.

That add-relation wasn't free, it took work coding, testing, integrating,
distilling operational knowledge, getting multiple contributors to
test and submit bug reports...

But, after that work, it's to the point now where nagios is highlighting
bugs in the deployment that were overlooked before (especially
longer-running cloud bugs that don't show up at deployment time).  So,
not just valuable for production, and something that operators have
grown to expect and trust, but something that helps keep bugs from
escaping downstream as well!

I just wanted to pass on a bit of encouragement that the work to
incorporate those checks was valuable and having that same experience
across other bits of big software makes charms alive and moves them ever
closer to invaluable operational tools.

-- 
David Britton 

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Promulgated charms (production readiness)

[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 with layers and layer APIs that's now more possible than ever.

Once we have a simplified interface, I do think that the review process
should strongly recommend that monitoring support be included, though I
don't think we'll be able to make it a hard requirement.

On Mon, May 16, 2016 at 10:06 AM, Tom Barber 
wrote:

> 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 have capability
> already in Nagios for a more in depth NPRE make sure its available for
> those who want to monitor it, procrunning as well for alarms.
>
> My point being, I guess, is considering how much Juju tries to do at an
> application level for sys admins, why shouldn't monitors.yaml be required
> OOTB?
>
> Don't get me wrong this was just a brief convo we had and I'm sure there
> are plenty of reasons against it, but monitoring, which is more than just
> "is my box alive" type monitoring, would seem pretty important and having
> people tack stuff on manually to a NPRE setup seems to get away from the
> Juju ethos somewhat.
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 16 May 2016 at 14:52, Charles Butler 
> wrote:
>
>> 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
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Promulgated charms (production readiness)

[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 have capability
already in Nagios for a more in depth NPRE make sure its available for
those who want to monitor it, procrunning as well for alarms.

My point being, I guess, is considering how much Juju tries to do at an
application level for sys admins, why shouldn't monitors.yaml be required
OOTB?

Don't get me wrong this was just a brief convo we had and I'm sure there
are plenty of reasons against it, but monitoring, which is more than just
"is my box alive" type monitoring, would seem pretty important and having
people tack stuff on manually to a NPRE setup seems to get away from the
Juju ethos somewhat.

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 16 May 2016 at 14:52, Charles Butler 
wrote:

> 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: Promulgated charms (production readiness)

[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: Promulgated charms (production readiness)

[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
> 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 at 9:33 AM Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com> wrote:
>
>> 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 thread, I took a brand new
>> charm that I wrote, for which I had not yet even thought about monitoring,
>> deployed Nagios, related it to my charm, and sure enough, it Just Worked.
>>
>>
>>> Its all well and good selling Juju to Developers like myself or CTO's by
>>> the Ops guys have their "special ways" and making sure that charms fit into
>>> those ways will be key to adoption.
>>>
>>> Tom
>>> --
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> 
>>> goal, but you can always help by sponsoring the project
>>> )
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
> --
> Juju Charmer
> Canonical Group Ltd.
> Ubuntu - Linux for human beings | www.ubuntu.com
> Juju - The fastest way to model your service | www.jujucharms.com
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Promulgated charms (production readiness)

[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 at 9:33 AM Tim Van Steenburgh <
tim.van.steenbu...@canonical.com> wrote:

> 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 thread, I took a brand new
> charm that I wrote, for which I had not yet even thought about monitoring,
> deployed Nagios, related it to my charm, and sure enough, it Just Worked.
>
>
>> Its all well and good selling Juju to Developers like myself or CTO's by
>> the Ops guys have their "special ways" and making sure that charms fit into
>> those ways will be key to adoption.
>>
>> Tom
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Promulgated charms (production readiness)

[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

goal, but you can always help by sponsoring the project
)

On 16 May 2016 at 14:32, Tim Van Steenburgh <
tim.van.steenbu...@canonical.com> wrote:

>
> 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 thread, I took a brand new
> charm that I wrote, for which I had not yet even thought about monitoring,
> deployed Nagios, related it to my charm, and sure enough, it Just Worked.
>
>
>> Its all well and good selling Juju to Developers like myself or CTO's by
>> the Ops guys have their "special ways" and making sure that charms fit into
>> those ways will be key to adoption.
>>
>> Tom
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Promulgated charms (production readiness)

[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 thread, I took a brand new charm
that I wrote, for which I had not yet even thought about monitoring,
deployed Nagios, related it to my charm, and sure enough, it Just Worked.


> Its all well and good selling Juju to Developers like myself or CTO's by
> the Ops guys have their "special ways" and making sure that charms fit into
> those ways will be key to adoption.
>
> Tom
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Promulgated charms (production readiness)

[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 puppet module I google: https://github.com/example42/puppet-tomcat

class { "tomcat":
monitor  => true,
monitor_tool => [ "nagios" , "monit" , "munin" ],
  }

Now, of course, I don't expect all Puppet modules to have monitoring
either, but because puppet is more low level, a sys admin, adding
monitoring would find it an easier task (IMHO) than doing it at charm level.

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 16 May 2016 at 12:06, Charles Butler 
wrote:

>
> >  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 out how
> to hook it up without some massive incentive.
>
>
> With that being said...
>
> 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.
>
>
>
>
>
>
> On Mon, May 16, 2016 at 6:45 AM Tom Barber 
> wrote:
>
>> 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 have
>> been validated by those in the know). So people new to the platform will
>> naturally gravitate towards these charms. But does it make them production
>> ready?
>>
>> A couple of questions that cropped up were, even though charms have been
>> reviewed, it doesn't make the them infallible and if people new to the
>> platform install MySQL for example and it fails before they've even
>> started, they'll just spin up a box and apt-get it because what's the
>> point, right? :) So mitigating that risk is one thing.
>>
>> Another point that cropped up was, monitoring. Obviously Charles and co
>> have been working hard on beats, but there are a bunch of industry standard
>> monitoring tools out there that sys admins will already use and be happy
>> with Nagios, Zabbix etc + the commercial ones. Some charms already have
>> Nagios monitoring points, but should it not be a requirement for all
>> promulagated charms to have a monitoring endpoint. For example, we use
>> Nagios on a bunch of our stuff, 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.
>>
>> Its all well and good selling Juju to Developers like myself or CTO's by
>> the Ops guys have their "special ways" and making sure that charms fit into
>> those ways will be key to adoption.
>>
>> Tom
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
> --
> Juju Charmer
> Canonical Group Ltd.
> Ubuntu - Linux for human beings | www.ubuntu.com
> Juju - The fastest way to model your service | www.jujucharms.com
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Promulgated charms (production readiness)

[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 out how to hook it
up without some massive incentive.


With that being said...

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.






On Mon, May 16, 2016 at 6:45 AM Tom Barber  wrote:

> 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 have
> been validated by those in the know). So people new to the platform will
> naturally gravitate towards these charms. But does it make them production
> ready?
>
> A couple of questions that cropped up were, even though charms have been
> reviewed, it doesn't make the them infallible and if people new to the
> platform install MySQL for example and it fails before they've even
> started, they'll just spin up a box and apt-get it because what's the
> point, right? :) So mitigating that risk is one thing.
>
> Another point that cropped up was, monitoring. Obviously Charles and co
> have been working hard on beats, but there are a bunch of industry standard
> monitoring tools out there that sys admins will already use and be happy
> with Nagios, Zabbix etc + the commercial ones. Some charms already have
> Nagios monitoring points, but should it not be a requirement for all
> promulagated charms to have a monitoring endpoint. For example, we use
> Nagios on a bunch of our stuff, 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.
>
> Its all well and good selling Juju to Developers like myself or CTO's by
> the Ops guys have their "special ways" and making sure that charms fit into
> those ways will be key to adoption.
>
> Tom
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Promulgated charms (production readiness)

[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 have been
validated by those in the know). So people new to the platform will
naturally gravitate towards these charms. But does it make them production
ready?

A couple of questions that cropped up were, even though charms have been
reviewed, it doesn't make the them infallible and if people new to the
platform install MySQL for example and it fails before they've even
started, they'll just spin up a box and apt-get it because what's the
point, right? :) So mitigating that risk is one thing.

Another point that cropped up was, monitoring. Obviously Charles and co
have been working hard on beats, but there are a bunch of industry standard
monitoring tools out there that sys admins will already use and be happy
with Nagios, Zabbix etc + the commercial ones. Some charms already have
Nagios monitoring points, but should it not be a requirement for all
promulagated charms to have a monitoring endpoint. For example, we use
Nagios on a bunch of our stuff, 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.

Its all well and good selling Juju to Developers like myself or CTO's by
the Ops guys have their "special ways" and making sure that charms fit into
those ways will be key to adoption.

Tom
--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju