Bug 1119406

+++ This bug was initially created as a clone of Bug #969637 +++

Description of problem:
When we use spacewalk-clone-by-date command with configuration file (option -c ) to clone child channel for already existing destination base channel. It updates child channel as well as cloned base channel also with new errata.

Version-Release number of selected component (if applicable):
RHN Satellite v 5.5

How reproducible:
always

Steps to Reproduce:
1. Use configuration file with details as bellow 

{
 "username":"admin",
 "password":"password",
 "assumeyes":false,
 "to_date": "2013-05-31",
 "skip_depsolve":false,
 "security_only":false,
 "blacklist": {
              },
 "removelist": {
              },
 "channels":[
             {
                "rhel-x86_64-server-6": "clone-rhel-x86_64-server-6",
                "rhn-tools-rhel-x86_64-server-6": "testing-clone-rhn-tools-rhel-x86_64-server-6"
             }
           ]
}

Here destination base channel - clone-rhel-x86_64-server-6 is already present and has all required packages. Intention is to create clone of child channel of RHN tools. 

2. Create clone of RHN Tools channel using configuration file : 

# spacewalk-clone-by-date -c /root/sample-config.txt 
Reading repository information.

By continuing the following channels will be created: 
testing-clone-rhn-tools-rhel-x86_64-server-6

Continue with channel creation (y/n)?y

Cloning rhn-tools-rhel-x86_64-server-6 to testing-clone-rhn-tools-rhel-x86_64-server-6 with original package set.
Copying repodata, please wait.
Solving Dependencies (1): 
________________________________________
######################################## - complete
Processing Dependencies:
________________________________________
######################################## - complete

By continuing the following will be cloned:
  rhel-x86_64-server-6 -> stagging2-rhel-x86_64-server-6  (417/451 Errata)
  rhn-tools-rhel-x86_64-server-6 -> testing-clone-rhn-tools-rhel-x86_64-server-6  (23/23 Errata)

Continue with clone (y/n)?y

Cloning Errata into stagging2-rhel-x86_64-server-6 (417):
________________________________________
######################################## - complete
Cloning Errata into testing-clone-rhn-tools-rhel-x86_64-server-6 (23):
________________________________________
######################################## - complete
Copying repodata, please wait.
Solving Dependencies (1773): 
________________________________________
######################################## - complete
Processing Dependencies:
________________________________________
######################################## - complete


Here are can see that new parent channels is not created but custom parent channel also get updated along with the child channel from Red Hat provided channel. 

As here intention was to create clone of RHN tools channel only but we can see that parent channel also get updated with latest errata's. 

When we use command line option of passing channels with -l option and parent channel as -a option , here new errata's are not added to destination base channel. Bellow is output of spacewalk-clone-by-date command without configuration file

# spacewalk-clone-by-date -d 2013-04-01 -u admin -p redhat -l  rhn-tools-rhel-x86_64-server-6 testing-clone-2-rhn-tools-rhel-x86_64-server-6 -a  rhel-x86_64-server-6  stagging3-rhel-x86_64-server-6 
Reading repository information.

By continuing the following channels will be created: 
testing-clone-2-rhn-tools-rhel-x86_64-server-6

Continue with channel creation (y/n)?y

Cloning rhn-tools-rhel-x86_64-server-6 to testing-clone-2-rhn-tools-rhel-x86_64-server-6 with original package set.
Copying repodata, please wait.
Solving Dependencies (1): 
________________________________________
######################################## - complete
Processing Dependencies:
________________________________________
######################################## - complete

By continuing the following will be cloned:
  rhn-tools-rhel-x86_64-server-6 -> testing-clone-2-rhn-tools-rhel-x86_64-server-6  (23/23 Errata)

Continue with clone (y/n)?y

Cloning Errata into testing-clone-2-rhn-tools-rhel-x86_64-server-6 (23):
________________________________________
######################################## - complete
Copying repodata, please wait.
Solving Dependencies (35): 
________________________________________
######################################## - complete
Processing Dependencies:
________________________________________
######################################## - complete



Actual results:
Using spacewalk-clone-by-date with configuration file instead of command line parameters to clone child channel, it updates destination base channel along with cloning child channel.

Expected results:
Using spacewalk-clone-by-date with configuration file to clone child channel should not add any new errata to already existing destination base channel.

--- Additional comment from Clifford Perry on 2014-02-28 11:42:42 EST ---

From reviewing the man page for spacewalk-clone-by-date, including the example listed at the bottom of it: 

Clone a base channel and child channel to 2008-12-20 with a blacklist excluding all versions of squid, and all versions of any package that starts with 'sendmail'.

spacewalk-clone-by-date  --channels=rhel-x86_64-server-5 clone-rhel --channels=rhn-tools-rhel-x86_64-server-5 clone-tools --username admin --password redhat --to_date=2008-12-20 --blacklist=sendmail.*,squid


The behaviour should be, if you specify both the base and parent, then we will act on both base and parent for clone event to date provided. 
 - as such, I believe that the behaviour observed using the config file is correct, and the command line example listed in bug report (of difference of behaviour) is the incorrect behaviour. 

 - In any attempt to fix this though, we will need to carefully review past bug reports, since we may re-introduce a regression to someone else, based on how they perceive what is correct/expected behaviour. 

 - This may only be resolved by allowing both behaviours, where both remain default as is today, and new option is provided to flip to the other behaviour. 

Cliff

--- Additional comment from Stephen Herr on 2014-07-11 14:38:19 EDT ---

(In reply to Clifford Perry from comment #3)
>  - as such, I believe that the behaviour observed using the config file is
> correct,

Agreed.

> and the command line example listed in bug report (of difference of
> behaviour) is the incorrect behaviour. 

Disagree.

The entire purpose of the --parents option (as opposed to just using --channels) is that it is impossible to modify the base channel with --parents. The command line example is functioning as designed. There is no config file equivalent to the --parents option, as the man page states. An updated man page entry to make it more clear that this is expected behavior may be in order. The base functionality that is requested here - that there be a way to specify --parents through the config file - would therefor be an RFE, not a bug.

It is difficult to imagine what the config file equivalent to --parents should be, because:
1) The config file supports multiple channel trees, whereas all channels specified on the command line must correspond to a single channel tree (ie a single parent channel and potentially several channels that are children of that parent). Thus we cannot simply add a named global parameter like
"parents": {"original-parent-channel": "already-existing-cloned-parent-channel"}
because we would not know which channel tree it should apply to.

2) The channel listing already has variable size to accomodate channel name / summary / description specification. So you can specify a channel by either:
"rhel-x86_64-server-5": "my-rhel5-x86_64-clone" - labels only, no name etc.
or
"rhel-x86_64-server-5": ["my-rhel5-x86_64-clone",
                        "My Clone's Name", "This is my channel's summary",
                        "This is my channel's description"] - everything
or something in between:
"rhel-x86_64-server-5": ["my-rhel5-x86_64-clone",
                        "My Clone's Name"] - labels and name only

What exactly a string is is determined by it's position. So we can't just add another option on the end because then you can only specify it if you are also specifying name, summary, and description, which doesn't make any sense for an option meaning that you are not going to modify this channel.

3) Whatever we change, spacewalk-clone-by-date must continue to be able to read old config files. I suppose one possible implementation could be to specify the channel listing as a hash of key:value pairs instead of a list of position-sensitive strings, like so:
"rhel-x86_64-server-5": {"label": "my-rhel5-x86_64-clone",
                         "name": "My Clone's Name",
                         "summary": "This is my channel's summary",
                         "description": "This is my channel's description",
                         "do-not-modify": True]
Where the last row would allow us to switch between the --parents or --channels behavior. Actually now that I've thought of it I wish this was how I originally implemented the name / summary / description specification in the config file, as I think that makes a lot more sense. I was trying to make it as similar to the command-line implementation as possible but I like this better. This is a possibility, but makes backwards-compatibility with old config file formats harder.

4) The --parents option only makes sense to be associated with parent channels, but the config file makes no distinction between parent channels and child channels. Even if we did implement the suggestion in #3, what should we do if the user specifies it on a child channel? Ignore it and modify the child channel? Not make any changes to the child channel (and therefore there's no reason that entry should exist at all)? Throw an error? I think any of those are reasonable behaviors, probably throwing an error would be the safest thing to do.

Anyway, I hope that gives some background and understanding to why it is not currently possible to specify this option through the config file. If this is something we want to go ahead with then 1) it really should be an RFE and 2) I suggest we proceed with the implementation in #3.