Archive for February 2005
I basically agree with the overall design. Having a separate configuration management component and deployment component is a good idea and keeps us compatible with the V. architecture as well. To extent it further, we could use XML to communicate between those.
Now for some criticism:
The design is too generic.
- Monitors should only be associated with Components not with Devices.remember that components are devices.
- Monitors should not be associated with Component classes and Device classes . The consensus was that we would implement a templating mechanism that would populate the monitors in the database. Overriding properties make the design too complex
- Why make the design so flexible with attributes. We only need to support a few monitor classes.
- I don’t like using a generic name-value table. This is like creating a metalayer on top of SQL. Why not use different tables for different monitors. That is much more natural and understandable later on.
- I don’t like hiding assembly names away in a SQL database. Why do we need that? If we start supporting new monitors we can simply provide a new release.
In addition, we also need to support a reverse path, where we prime the database from reading the configuration of the SSMs using SNMP. It is important that we do this from the start. It will also greatly facilitate the rollback later on.
Further, the model should incorporate the current performance monitors as well
Finally, a history of monitor changes should be kept in a journalling table
What is that backup agent storing locally?
Can we talk to the backup team to see if local storage can be minimized?
Short term solution:
- Suspend the backup agent
- Format the remaining 26Gb as a D: drive and relocate the swap file there. This requires a server reboot. Then reactive the backup agent.
This is the same solution as for the CDS server
Long term solution: Reprovision
Since it looks like Opsware 4.5j is now working in Decafe (Correct me if I am wrong), we have to update the sync tool to work the new API ASAP.
According to the Opsware team schedule we have 2 weeks to change and QA this. The change should be minimal, is there is a change at all. D might consider using the function that was recommended during the conf call to get server info. However, I worry about QA. I think we better finish this quickly from our side, so that QA has a bit of time.