Remote repository as both data and metadata store
The main motivation for storing more data in an S-RAMP repository is the fact that it is externally queryable. This means that any data we store into S-RAMP is accessible by users and 3rd parties. This is of course very useful for automation purposes. The reason why S-RAMP is a better place for storing such data than RHQ itself is that S-RAMP is designed to be a repository of deployable artifacts and has some nice built-in features to extract metadata from the artifacts. Another focus of S-RAMP is on querying the stored data and metadata. Thus it is meant to be a one-stop-shop for accessing the artifacts and also their metadata in an intelligent manner.
A consequence of moving the data and metadata about the deployable files and also the metadata about their deployments into S-RAMP/JCR is the fact that our own data model is drastically simplified. The data previously described by the model of course still exists but now lives in a external repository in a much more succint format than the JPA entities.
Data Model
ContentRepository
This is basically an amalgamation of today's repository and content source. A content repository represents a remote repository and is able to stream the files back and forth between the repository and RHQ. It is a "live view" of the repository - we don't cache or store on our own any data in the repository. In essense, a repository is understood as part of the data backend - as is the database - we just rely on it being there to provide and store data.
ContentFileIdentifier
We have a concept of ContentGroup}}s which are just renamed {{BundleGroup}}s of today (see https://docs.jboss.org/author/display/RHQ/Bundle+Permissions). To be able to make a link between a remote file stored in a repository and the {{ContentGroup that defines the authorization placed on it inside RHQ, we need to represent the file somehow inside RHQ. This is done using this class. Notice that it is just a path in the repository, NOT containing the version of the file. This is to conform to how bundle groups are designed to work - they are enforced on bundles, not bundle versions. This means that once you assign a file in the repository to a content group, all versions of that file will be accessible to anyone with access to the content group.
ContentRepositorySyncJob
An optional feature to automatically deal with the changes in the remote repository - if a file disappears from the repository, we should also remove from our records - i.e. remove a ContentFileIdentifier if we have one for the file.
ContentFile
A content file is a class to represent a file in the remote repository. It is just a DTO that travels through various RHQ workflows.
ProvisioningDestinationDefinition
Similar to ResourceTypeBundleConfiguration of today. This represents the definition of a destination to deploy stuff to. These entities are created based on information in agent plugins, namely the "destination-base-dir"s in <bundle> sections and the <content> sections.
<destination-base-dir> would be mapped as:
applicable mimetypes: application/vnd.rhq.bundle.*
name: name of the destination
displayName: name of the destination
description: description of the destination
allowedBundleFileExtensions: *
<content> would be mapped as:
applicable mimetypes: coming from <content>
name: coming from <content>
displayName: coming from <content>
description: coming from <content>
allowedBundleFileExtensions: coming from <content>
ProvisioningTypeDefinition
This is akin to today's BundleType. Basically it formally represents a bundle handler. Today, the BundleType is defined based on info in a server-plugin. The ProvisioningTypeDefinition would on contrast come from the agent bundle plugin!
An old-fashioned bundle type would be mapped as:
applicable mimetypes: *
configurationDefinition: a single simple prop called deployDir
bundleHandlerResourceType: ant or filetemplate respectively
<content> tags would be mapped as:
applicable mimetypes: defined in <content>, defaulting to *
configurationDefinition: none
bundleHandlerResourceType: the resource type defining the <content>
ProvisioningDestination
Defined by the user, these represent the actual configured destinations for deploying content. These correspond to today's {{BundleDestination}}s but can also represent a single <content> on a set of resources. Even though I have been warned several times in the past, I think it is still worth to support single-resource destinations as opposed to only having resource group based destinations.
ContentRepositoryConnectorFacet
This represents a new type of a server plugin that can communicate with a remote repository (S-RAMP, JCR, ...). It is the cornerstone of the new design because it provides a gateway through which the information is relayed between RHQ and the remote repository.
BundleRecipe
This artifact lives in the remote repository. The remote repository is enhanced with an RHQ "plugin" of sorts, specific to that kind of repository. In S-RAMP, we'd have a RHQ model that would define the derived artifacts and relationships, in Modeshape we'd have a custom sequencer and in other remote repositories, we'd have another kind of "plugin" that would make information about RHQ bundles and deployments available.
A bundle recipe is what is being installed as a bundle. The actual bundle files are linked to it using S-RAMP relationships or using a custom property in JCR. The repository connector provides a method to obtain such linked files in a repository-specific way. RHQ server, therefore, is told what file to deploy by the user. It asks the connector to fetch the linked files, too, and proceeds with the deployment using all those files. In another words, the bundles are/can be stored "exploded" in the repositories (this is because it just makes sense in a repository, while it made less sense in RHQ with bundles, which is why we originally wanted to support this in bundles but dropped it), but once they enter the deployment workflows in RHQ, they travel as bundles do today - in a zipped form, all files together.
Deployment
Not only do we store the metadata about the artifacts in the repository, but we also store the data about the deployments of those artifacts in there. The reason is that such information can be very useful for business processes that might want to know the places an artifact is currently deployed to. Note that S-RAMP as of recent supports auditing of changes, so we can track the history
of deployments of an artifact.
ResourceDeployment
A companion of Deployment describes the state of the deployment of the artifact on a single resource. These two artifacts together represent the data model we currently have in the bundle subsystem for tracking the deployment info. The audit logs coming from the bundle recipes are stored as content of the ResourceDeployment artifact in a form of a log4j log file. This log file represents what we currently model as a list of ResourceDeploymentHistory entities in the bundle subsystem.