Tests that sync Puppet repositories.
Test whether Pulp can associate already-downloaded content with a repo.
Consider the following scenario:
- Create a repository with a feed and sync it.
- Create a second repository with the same feed and sync it.
When the second repository is synced, Pulp should recognize that the needed content units are already present, and it should associate them with the second repository. However, according to Pulp #1937, Pulp fails to do this, and the second repository will not be populated.
Create two repositories with the same feed, and sync them serially.
More specifically, this test creates two puppet repositories with identical feeds, syncs them serially, and verifies that both have equal non-zero content unit counts.
Test whether one can sync modules from the Puppet Forge.
According to Pulp #1846, Pulp sometimes fails to sync modules available on the Puppet forge. There is no consistency regarding which modules fail to sync: according to one comment, Pulp only detects 40 modules (of ~1,800), and according to another comment, Pulp syncs 4,089 of 4,128 modules.
How do we test this? The ideal test case is to repeatedly sync the entire Puppet Forge and check for sync failures, until the probability of another random failure is low. This is problematic: we’re abusing the Puppet Forge and extending the test time. A more realistic test is to sync a small number of modules and ensure that no errors occur. This provides much less assurance, but it does at least show that a sync from the Puppet Forge can complete.
The end result is a test case that syncs an unknown number of Puppet modules and which provides only minimal assurance that syncs from the Puppet Forge work. Unfortunately, we cannot do better.
Create a Puppet repository and trigger a sync.
Tell how many puppet modules are in a repository.
- server_config (pulp_smash.config.PulpSmashConfig) – Information about the Pulp server being targeted.
- repo_id – A Puppet repository ID.
The number of puppet modules in a repository, as an