Custom Query (894 matches)

I can't add new information to or change the metadate of Bcfg2 Trac tickets any more. Also might want to add a new Component: bcfg2-trac

The WritingSpecification? documentation page says that the pingable attribute is deprecated. But when I remove it and run bcfg2-repo-validate, I get the following output:

/var/lib/bcfg2/Metadata/clients.xml ***FAILS*** to verify               <----
/var/lib/bcfg2/Metadata/clients.xml:3: element Client: Schemas validity error : Element 'Client': The attribute 'pingable' is required but missing.

I had expected to be able to remove the deprecated element and still have the config file be valid.

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