SHA For Exploded Content

Stefan Negrea snegrea at redhat.com
Thu Mar 8 21:59:58 UTC 2012


Hello,

I created the following branch for this change: http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=shortlog;h=refs/heads/stefan/contentsystem

This commit in particular has the refactoring for FileContentDelegate:
http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=a5aa7487716d4ef9f49c19974567256dc8981f28


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 at redhat.com>
> To: "rhq-devel" <rhq-devel at 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 at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list