-
Notifications
You must be signed in to change notification settings - Fork 72
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
Fixes #27576 - config files backup fix #277
Conversation
Issues: #27576 |
Removed unnecessary && condition from below one as its not required,
|
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.
Thank you @upadhyeammit!
Added few comments. I haven't tested the changes yet.
def create_tarball | ||
(1..MAX_RETRIES).each do |ret| | ||
exit_status = run_tar_cmd | ||
break unless statuses.include? exit_status |
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.
exit_status
is used only in condition then why not to add run_tar_cmd
directly?
break unless statuses.include? exit_status | |
break unless statuses.include? run_tar_cmd |
Could you rename method run_tar_cmd
to execute_tar_cmd
?
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.
Yes we can, but I think we should keep exit_status so its good to understand that we are looking exit_status in array ? maybe I am wrong !
Recent commit keeps exit_status, request to add suggestions !
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.
Could you please give specific name to statuses
method?
Example - allowed_exit_statuses or allowed_exit_codes
.
As per me then after you can directly use method execute_tar_cmd
in the condition.
exit_status = run_tar_cmd | ||
break unless statuses.include? exit_status | ||
|
||
warn "\nRemoving config files archive #{tarball} as its incomplete" |
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.
Are we going to show warnings on every run if one fails?
As I haven't tested it but I would like to see difference between two outputs i.e using spinner.update
and using warn
.
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.
The current output with warn and warn!,
# bin/foreman-maintain advanced procedure run backup-config-files --backup-dir /tmp/
Running ForemanMaintain::Scenario
================================================================================
Backup config files:
/ Collecting config files to backup
Removing config files archive /tmp/config_files.tar.gz as its incomplete
Recollecting config files backup, retry 1 !
\ Collecting config files to backup
Removing config files archive /tmp/config_files.tar.gz as its incomplete
Recollecting config files backup, retry 2 !
/ Collecting config files to backup
Removing config files archive /tmp/config_files.tar.gz as its incomplete
Recollecting config files backup, retry 3 !
- If I use the spinner.update for "Removing config files archive /tmp/config_files.tar.gz as its incomplete"
# bin/foreman-maintain advanced procedure run backup-config-files --backup-dir /tmp/
Running ForemanMaintain::Scenario
================================================================================
Backup config files:
\
Removing config files archive /tmp/config_files.tar.gz as its incompleteRecollecting config files backup, retry 1 !
\
|
Removing config files archive /tmp/config_files.tar.gz as its incompleteRecollecting config files backup, retry 2 !
|
/
-
Removing config files archive /tmp/config_files.tar.gz as its incompleteRecollecting config files backup, retry 3 !
- As per this I thought of using it for "Recollecting config files backup, retry 3 !"
# bin/foreman-maintain advanced procedure run backup-config-files --backup-dir /tmp/
Running ForemanMaintain::Scenario
================================================================================
Backup config files:
-
-
-
\
|
|
|
/
-
-
Recollecting config files backup, retry 3 ! [FAIL]
- One more thing here is if I use spinner.update instead of warn! when MAX_RETRIES== ret ; the run show status as OK instead of FAILED, I tried to forcefully fail it by setting @status= :fail, @status =1 but it did not help to make it fail. If I am missing anything here then request to elaborate on same ?
warn! 'Config files backup failed' if MAX_RETRIES == ret
- I preferred to show warning at each run as its good to understand that we are deleting the failed backup and retrying again, so user is not confused anywhere.
In PR-269, @mbacovsky made code changes in the |
@mbacovsky I still feel that we should have sleep in-between each failed run because even for 3 runs it completes swiftly and so I feel this code wont add any value because config files wont be committed to disk. Maybe we can start with sleep = 2 seconds and double that for every failed run ? like 2, 4 and 8 seconds ? or maybe something else ? |
There were the following issues with the commit message:
If you don't have a ticket number, please create an issue in Redmine. More guidelines are available in Coding Standards or on the Foreman wiki. This message was auto-generated by Foreman's prprocessor |
1ccffc4
to
25a5860
Compare
@upadhyeammit, could you please rebase and update the pull-request. |
25a5860
to
ab4f651
Compare
end | ||
|
||
def statuses | ||
@ignore_changed_files ? [0, 1] : [0] |
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.
I can see tar feature has same statuses assignment, I have kept this one as its single line method. To call it from feature tar need to create method in that first, if it has benefit then will do changes accordingly.
done, request to check. Thank You ! |
@mbacovsky rebased this one, request to have a look once. Thank You ! |
def create_tarball | ||
(1..MAX_RETRIES).each do |ret| | ||
exit_status = run_tar_cmd | ||
break unless statuses.include? exit_status |
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.
Could you please give specific name to statuses
method?
Example - allowed_exit_statuses or allowed_exit_codes
.
As per me then after you can directly use method execute_tar_cmd
in the condition.
@kgaikwad changed method names ! request to check. |
def execute_tar_cmd | ||
@tarball_path ||= File.join(@backup_dir, 'config_files.tar.gz') | ||
@increments_path ||= File.join(@backup_dir, '.config.snar') | ||
configs, to_exclude = config_files |
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.
configs, to_exclude = config_files | |
configs, exclude_configs = config_files |
@jameerpathan111, mind testing these changes. |
|
fffb8fd
to
db0e679
Compare
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.
@upadhyeammit, @mbacovsky,
Do we still need to keep with_content?
method inside foreman_proxy
feature?
Can't we directly check the presence of pulp
feature inside two conditions i.e at line 24 and line 44
else | ||
attempt_no += 1 | ||
FileUtils.rm_rf(tarball_path) | ||
puts "We will re-try after #{RETRY_DELAY} seconds." |
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.
Instead of using we
, could you change a message something like -
puts "We will re-try after #{RETRY_DELAY} seconds." | |
puts "Waiting #{RETRY_DELAY} seconds before re-try." |
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.
@kgaikwad I think with_content? is useful information about the proxy and the proxy itself should be responsible for providing it. If we start to define content differently e.g. Pulp 3 has different feature or is not mandatory we want to have single place to update.
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.
Currently, inside with_content?
it just verifies the feature presence and method defined inside feature instance
at line 43 says foreman_proxy_with_content?
so I thought it's better to add condition there.
Secondly, with the different features for Pulp2 & Pulp3 and the suggested way on PR-290 it will resolve the concern. What do you think?
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.
IMO feature(:foreman_proxy).with_content?
and feature(:instance).foreman_proxy_with_content?
are two different things. The former tells if there is content managed with the proxy while the later tells if the machine is proxy with content only (no server). So I think both make sense to keep.
Further I'd suggest not to reduce with_content to with_pulp without revisiting the referencing code and checking what actually we are testing. I can imagine content proxy that is using remote pulp - it would still be content proxy but the current test will not be sufficient. If we need just pulp we should test for presence of pulp and not content proxy. Revisiting this is probably out of scope of this PR.
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.
Thank you @mbacovsky for giving pointers.
Because after seeing at the method, I was under an impression that it just checks the presence of pulp and didn't get the scope of it.
Nice suggestion, we could just check if pulp is there. Not sure whats coming up with Pulp 3, if its sort of node based where we can have pulp feature but not the content then this method should be useful. |
@kgaikwad I have fixed the message as per suggestion. Thank You ! |
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.
Thank you @upadhyeammit
ACK from my side except the comment mentioned related to with_content?
.
If everyone agree I don't mind to handle it separately in a different pull-request as not a part of an original issue.
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.
Looks good to merge, Thanks @upadhyeammit, @kgaikwad!
@lvrtelov do you want to give it another try before it is merged? |
I gave it a quick try :) I think it looks good and I also like the new message more. Tested with Satellite
Test cases
|
@lvrtelov, thanks a lot for testing this 🦄 ! |
This PR adds,
There is MAX_RETRIES constant which is max occurrences config file backup will be tried.
The create_tarball method which actually handles,
I have separated few methods to make it more simpler to understand.