Bug 535738 (RHQ-2402)

Summary: newly created package backed resources do not immediately have an available backing package
Product: [Other] RHQ Project Reporter: Jay Shaughnessy <jshaughn>
Component: ContentAssignee: Stefan Negrea <snegrea>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 1.3preCC: cwelton, snegrea
Target Milestone: ---Keywords: SubBug
Target Release: ---   
Hardware: All   
OS: All   
URL: http://jira.rhq-project.org/browse/RHQ-2402
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-25 23:02:01 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 565635    

Description Jay Shaughnessy 2009-09-02 10:37:00 EDT
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.
Comment 1 Jay Shaughnessy 2009-09-02 11:16:43 EDT
Just to confirm regarding the content discovery interval.

The ContentDiscoveryRunner is initialized in ContentManager with the default values of initial delay of 60 seconds and a period of 30 seconds.  Although, these values are configurable and could have been overriden by setting the Plugin Container config properties:

rhq.pc.content-discovery-initial-delay
rhq.pc.ontent-discovery-period


Comment 2 Red Hat Bugzilla 2009-11-10 16:03:44 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2402
Comment 3 wes hayutin 2010-02-16 11:59:14 EST
Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs.

keyword:
new = Tracking + FutureFeature + SubBug
Comment 4 wes hayutin 2010-02-16 12:04:05 EST
making sure we're not missing any bugs in rhq_triage
Comment 5 Corey Welton 2010-12-23 09:42:35 EST
Triaged 20-Dec
Comment 6 Stefan Negrea 2014-03-25 23:02:01 EDT
The content is eventually discovered and correctly attached to the resource when the discovery process runs. This is no longer an issue.