Content System - Versioning

Stefan Negrea snegrea at redhat.com
Tue Jan 17 21:52:05 UTC 2012


Hello Everybody, 

I just want to raise awareness regarding a couple of recent changes to the content system. These details are important for plugin developers that use the content system. If you are working on a server or agent plugin that interacts with the content system I would highly recommend to read this email carefully. Most likely the changes I will detail in this email do not impact existing plugins but I highly recommend a review of existing code to make sure it works as intended and as expected.

The content system stores data in a myriad of tables. The PackageVersion table is the most important because it links package metadata with actual content. Internal RHQ server queries use the version field of this table to uniquely identify a package. The content system can store multiple packages with the same name, but they are uniquely identified by the version. So [ROOT.war version=1.1] is stored only once in the database irrespective if the actual war content is different. Just to give an example, ROOT.war is deployed by default on both JBoss AS4 and JBoss AS5 and discovered by both plugins as [ROOT.war version=0]. The first server that gets inventoried wins the battle to store its ROOT.war content on the RHQ server. When a second application server is inventoried, the RHQ server considers that [ROOT.war version=0] is already stored and does not act on the agent request to store content. These details combined with some agent discovery issues resulted in a set of problems for deploying and retrieving content deployed.

The solution that I proposed and implemented preserves existing server code for the content system. The updates were done to the CLI, UI, three agent plugins (Tomcat, JBoss AS4, JBoss AS5), and four server plugins (remote repository syncing) to populate the version field with something that uniquely identifies that actual content. So, the version field is populated with the SHA256 of the content. After this changes the package [ROOT.war version=[sha256=abcd1234] ] is correctly identified based on its content and not on some arbitrary version. The old version concept was then made optional (in the UI and CLI) and stored in display version field, which was in the design but not used. After these changes a package version data will look like this: [ROOT.war version=[sha256=abcde123] display version=1.1].

Just to recap, your plugin will most likely work the same even after this set of changes. I highly encourage anybody to review their code that interacts with the content system to make sure it does not have the same version problems. Another recommendation would be to update existing code to use SHA256 for version and move the existing version concept to the display version field.


Please feel free to contact me if you have any questions or concerns.



Thank you,
Stefan Negrea

Software Engineer



More information about the rhq-devel mailing list