Bug 841084 - [RFE]RAW_REPOS is better than RAW_TREES in config file.
Summary: [RFE]RAW_REPOS is better than RAW_TREES in config file.
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: PulpDist
Classification: Community
Component: z_other
Version: unspecified
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: 0.1.0
Assignee: Nick Coghlan
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-07-18 06:16 UTC by xuezhi ma
Modified: 2014-11-18 02:20 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-09-07 07:08:23 UTC
Embargoed:


Attachments (Terms of Use)

Description xuezhi ma 2012-07-18 06:16:38 UTC
Description of problem:
I think RAW_REPOS is better than RAW_TREES in config file, RAW_TREES entries (with "repo_id" fields) and LOCAL_MIRRORS entries (with "mirror_id" fields) map to Pulp repositories, and we already have REMOTE_TREES, when we use CML to do some operation, --tree:REMOTE_TREES, --mirror:LOCAL_MIRRORS, --repo:RAW_TREES, so, I think --repo:RAW_REPOS is better.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Nick Coghlan 2012-07-18 06:58:47 UTC
This is something QE picked up during the initial testing - the reuse of the "_TREES" suffix is really quite confusing, particularly when the identified field in the RAW_TREES case is called "repo_id" and the command line filtering option is "--repo".

RAW_REPOS is a far more sensible name, and the 3.0 release is our last real chance to fix it before backwards compatible becomes a problem for changing it.

Comment 2 Nick Coghlan 2012-07-23 03:54:28 UTC
Updated in git

Comment 3 Nick Coghlan 2012-07-25 04:55:14 UTC
Pushed to staging server in 3.0.12

Expected behaviour:
- "init" command will reject files containing a "RAW_TREES" section
- "init" command will accept files with a "RAW_REPOS" section

Comment 4 Nick Coghlan 2012-09-07 07:08:23 UTC
Fixed in 0.1.0


Note You need to log in before you can comment on or make changes to this bug.