-
Notifications
You must be signed in to change notification settings - Fork 897
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 evm:db:dump:local and evm:db:dump:remote tasks #17483
Conversation
f1ed8cb
to
6116691
Compare
lib/evm_database_ops.rb
Outdated
# :username => 'samba_one', | ||
# :password => 'Zug-drep5s', | ||
# :remote_file_name => "backup_1", - Provide a base file name for the uploaded file | ||
private_class_method def self.run_db_opt_for_new_uri(db_opts, connect_opts = {}) |
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 method name is not great. I would prefer we refactor this into more pieces to make the individual operations more obvious. For example, with_mount_session
and check_free_space
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.
Not sure why this was squashed .. will copy the comment into a separate one.
end | ||
|
||
desc 'Dump the local ManageIQ EVM Database (VMDB) to a remote file' | ||
task :remote do |
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.
Do we need the restore for the dump side of things?
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.
Nope, this is handled in PostgresAdmin
:
Oddly enough, written by you: ManageIQ/manageiq-gems-pending@dbb78da
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.
Lol sorry, I read this as task :restore do
🤦♂️
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.
To be more clear, I was suggesting removing this task because I thought it was restoring a pg_dump which I don't really want to do unless it was an old backup (from before we removed it as a backup option).
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.
That is fair. Yeah, I really don't plan to support pg_dump
restores myself. I have a fun set of directions for importing DBs when working on performance issues and such, so me personally, I only really care about getting the pg_dump
stuff working from a "backup" perspective.
The fact that it "can work" in the :restore
tasks is just a nice plus.
lib/evm_database_ops.rb
Outdated
# :username => 'samba_one', | ||
# :password => 'Zug-drep5s', | ||
# :remote_file_name => "backup_1", - Provide a base file name for the uploaded file | ||
private_class_method def self.run_db_opt_for_new_uri(action, db_opts, connect_opts = {}) |
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 method name is not great. I would prefer we refactor this into more pieces to make the individual operations more obvious. For example, with_mount_session
and check_free_space
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.
Cool, yeah, I can look into doing that. I agree, the name sucks.
cc @jrafanie #namingIsHard #botherLJWheneverPossible
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 like naming things "run_things_and_stuff" to force myself to name it before merge. Sometimes, I leave it like that so someone else can provide a better 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.
For me this is the only thing holding this PR up. @NickLaMuro are you going to try to refactor this or are you just looking for naming 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.
@carbonin actively looking at this right now actually.
I think your naming suggestions are pretty solid, so probably just going to go with them, but I am noticing that half of what I would do for with_mount_session
is also needed for the EvmDatabaseOps.restore
method as well, so pondering how I can that in as well.
Since I am splitting things up a bit now (where before, it was just a copy-pasta for the most part), I am taking my time to do it right. This is the disadvantage of going the full refactoring route, where I original just kinda did it half way. Splitting this up via your suggestion is the overall better approach in my opinion, just has the cost of time to implement.
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.
Sounds good @NickLaMuro, just making sure 👍
A helper method that will be used in future commits. Also adds a few specs to validate log output.
a8630f2
to
56ad9f2
Compare
This methods is used to handle the session mount logic for the restore/backup methods in this class in a single spot. Note: merged_db_opts is used here in the log messages because db_opts is not mutated as part of with_mount_session, but we want to make sure we are logging the correct info. Putting the log statement inside the with_mount_session seemed like a bad idea, so rebuilding the calculated db_opts hash seemed like the least ugly workaround.
Moves out free_space calculation code from EvmDatabaseOps.backup into a helper method for later shared use.
Runs using the same setup as EvmDatabaseOps#backup, but runs a `pg_dump` under the hood. It uses the same method for determining if there is enough diskspace for the dump as the backup method. This isn't 100% accurate, but it should be "Good Enough™".
Effectively a carbon copy of the `:backup` namespace tasks.
Allows excluding of specific tables from the database dump that may not be necessary for the intended use.
56ad9f2
to
051a1f7
Compare
Some comments on commits NickLaMuro/manageiq@bf7e19f~...051a1f7 spec/lib/evm_database_ops_spec.rb
|
Checked commits NickLaMuro/manageiq@bf7e19f~...051a1f7 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0 lib/evm_database_ops.rb
lib/tasks/evm_dba.rake
|
Those |
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 great @NickLaMuro
Looking over all of this again I'm seeing a bunch of things that would be nice to fix up (I can't keep track of these options hashes at all), but this PR is definitely not the place for it.
Builds off of ManageIQ/manageiq-gems-pending#351 , which added
pg_dump
functionality back to thePostgresAdmin
lib, and creates rake tasks for running a database dump to either a local file, of NFS/SMB share.Notable changes
EvmDatabaseOps#backup
so thatEvmDatabaseOps#dump
can leverage almost all of the same code.evm:db:backup
tasks intoevm:db:dump
tasks.--exclude-table-data
from the dump for specific tablesLinks
Steps for Testing/QA
Not sure the best way to test that these work, but we probably should run some tests to confirm everything is behaving as expected. I will probably do some testing of this locally now that I have this up for review, and will report back with how I tested things for others to try as well.
Update: Here is what I did to test:
Found a db to dump on my local machine
Ran in the terminal:
$ rake evm:db:dump:local -- --local-file tmp/vmdb_db_dump --dbname my_vmdb
Checked the
log/evm.log
to see that the commands run made sense:Ran in the terminal:
Confirmed that the dump size was smaller and commands executed made sense: