SHA For Exploded Content

Stefan Negrea snegrea at redhat.com
Tue Mar 6 23:04:05 UTC 2012


Hello Everybody,

One of the biggest challenges for the content system is to match content on disk with data stored in the RHQ database. To be more specific, how to match a set of files deployed on disk for a particular application with PackageVersion entries in the database.

The current approach:
1) Use content's SHA to match content with PackageVersion
2) For zipped deployments, compute the SHA every time discovery runs and report it back to the server.
3) For exploded deployments report back the SHA stored in the manifest:
  a) If deployment was done through RHQ, then store during deployment the SHA of the archive in the manifest.
  b) If deployment was not done through RHQ, then compute the aggregate SHA of all the files that comprise the app.

Now this has some weaknesses:
1) In AS 5 the actual deployment process is done in two parts (half by AS5 and half by RHQ). This leads to file permissions problems. Please refer to https://bugzilla.redhat.com/show_bug.cgi?id=790753 for more details.
2) RHQ is actually updating/creating files in the actual deployment (the manifest). In case of a failed deployment, it could create the perception that it is RHQ's fault because it updated app files.
3) If users go and delete the manifest outside of RHQ, next discovery will generate a new SHA based on disk files. The problem here is that this new SHA will be different than the original SHA of the archive and when reporting back the server will consider this is a new and different package. 


Here is a solution for the first two problems:
1) Stop updating/creating the manifest.
2) In the RHQ agent data directory, create a file for each webapp to store the SHA. The file name would be based on the resource id. Use the same process for generating the SHA.


Going back to the third weakness, in a sense if a user updates files on disk then the app is no longer the original deployed app. It makes sense to consider this a completely different content and discover it as such. While the proposed solution has advantages, it will accentuate this third weakness. Every single time a user deletes agent's data folder all the SHAs will be lost and recalculated based on files on disk. So there are trade-offs (non-intrusive solution vs data persistence, simple vs complex run-time requirements due to file permissions) but I think the proposed solution is a step forward in many ways.


Any feedback for the proposed solution (anything that I might have missed)? Any other ideas how to store the SHA (without updating application files)?



Thank you,
Stefan Negrea

Software Engineer



More information about the rhq-devel mailing list