Currently we either store what might be termed “sync options” on the remote, or else they can be specified on the sync API endpoint. Now it is not entirely obvious to me why for example
remote.policy (can be one of
streamed) is a remote option, but for example the pulp_rpm
sync_policy (can be one of
mirror_content_only) can only be specified at the time of the sync. Neither really tell us anything about the remote repository itself. I have also noticed that any sync options provided to the sync API endpoint at the time of the sync, tend to be extremely ephemeral. When using Pulp via Katello (for example), it can be pretty difficult to find out for certain if Katello really has passed some expected sync option to Pulp.
In summary I have two questions for discussion:
- Do we have some organizing principle for what should be a remote field, and what should be a sync API endpoint option?
- Do we want sync API endpoint options to be ephemeral, or should we systematically log or store them somewhere for debugging?
In some sense question 2 also applies to remotes, since the remotes can be changed after use, or the information what remote was used for a particular sync can be lost when the sync task is deleted (as old tasks eventually tend to be).