Bug 536304 (RHQ-669)
Summary: | Add package metadata to indicate if it supports multiple architectures | ||
---|---|---|---|
Product: | [Other] RHQ Project | Reporter: | Jason Dobies <__jdobies> |
Component: | Content | Assignee: | Jason Dobies <__jdobies> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Corey Welton <cwelton> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | unspecified | Keywords: | 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
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". 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. 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). 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. QA Verified - supports_architecture | boolean | not null Furthermore, after submitting ear/war files they deploy correctly. 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. This bug was previously known as http://jira.rhq-project.org/browse/RHQ-669 This bug relates to RHQ-763 |