KARL3

Bug #770428
Comment #5

Comment 5 for bug 770428

Revision history for this message

Paul Everitt (paul-agendaless) wrote on 2011-05-10: Re: [Bug 770428] Re: Develop email-in tracer tool

On May 10, 2011, at 10:59 AM, Robert Marianski wrote:

> I was assuming these tracer emails would just be blog post entries, and
> then the test would be to verify that unique text, like a uuid or
> timestamp, was present on the page.

We'd have to teach Nagios to have a login. Its requests are currently anonymous. We'd be moving some of the "Is KARL ok?" away from the error monitor page.

> What are the negative consequences of just sending an email to a
> separate private community? If we want to eliminate the content feeds
> side effect, we can create a separate dummy user just for this tracer
> private community.

We'll accumulate around 10,000 new pieces of bogus content a month. I suppose search/catalog time after a while will bog down.

On the plus side, you'll double the amount of "content" in KARL in about half a year I suppose. :)

--Paul

> I guess this makes the test to verify that the mail went through more
> complicated, but it might be easier to move the complexity there than to
> build something separate in karl.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/770428
>
> Title:
> Develop email-in tracer tool
>
> Status in KARL3:
> New
>
> Bug description:
> We don't have a reliable way to know when email-in is wedged. Rather
> than trying to monitor each part of the end-to-end facility, we should
> instead monitor the failure of a tracer email to be received.
>
> The idea is that something, somewhere (hopefully inside the OSF NYC
> LAN) sends a tracer email to KARL every N minutes. This won't be a
> blog entry, as we don't want some dummy blog filling up and the
> content feeds getting blasted.
>
> Instead, we'll develop a new tool, either as part of a community or
> something hanging off the top. This tool will record receipt of the
> email. We'll also make sure that if the tracer wasn't received in the
> last N minutes, monitoring gets triggered.
>
> Some notes:
>
> - Exercise as much of the machinery as possible. We don't really need
> to test the ability to create a blog entry or blog comment. If it
> goes out of the NYC network, through the Internets tubes, into the
> outer Postfix, through its spam filters, to the inner, through
> repoze.postoffice, and is picked up by the daemon, that will handle
> 99% of the problems.
>
> - Make sure admins like Robert/Nat/Paul can go and see something about
> the tracer. Most likely the admin screen.
>
> - Document, in that tool, the email address that is used for the To:
> on the tracer. That lets people send the email manually if they want
> to.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/karl3/+bug/770428/+subscribe

On May 10, 2011, at 10:59 AM, Robert Marianski wrote:

> I was assuming these tracer emails would just be blog post entries, and
> then the test would be to verify that unique text, like a uuid or
> timestamp, was present on the page.

We'd have to teach Nagios to have a login. Its requests are currently anonymous.  We'd be moving some of the "Is KARL ok?" away from the error monitor page.

We'll accumulate around 10,000 new pieces of bogus content a month.  I suppose search/catalog time after a while will bog down.

On the plus side, you'll double the amount of "content" in KARL in about half a year I suppose. :)

--Paul

> I guess this makes the test to verify that the mail went through more
> complicated, but it might be easier to move the complexity there than to
> build something separate in karl.
> 
> -- 
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/770428
> 
> Title:
>  Develop email-in tracer tool
> 
> Status in KARL3:
>  New
> 
> Bug description:
>  We don't have a reliable way to know when email-in is wedged.  Rather
>  than trying to monitor each part of the end-to-end facility, we should
>  instead monitor the failure of a tracer email to be received.
> 
>  The idea is that something, somewhere (hopefully inside the OSF NYC
>  LAN) sends a tracer email to KARL every N minutes.  This won't be a
>  blog entry, as we don't want some dummy blog filling up and the
>  content feeds getting blasted.
> 
>  Instead, we'll develop a new tool, either as part of a community or
>  something hanging off the top.  This tool will record receipt of the
>  email.  We'll also make sure that if the tracer wasn't received in the
>  last N minutes, monitoring gets triggered.
> 
>  Some notes:
> 
>  - Exercise as much of the machinery as possible.  We don't really need
>  to test the ability to create a blog entry or blog comment.  If it
>  goes out of the NYC network, through the Internets tubes, into the
>  outer Postfix, through its spam filters, to the inner, through
>  repoze.postoffice, and is picked up by the daemon, that will handle
>  99% of the problems.
> 
>  - Make sure admins like Robert/Nat/Paul can go and see something about
>  the tracer. Most likely the admin screen.
> 
>  - Document, in that tool, the email address that is used for the To:
>  on the tracer.  That lets people send the email manually if they want
>  to.
> 
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/karl3/+bug/770428/+subscribe