-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add repo sync option #1127
base: develop
Are you sure you want to change the base?
Add repo sync option #1127
Conversation
There was a discussion, at length, in the original role PR (#1027) around this. In that PR, we avoided this as we landed on introducing a role for syncing rather than baking it into the repositories role. That would avoid duplicated logic (as a role for syncing is certainly useful) and would allow users to compose functionality to their desire. And the repositories role could potentially import the role if we went that route DRYing things up. |
@ehelms updated PR to introduce a new role rather than an extension to the existing role. |
AI: @evgeni wants to link the old issue where the |
Hey @willtome, we had the Is there a possibility to batch those syncs better? Like "only do X" at a time? |
validate_certs: "{{ validate_certs | default(omit) }}" | ||
organization: "{{ organization }}" | ||
product: "{{ item.0.name }}" | ||
repository: "{{ item.1.name }}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you omit repository
the module will sync the whole product, which in most cases is what the user wants to do anyways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we go for the batching, we might want to iterate over the repositories to even out the load better.
If we do one product at a time, this might just be the easiest approach to batching.
Just my two thoughts here...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, agree, "by product" is probably the cheapest batching we can get
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. Will update to just sync by product and not async. Can an issue be opened to better queue requests in foreman? At the end of the day, it really shouldn't be the automation's responsibility to batch requests and manage load for the system.
product: "{{ item.0.name }}" | ||
repository: "{{ item.1.name }}" | ||
with_subelements: | ||
- "{{ products | selectattr('repository_sets', 'defined') | list }}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this means it won't sync any custom repositories that the repositories
role can create.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this needs tests -- do you know how to record those, or do you need help with them?
product: "{{ item.0.name }}" | ||
with_subelements: | ||
- "{{ products | selectattr('repository_sets', 'defined') | list }}" | ||
- repository_sets | ||
when: item.0.sync | default(false) | bool |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
product: "{{ item.0.name }}" | |
with_subelements: | |
- "{{ products | selectattr('repository_sets', 'defined') | list }}" | |
- repository_sets | |
when: item.0.sync | default(false) | bool | |
product: "{{ item.name }}" | |
loop: "{{ products }}" | |
when: item.sync | default(false) | bool |
There is no need to iterate over the repositories anymore, as we're syncing by-product now.
Also loop over all products, regardless of repository_sets
(RH repos) or repositories
(custom repos) attributes.
@@ -81,4 +81,4 @@ | |||
verify_ssl_on_sync: "{{ item.1.verify_ssl_on_sync | default(omit) }}" | |||
with_subelements: | |||
- "{{ products | selectattr('repositories', 'defined') | list }}" | |||
- repositories | |||
- repositories |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks unrelated and unneeded?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @willtome , thanks for the PR!
could you add some tests to this role? The documentation at https://theforeman.github.io/foreman-ansible-modules/develop/testing.html is really helpful for this
In short, what you need is a test playbook tests/test_playbooks/repositories_sync_role.yml
and an apidoc fixture tests/fixtures/apidoc/repositories_sync_role.json
which should just be a symlink to katello.json
in the same dir
To record the test fixtures, there is a little first time setup: make test-setup
and then edit tests/test_playbooks/vars/server.yml
to point to your katello server. Once that setup is complete make record_repositories_sync_role
would then record the fixtures.
You can look at the PRs for other roles to get an idea how to do this, or please feel free to reach out any time if you have any questions
This PR adds the option
sync
to the repositories data structure to allow for an on-demand sync of a product when it is enabled. I believe this should be added to the current repositories role because it uses the same variable. The default behavior is not to sync. Ifsync: true
the repos for that product will be synced. This is achieved using async operations so that multiple repos can be synced simultaneously.closes #1119