There are issues with the logic behind package backed resource creation and the artifacts that get generated.  When a PBR (I like that acronym) gets created it should, in my opinion have an associated InstalledPackage record tying together the new Resource with its PackageVersion.  In turn, the PackageVersion should reflect a version of a Package.

The issue is that none of these things exist in a usable way when the resource creation is complete. Here is what happens (based on my investgation of deploying a .war to a Tomcat server):

1) We create a PackageVersion, and associated Package, in advance of the CreateRequest.

We're already behind the eight ball.  The problem is that we're generating a PackageVersion without actually knowing the resulting package name or version.  The package name is set to the file name (e.g. 'foo.war') and the version is set to the current timestamp.  We store the bits in the db on the PackageVersion record.  The new PackageVersion record is immediately inaccessible because no future query will know its package name or version.

Note, it is not necessary to create a PackageVersion record in order to perform the resource creation request.


2) We perform the the Agent side creation request.

It's actually here that we could determine the actual package name and version.  The information could be returned in the CreateResourceReport but today it is not.  In the default scenario the package name is actually 'foo', not 'foo.war' (the war is exploded into a directory). And the version will be set explicitly (if set in the manifest) or default to '1.0' (this is plugin dependent).


3) We complete the resource creation server-side.

After successful PBR creation the new PBR does not have an InstalledPackage record.  To a degree this is ok because it would reference the "invalid" PackageVersion record with a different package name and version.

The PBR will have no backing record until the next content discovery is run (I think this is a 30 second interval/60 second initial delay, not sure. May be short but there is a window).  At that time the plugin will be asked to perform a package discovery.  This package discovery is actually done to find deployments performed outside of RHQ (either pre-existing or deployed in another way).  As it turns out it will also pick up our new PBR's package.  At this point the server will try and "merge" these discovered packages into the existing server-side model by looking for existing InstalledPackage records matching name/version.  For those not found it will generate them, and backing PackageVersion/Package records (giving us two PVs and two Package records, one for 'foo' and the original 'foo.war').

This sort of works but has drawbacks.  First, there is a window where the PBR has no backing package info. Second, the package bits are on the invalid, inaccessible PackageVersion record.  This means that if a client asks for the backingPackage of the PBR there is a chance it will not exist.  If a client asks for the backing bits of the PBR it will either not exist or need to be pulled via the plugin, on the agent. Even though the bits are actually stored in the db in the invalid PackageVersion record.

And third,  the installation time and installer (subject) are not settable by package dsicovery so it's confusing in the GUI when you create a resource and install time is set to epoch. (We should probably return 'unknown' when converting a timestamp of 0.)


What to do about it:

Well, given the complexity here I'm now thinking we leave it alone for 2.3.  The window of having no InstalledPackage is fairly small, due to content discovery being a sceduled event (although, a create followed by a immediately by a getBackingPackage will almost always fail).  If the plugin side code is implemented to return package bits then, although inefficient, I think things should work.

The useless PV records are storing inaccessible package bits.  This is a waste of space but not a monumental issue.  In the future this PackageVersion creation could just be skipped.

The biggest problem is just the ongoing complexity of the content model with respect to bugs or feature enhancement.  These unnecessary steps and errant records are simply confusing and inefficient.  I initially thought that we could change the PBR creation to pass back more information from the plugin and generate the InstalledPackage/PackageVersion records as part of the CreateRequest completion logic. But, as it turns out, the PBR is not actually created in inventory until after the scan and inventory synch.  So, we can't get a handle on the resource (the id) until after the actual createResource call has already completed. And even then, it's not simple to get the new resource, once it's in inventory we need to get it via the resourceKey returned by the create.