The SHA256 for exploded content is now saved in the data directory of the agent in
properties file with the name "<Resource Uuid>.sha". I also simplified as
much as possible the public interface for FileContentDelegate. While the interface is much
cleaner, I am still pondering about the fact that this class servers two purposes: (1)
deploy/retrieve/delete content and (2) save/retrieve SHA for the content.
Feedback is greatly appreciated :)
Thank you,
Stefan Negrea
----- Original Message -----
From: "Stefan Negrea" <snegrea(a)redhat.com>
To: "rhq-devel" <rhq-devel(a)lists.fedorahosted.org>
Sent: Tuesday, March 6, 2012 5:04:05 PM
Subject: SHA For Exploded Content
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
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel