Story #9316
Updated by dalley about 3 years ago
This used to be how things worked, then we changed how mirroring worked. But there are rare cases when metadata mirroring is not possible (see related issue) so we should add back a way to do this. edit: I have two ideas. They are not mutually exclusive, we could implement the first and then later move in the direction of the second without much trouble. Idea #1 ====== A simple extension of our current API. On the sync URL, we would support one additional parameter, which is only valid if mirror=True (else it will either do nothing, or fail to validate). Because it only adds a small option to the sync API and can be done on a plugin by plugin basis, there is no need for a migration. `mirror=False` means additive sync, the same as it does currently For `mirror=True mirror_type=$value`, a value of: 1. `mirror_type="original"` (or "exact") would signify metadata mirroring 1. `mirror_type="reproduction"` would signify content mirror (+ autopublish? *) + autopublish The exact (exact names of the modes are open for discussion. \* If all mirror modes functioned as though they did an immediate publish, it might allow Katello and RHUI to drop some separate codepaths. On the other hand it would carry the limitation that you can't do a content-only-mirror sync without publishing. discussion) Idea #2 ======= We deprecate the `mirror` option globally, and add a "sync_policy" option to replace it. This would work similarly to "download_policy" and would be a setting on the remote. Instead of being a boolean, many different options could be available, potentially customizable by the plugins. We would discourage using the `mirror` or `mirror_type` options to override this setting, although we would allow it for backwards compatibility. For metadata mirroring, content-only-mirroring, and additive sync respectively the options would be one of: 1. clone | mirror | replica | exact | exact_clone | exact_replica | exact_mirror 1. content_mirror | content_clone | inexact_clone | inexact_replica | inexact_mirror | reproduction 1. additive Because this involves changing the remote - probably the base remote class, this would require a migration and a more substantial time investment across plugins. Since more flexibility in function is allowed than `mirror_type`, it would be hard for this option to have consistent behavior re: ending with a publication. We could have options for with, and without.
.