Bug 536304 (RHQ-669)

Summary: Add package metadata to indicate if it supports multiple architectures
Product: [Other] RHQ Project Reporter: Jason Dobies <__jdobies>
Component: ContentAssignee: Jason Dobies <__jdobies>
Status: CLOSED NEXTRELEASE QA Contact: Corey Welton <cwelton>
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedKeywords: Improvement
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
URL: http://jira.rhq-project.org/browse/RHQ-669
Whiteboard:
Fixed In Version: 1.1 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jason Dobies 2008-07-14 16:24:00 UTC
In addition to versionless content, there seem to be a growing number of package types that do not care about architecture. While we have an enumerated value for this (noarch), it would be useful to express the architecture-less nature of a package type, giving us the ability to limit the amount of things requested in the UI. I'm envisioning something like a property "supportsMultipleArchitectures" that is defined as part of the package type.

Comment 1 Jason Dobies 2008-07-14 16:26:05 UTC
Related to this is actually using this concept, specifically in the package-backed resource create to not show the architecture drop down and default to "noarch".

Comment 2 Jason Dobies 2008-07-14 16:28:07 UTC
I'm not sure I like "supportsMultipleArchitectures" if I'm simply defaulting to "noarch" if this is false. Two options:

- I suppose it might be more flexible to have the metadata be "singleArchitecture" and have its value be set to "noarch". This would allow package types that do have architecture to only be of a specified type.

- Change the property to be something akin to "supportsArchitecture", meaning whether or not architecture is even relevant to the package type. This makes defaulting to noarch make more sense.

Comment 3 Jason Dobies 2008-07-16 18:33:17 UTC
r1100
- Added metadata to a package type to indicate if there is the concept of architectures. Updated DB schema and parser to read and persist this information. Added check in package-backed resource creation to not render the architecture drop down when architecture is not supported (defaults to "noarch" internally in this case).

Comment 4 Jason Dobies 2008-07-16 18:46:53 UTC
QA:

Note that this can easily be tested with RHQ-666.

This change affects the database and thus should be tested as both a clean installation as well as an upgrade.

- If the server successfully starts without throwing any exceptions preventing any plugins from loading, the DB is correct.
- To verify the DB structure explicitly, make sure the table rhq_package_type has a column of type "boolean", named "supports_architecture", and is set to "not null". In postgres, I checked this by using psql to connect to the database ("psql rhq") and typing "\d rhq_package_type". In Oracle, I used the web interface and navigated to the table's description.

- Navigate to create a new EAR or WAR file.
- On the screen where the package name and file inputs are displayed, the page should *not* show a drop down for architecture.
- Complete the EAR or WAR deployment and make sure it works correctly.

Comment 5 Corey Welton 2008-08-22 17:08:46 UTC
QA Verified - 

 supports_architecture    | boolean                | not null


Furthermore, after submitting ear/war files they deploy correctly.

Comment 6 Jeff Weiss 2008-08-27 20:35:48 UTC
I tried this on an upgrade install, and the ear creation fails.  Joseph is going to open a separate bug for this.

I did verify the postgres tables on the upgrade install, rev1250.  Have not tried oracle, I don't even have an oracle instance.

Comment 7 Red Hat Bugzilla 2009-11-10 21:14:24 UTC
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-669
This bug relates to RHQ-763