-
Notifications
You must be signed in to change notification settings - Fork 224
Uyuni config auto repo sync #10897
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
base: master
Are you sure you want to change the base?
Uyuni config auto repo sync #10897
Conversation
|
👋 Hello! Thanks for contributing to our project. You can see the progress at the end of this page and at https://github.com/uyuni-project/uyuni/pull/10897/checks If you are unsure the failing tests are related to your code, you can check the "reference jobs". These are jobs that run on a scheduled time with code from master. If they fail for the same reason as your build, it means the tests or the infrastructure are broken. If they do not fail, but yours do, it means it is related to your code. Reference tests: KNOWN ISSUES Sometimes the build can fail when pulling new jar files from download.opensuse.org . This is a known limitation. Given this happens rarely, when it does, all you need to do is rerun the test. Sorry for the inconvenience. For more tips on troubleshooting, see the troubleshooting guide. Happy hacking! |
f43d60f to
36b5342
Compare
|
I have a problem to understand the background of this and what you want to achieve.
Now an auto_sync configuration is added. I think you can only change it when it is a custom channel. Is it planned to make this configurable for vendor channels as well? |
36b5342 to
727fe33
Compare
@mcalmer, my goal with these changes is to allow for the configuration in any channel, vendor and custom ones. My idea is that some channels may not need to get updates during the night, even vendor ones (think about the pool channels, for example). By synchronizing it, we are putting a load on the server for the mgr_sync task and the repo metadata generation task (even if no packages get downloaded). This way, we can skip individual channels and reduce the load. Another topic that we can look at, is skip channel metadata generation if no packages have changed, which would also reduce the load. Michael, any thoughts on this? |
java/code/src/com/redhat/rhn/domain/channel/ChannelFactory.java
Outdated
Show resolved
Hide resolved
727fe33 to
2b0f238
Compare
|
Thank you for the review @mackdk , I think I have addressed all the comments. Cheers |
5b912ac to
05c9155
Compare
mackdk
left a comment
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.
LGTM. Not sure why SonarCloud is picking so many errors on unrelated files though
Implement support to disable automatic repository synchronization on taskomatic mgrsync task. Signed-off-by: Ricardo Mateus <[email protected]>
05c9155 to
d31dcd9
Compare
|
@mackdk sorry to trigger the review again but I have forced push the name of the sql script and that cleared the approval. |
|
@admd should I port this PR to 5.1? Or should it land only in uyuni and later in 5.2? |
What does this PR change?
Allow configuration at channel level if it should be picked by the recurrent taskomatic mgr-sync, which run synchronization once per day.
Channels can still be synchronized manually by users if needed.
The synchronization status is shown in the UI. Changing the flag is only available through the API.
This feature is useful because it allows disble outsync on some channels that know they will not receive any more updates, like the pool channels.
GUI diff
No difference.
Before:
After:

Documentation
No documentation needed: It will need documentation on how tho use it.
No documentation needed: only internal and user invisible changes
Documentation issue was created: Link for SUSE Multi-Linux Manager contributors, Link for community contributors.
API documentation added: please review the Wiki page Writing Documentation for the API if you have any changes to API documentation.
(OPTIONAL) Documentation PR
DONE
Test coverage
ℹ️ If a major new functionality is added, it is strongly recommended that tests for the new functionality are added to the Cucumber test suite
No tests: add explanation
No tests: already covered
Unit tests were added
Cucumber tests were added
DONE
Links
Issue(s): #
Port(s): # add downstream PR(s), if any
Changelogs
Make sure the changelogs entries you are adding are compliant with https://github.com/uyuni-project/uyuni/wiki/Contributing#changelogs and https://github.com/uyuni-project/uyuni/wiki/Contributing#uyuni-projectuyuni-repository
If you don't need a changelog check, please mark this checkbox:
If you uncheck the checkbox after the PR is created, you will need to re-run
changelog_test(see below)Re-run a test
If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run:
Before you merge
Check How to branch and merge properly!