Uploaded image for project: 'Artifactory Binary Repository'
  1. Artifactory Binary Repository
  2. RTFACT-19040

Provide an option to prevent event based replication based on origin of the upload

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open
    • Priority: High
    • Resolution: Unresolved
    • Affects Version/s: 5.8.9
    • Fix Version/s: None
    • Component/s: Replication
    • Labels:

      Description

      Artifactory should provide an option for preventing event based replication when an artifact is uploaded from another artifactory.

      This feature can significantly simplify full mesh topology setup since each site can have a single local repository name used, without running into infinite cyclic replication issue (cluster A replication uploads to B and C, Cluster B triggers event based replication to A and C; B to A and C....).

      This feature can help:

      1. Significantly simplify full mesh set up by reducing number of repositories (66% reduction - 1 repo instead of 1 virtual, 2 locals) and associated permission targets (e.g. needed just for one local repo instead of two local repos) created
      2. reduce complexity of coming up with different naming convention (repo named A replicates to repo named A)
      3. reduce complexity in setting up Access Federation where each cluster may have different permissions due to repo name
      4. reduce the need to deal with "latest tag" or common path issue (e.g. latest tag uploaded to cluster A and C's local repositories. Which latest is the latest when it is downloaded from a virtual repo that contains local repo and a repo used for receiving replicated artifact?)
      5. prevent issue that rises for a package type that does not yet support virtual repo (e.g. RTFACT-9130). Current model doesn't work without a virtual repo.
      6. allow sync-delete (if using full mesh). Current model doesn't propagate a local deletion, leaving massive number of artifacts that exists on remote clusters over time
      7. simplify DR setup, as there can be no need to manually switch over replication from one way to another. Just keep the replication going between the source and the target, bidirectionally, all the time 

      A sample diagram of full mesh setup that can be supported if this Jira is resolved.

       

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              rotemk Rotem Kfir
              Reporter:
              joshuah Joshua Han
              Votes:
              2 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated: