[
https://jira.jboss.org/jira/browse/JOPR-64?page=com.atlassian.jira.plugin...
]
Charles Crouch updated JOPR-64:
-------------------------------
Description:
Example of what I mean:
1) Create a content source pointing at a QA CSP feed.
2) Sync the content source and review the packages. Select a package and see the
downloadUrl is pointing at the QA CSP infrastructure
3) Create a content source pointing at the Prod CSP feed.
4) Sync the content source and review the packages. Select a package and see the
downloadUrl is still pointing at the QA CSP infrastructure. This means that even if you
create a channel associated with the Prod content source and then subscribe a resource to
this channel you will still end up trying to download a QA package when you try to apply a
patch.
The problem arises because we only use package name (e.g. JBoss AS 4.0.3.SP1_CP11) and
package type (e.g. CP) to determine uniqueness of packages so both channels are providing
information about what we think is the same package. I think the logical thing here is
have each channel have its own unique packages, even though that means the
rhq_package/rhq_package_version tables would need to change to take into account channel.
This seems somewhat wasteful if you have a lot of identical packages across two content
sources, but the current situation: What you have in your channel is determined by what
old content sources you have deployed, doesn't seem tenable.
was:
Example of what I mean:
1) Create a content source pointing at a QA CSP feed.
2) Sync the content source and review the packages. Select a package and see the
downloadUrl is pointing at the QA CSP infrastructure
3) Create a content source pointing at the Prod CSP feed.
4) Sync the content source and review the packages. Select a package and see the
downloadUrl is still pointing at the QA CSP infrastructure. This means that even if you
create a channel associated with the Prod content source and then subscribe a resource to
this channel you will still end up trying to download a QA package when you try to apply a
patch.
I think the logical thing here is have each channel have its own unique packages, even
though that means the rhq_package/rhq_package_version tables would need to change to take
into account channel. This seems somewhat wasteful if you have a lot of identical packages
across two content sources, but the current situation: What you have in your channel is
determined by what old content sources you have deployed, doesn't seem tenable.
No support for multiple content sources providing the same content
------------------------------------------------------------------
Key: JOPR-64
URL:
https://jira.jboss.org/jira/browse/JOPR-64
Project: Jopr
Issue Type: Bug
Affects Versions: 2.1
Reporter: Charles Crouch
Example of what I mean:
1) Create a content source pointing at a QA CSP feed.
2) Sync the content source and review the packages. Select a package and see the
downloadUrl is pointing at the QA CSP infrastructure
3) Create a content source pointing at the Prod CSP feed.
4) Sync the content source and review the packages. Select a package and see the
downloadUrl is still pointing at the QA CSP infrastructure. This means that even if you
create a channel associated with the Prod content source and then subscribe a resource to
this channel you will still end up trying to download a QA package when you try to apply a
patch.
The problem arises because we only use package name (e.g. JBoss AS 4.0.3.SP1_CP11) and
package type (e.g. CP) to determine uniqueness of packages so both channels are providing
information about what we think is the same package. I think the logical thing here is
have each channel have its own unique packages, even though that means the
rhq_package/rhq_package_version tables would need to change to take into account channel.
This seems somewhat wasteful if you have a lot of identical packages across two content
sources, but the current situation: What you have in your channel is determined by what
old content sources you have deployed, doesn't seem tenable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira