Skip to content
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

Merged
merged 12 commits into from
Nov 22, 2019

Conversation

upadhyeammit
Copy link
Contributor

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,

    • This will loop 3 times at max(MAX_RETRIES) if exit_status of the tar command does not include in statutes. The loop terminates when it finds exit_status in statuses array.
    • I am exiting the loop as per statuses because, I think we should only retry collecting tar when ignore_changed_files is false([0]), else it means user wants to continue execution even when tar is incomplete.
    • If the tar fails at third attempt I am not sure if I should skip deleting the tar archive or not ? current implementation deletes it because in this case user expects tar should be complete one.
    • It shows warning using warn! when the last time(3) tar command fails with exit status 1. This means the backup fails with error message.
  • I have separated few methods to make it more simpler to understand.

@theforeman-bot
Copy link
Member

Issues: #27576

@upadhyeammit
Copy link
Contributor Author

Removed unnecessary && condition from below one as its not required,

warn! 'Config files backup failed' if MAX_RETRIES == ret && !@ignore_changed_files

Copy link
Member

@kgaikwad kgaikwad left a 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
Copy link
Member

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?

Suggested change
break unless statuses.include? exit_status
break unless statuses.include? run_tar_cmd

Could you rename method run_tar_cmd to execute_tar_cmd?

Copy link
Contributor Author

@upadhyeammit upadhyeammit Aug 19, 2019

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 !

Copy link
Member

@kgaikwad kgaikwad Sep 3, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@upadhyeammit,

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.

definitions/procedures/backup/config_files.rb Outdated Show resolved Hide resolved
definitions/procedures/backup/config_files.rb Outdated Show resolved Hide resolved
definitions/procedures/backup/config_files.rb Outdated Show resolved Hide resolved
exit_status = run_tar_cmd
break unless statuses.include? exit_status

warn "\nRemoving config files archive #{tarball} as its incomplete"
Copy link
Member

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.

Copy link
Contributor Author

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.

@kgaikwad
Copy link
Member

kgaikwad commented Aug 14, 2019

@upadhyeammit,

In PR-269, @mbacovsky made code changes in the config_files procedure. My suggestion would be that you could add code changes once his PR get merged.

@upadhyeammit
Copy link
Contributor Author

@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 ?

@theforeman-bot
Copy link
Member

There were the following issues with the commit message:

  • 1ccffc4 must not be authored by vagrant or root user

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

@kgaikwad kgaikwad added the 0.4.x pull-requests targeted for next version 0.4.x label Aug 20, 2019
@kgaikwad
Copy link
Member

@upadhyeammit, could you please rebase and update the pull-request.

end

def statuses
@ignore_changed_files ? [0, 1] : [0]
Copy link
Contributor Author

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.

@upadhyeammit
Copy link
Contributor Author

@upadhyeammit, could you please rebase and update the pull-request.

done, request to check. Thank You !

@upadhyeammit
Copy link
Contributor Author

@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
Copy link
Member

@kgaikwad kgaikwad Sep 3, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@upadhyeammit,

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.

@upadhyeammit
Copy link
Contributor Author

@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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
configs, to_exclude = config_files
configs, exclude_configs = config_files

@kgaikwad
Copy link
Member

kgaikwad commented Sep 5, 2019

@jameerpathan111, mind testing these changes.

@jameerpathan111
Copy link
Contributor

@jameerpathan111, mind testing these changes.

@kgaikwad, @lvrtelov will be looking into this issue.

Copy link
Member

@kgaikwad kgaikwad left a 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."
Copy link
Member

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 -

Suggested change
puts "We will re-try after #{RETRY_DELAY} seconds."
puts "Waiting #{RETRY_DELAY} seconds before re-try."

Copy link
Member

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.

Copy link
Member

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?

Copy link
Member

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.

Copy link
Member

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.

@upadhyeammit
Copy link
Contributor Author

@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

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.

@upadhyeammit
Copy link
Contributor Author

@kgaikwad I have fixed the message as per suggestion. Thank You !

Copy link
Member

@kgaikwad kgaikwad left a 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.

Copy link
Member

@mbacovsky mbacovsky left a 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!

@mbacovsky
Copy link
Member

@lvrtelov do you want to give it another try before it is merged?

@lvrtelov
Copy link

I gave it a quick try :) I think it looks good and I also like the new message more.

Tested with Satellite

brand new set-up with foreman-maintain nightly + PR patch

Test cases

changing config -> failed backup
stable config -> successful backup
# foreman-maintain advanced procedure run backup-config-files --backup-dir /backup/
Running ForemanMaintain::Scenario
================================================================================
Backup config files: 
- Collecting config files to backup                                             
WARNING: Attempt 1/3 to collect all config files failed!
Some files were modified during creation of the archive.
Waiting 10 seconds before re-try
| Collecting config files to backup                                   [OK]      
--------------------------------------------------------------------------------

@mbacovsky
Copy link
Member

@lvrtelov, thanks a lot for testing this 🦄 !

@mbacovsky mbacovsky merged commit 25850e9 into theforeman:master Nov 22, 2019
@upadhyeammit upadhyeammit deleted the 27576-config-file branch December 3, 2021 12:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0.4.x pull-requests targeted for next version 0.4.x Needs testing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants