Best practices for managing federated repositories?

[richardmcsong]

Hi!

I'm not entirely sure what the recommended pattern is to deploy artifactory configuration through terraform, especially as it pertains to federated repositories. Our context is that we have two artifactory clusters, with federated repositories to federate the artifacts between these clusters. We also use projects and environments to control the RBAC for these repositories.

Approach 1 - Status quo

We set up two parallel terraform pipelines: one to each artifactory cluster. However, because it seems like the creation of one repository in one cluster propagates over to the other cluster, the second pipeline to run fails with a

error when validating repository name: _____ : Case insensitive repository key already exists

Approach 2 - Modifying our current approach

As per our account manager, the intention is for the JFrog platform to handle the federation logic, even up to the creation of the repository on other clusters. So another approach could be: rip out all of the federated repository logic from our second cluster, and only have it applied/live on the first cluster.

However, our requirement for using projects and environments break under this approach: the federated creation does not create the repository under a particular project and environment. This means that when users go to use the second cluster, they will find that they won't have the same RBAC to these artifacts. In other words, because we use projects, we have to be able to control the specifics of how the second clusters' repositories get created, but we can't do that, since artifactory currently automatically propagates it over from the first cluster.

Approach 3 - Make federated creation/configuration optional

I noticed that the propagation logic was implemented in #825 and #840 via the terraform provider firing a configSync API call. If we make this optional, this may buy us enough time to get both created via terraform.

However, this causes yet another issue: do I ever need to invoke configSync? If both repositories are created separately, but I can guarantee that the configuration is correct, do I ever need to trigger a sync?

[alexhung]

@richardmcsong Thanks for the post. Approach 3 is in our plan to be implemented so that will give users more control over whether they want the sync to automatically happens or not. Adding a new attribute (auto_sync may be?) to control if configSync will be called after repo creation/update, and when set to false will allow you to apply same configuration to all nodes in the cluster and not gets the "repository key already exists" error. As long as your configuration is correct, both repos should be setup correctly without calling configSync API.

[alexhung]

@richardmcsong I did some more testing and experimenting and came to the conclusion that this issue can't be fixed by the Terraform provider.

Originally I thought part of the issue is that the provider calls the configSync API after repo creation/update to force the repos to synchronize across members. Thus, my thought is that if I make that API call optional then users can create federated repo on nodes separately.

Turns out the synchronization is done automatically by Artifactory even without the additional configSync API call. So when the provider creates the federated repo on node 1 (for example) with member on node 2, Artifactory will synchronize the configuration and create the same repo on node 2. So configSync was not necessary (was before Artifactory does the syncing).

This means that there's no way to fix or workaround this issue in the Terraform provider. This needs to be resolved by our Artifactory and Project teams. They are aware of this but I don't have any information on what the fix will be and when it will be rolled out.