On Thu, Jan 23, 2014 at 15:35:41 +0100, Lukas Zapletal wrote:
> >  +---------+   +-----+
> >  | foreman |   | FAF |
> >  +---------+   +-----+
> >      ^            ^
> >       \          /
> >        \        /
> >         \      /
> >          \    /
> >      +-------------+
> >      | smart proxy |
> >      +-------------+
> >             ^
> >             |
> >             |
> >         +------+
> >         | host |
> >         +------+
> 
> I havent attended the discussion, but why the host cannot talk to the
> FAF directly?
> 
> the host ---> FAF <----> smart proxy <-----> foreman
>
> I assume that would be scenario A) in your former proposal. We kinda
> discussed both A and B options and I have to admit I leaned towards B
> option (the picture above), after reading this:
> 
> > 4) The smart proxy formats the report to the same format as Puppet uses
> > and sends it to Foreman. It probably always shouldn't do so immediatelly
> > as that could DOS the Foreman in case a lot of hosts will be sending
> > crash reports very often. It should store the reports in memory and
> > aggregate them according to the their identifier (a.k.a.  hash). The
> > hash can be computed by the satyr library [2].
> 
> I am not so sure now. I am late on emails today, but I haven't seen any
> pros/cons or wider discussion why we should integrate like that.

The reason is that we'd like to make use of the reports without the need
to install FAF, as:
- FAF is rather heavyweight piece of software that has lots of
  dependencies, needs SQL database, etc.
- Its features are mostly targeted at developers of the software for
  which the reports are generated. I assume that it wouldn't be actually
  that useful for typical foreman user.

The architecture in the picture allows you to be informed about crashes
on your managed hosts. Optionally, you can deploy your own FAF instance
for better crash statistics and more crash data, or send the reports to
FAF instance of your software supplier (e.g. Red Hat).

Reply via email to