Modify

Ticket #433 (closed enhancement: fixed)

Opened 14 years ago

Last modified 12 years ago

Report system, possible enhancements...

Reported by: jnormand@… Owned by: hagedorn
Priority: major Milestone: Bcfg2 1.0.0 Release
Component: bcfg2-reports Version: 1.0
Keywords: Cc:

Description

Hi,

Here is my take on ticket #89. Ideally I would be able to add a comment to it but htat does not seem to work. Anyway:

  • having bcfg2 directly accessing the RDBMS of the report system? I think this is a _bad_ idea. The 2 sides, bcfg2-server and reports should be completely independent. I would rather have the server send some updates to the report system. That would allow the structure of the database to change without breaking everything, and also the version of the 2 parts would not be tighly linked. The cool part is that we already have something like that working. The current already send (xml) updates to the report system. The current problem is that those messages are a global view of the network instead of just a delta (diff?) of what changed. That would be much cheaper to produce and scale better (O(1) instead of O(n)). The way I see it, we would have a filter on the server. The conclusion message sent back by the client would be just slightly modified to include any extra info needed for the reports, and the result sent. An extra cool part is that one could put an additional step between the server and the reports, maybe for a ticket management or a paging system without having to deal with the possibly changing structure of the reports database. One will also be able to maintain a redundant system with several report system and several servers since the updates are essentially one way pushes.
  • reports accessing the repository? I don't like that too much. I think that there is a risk of miss-information. The repository can change between the time the client ran and when the report is read. I would much rather include the relevant parts in the delta message in was speaking about. This way the server can make sure that everything is part of the same transaction. That will also make the reports code simpler which might not be a bad idea.
  • node up/down and pings: I don't think that it is the job of the server to do those checks. Any network large enough to get the benefit of bcfg2 will include some kind of monitoring system (nagios?). They might or might not run of the same box and they might or might not share some configuration informations (nagios configured by a magic plugin with the data from the repository). But the monitor system will have to do a lot more than a simple ping and in particular verify that every service work as it should (test accounts for ssh, sample page request for apache, etc). This ping test from the server seems like it does not give much, is difficult to implement correctly (with the synchronization to the reports) and well is redundant with what will run on the side. Did I miss something?
  • System display: I think that displaying each client by name on the start page of the report is not the best way. It will not scale so well on large networks because each line will require several DB requests. I would rather have the entries sorted by profiles since we already have this information anyway. There is likely to be fewer of those, and it will be easier to dig through. Opening a profile will only access part of the db so that will cut down on the strain and I am pretty sure that it will give an extra view of the system (why only my lab-workstations do show as bad?)

Sorry for the long message but I wanted to be as clear as possible. These are some subject that I talked about on the IRC channel, but it is always good to have them in writing somewhere.

Jacques

Attachments

Change History

comment:1 Changed 14 years ago by desai

  • Owner changed from desai to hagedorn
  • Reporter changed from anonymous to jnormand@…

comment:2 Changed 13 years ago by solj

  • Version set to 1.0
  • Milestone set to Bcfg2 1.0 Release

comment:3 Changed 12 years ago by solj

  • Status changed from new to closed
  • Resolution set to fixed

I think most of these issues are resolved (or will be with Snapshots). A reference has also been added to this ticket from #89.

WARNING! You need to establish a session before you can create or edit tickets. Otherwise the ticket will get treated as spam.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.