-
Notifications
You must be signed in to change notification settings - Fork 125
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
Migrate evm dba #195
Migrate evm dba #195
Conversation
(transferred from ManageIQ/manageiq@705dae5)
(transferred from ManageIQ/manageiq@e2e46a2)
(transferred from ManageIQ/manageiq@2c76af7)
Changed this to use the CommandResult#error (transferred from ManageIQ/manageiq@5255d79)
Without this, running `rake db:migrate db:seed` in the same process can fail during seed with: `PG::UndefinedColumn: ERROR: column XYZ does not exist` We do exactly this, `rake db:migrate db:seed`, in bin/setup and bin/update. (transferred from ManageIQ/manageiq@23e8a33)
This reverts commit 23e8a333f25f9df4d416012ba08a901e1ab9830e. Fixed upstream in Rails now (transferred from ManageIQ/manageiq@2b02002)
(transferred from ManageIQ/manageiq@714af78)
(transferred from ManageIQ/manageiq@2a1402b)
This is no longer useful as we may use a hostname to connect to database servers that are actually running locally to "proxy" connections so we can easily switch in a failover scenario. Also we may run standby database servers when we are actually configured against a remote primary server. In that case we would want the local database to continue running even though we are not configured to use it. (transferred from ManageIQ/manageiq@c88a380)
db:reset resets the database to the current schema.rb. We as developers are probably running different branches with different migrations and ruby/rails versions, so we most likely want to be running all the migrations over again instead of just recreating from schema.rb. (transferred from ManageIQ/manageiq@29dd803)
…_event instead of manually adding request to MiqQueue (transferred from ManageIQ/manageiq@e0ac6ff)
(transferred from ManageIQ/manageiq@b18a3da)
These don't use systemd to start and stop the database, which we should be doing. Additionally get rid of unnecessary extra one-line methods. (transferred from ManageIQ/manageiq@af5ea8b)
We need the rails environment to access the VmdbDatabaseConnection model (transferred from ManageIQ/manageiq@4d7af02)
(transferred from ManageIQ/manageiq@d584c2c)
@Fryguy I'm not sure if I've corrupted any of the git config though in the process of doing this. |
Checked commits juliancheal/manageiq-schema@9fbfdaa~...d8dacc4 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0 lib/tasks/evm_dba.rake
|
end | ||
|
||
opts = opts.delete_if { |_k, v| v.nil? || v == false } | ||
EvmDatabaseOps.gc(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.
EvmDatabaseOps should probably come over as well.
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.
There are a handful of places where we use models in that file. Are we okay with those being in this repo?
hmm, I like the idea of moving things where they belong but there's something weird about moving gc/backup/restore/postgresql stop/start/database configuration/ etc. to a schema repo. They're only vaguely related in that they're for the same postgresql database. For example, why not bring over postgresql HA stuff, our pg stat activity stuff and other PG related things here? I can't say where they belong but it feels unrelated to schema. Perhaps the wrapper for reset and migrate as they're more schema related but the others don't seem to fit. |
This pull request has been automatically closed because it has not been updated for at least 6 months. Feel free to reopen this pull request if these changes are still valid. Thank you for all your contributions! |
Used my code extraction library to migrate over evm_dba.rake.
Fixes issue #3