Fixes #27534 - Allow migration of Dynflow data using prod2dev #6962
Conversation
|
Issues: #27534 |
|
Can't we use pure |
|
About arel, we could, but I didn't want to rewrite the migration script from scratch. About migration, by default foreman uses dynflow as a backend for active job. So it is possible to have dynflow and not have foreman-tasks. This means we also need to have the migration in core and not in tasks. |
|
Ack why here, thanks for explanation :)
Just it feels like it would have been less of a hassle... but I agree, if it works, do not touch it unless necessary. Another question though: If we do not have the dynflow, what is the rake task doing than? won't it create the dynflow tables anyways? |
What do you mean by this? We should always have dynflow tables on the source side. If not they will get created on the destination side, but will remain empty. |
Ah, I thought I can have foreman without dynflow, but it's always around. Sorry for the fuzz, going to test then 👍 |
| # dynflow:migrate migrates the db configured for the current rails env | ||
| # In this case, we need to make sure it migrates development | ||
| env_bak = ::Rails.env | ||
| Rake::Task['dynflow:migrate'].invoke |
There was a problem hiding this comment.
shouldn't this just run with development env? since we are always migrating production=>development.
There was a problem hiding this comment.
Well, we are always migrating production => development, regardless of what ::Rails.env is set to. dynflow:migrate is picky about this and always migrates the db associated with the current rails environment.
There was a problem hiding this comment.
can we move this to the mysql2pgsql task @lzap added? Or maybe it should be done as part of the db:migrate task?
| # In this case, we need to make sure it migrates development | ||
| env_bak = ::Rails.env | ||
| Rake::Task['dynflow:migrate'].invoke | ||
| ::Rails.env = env_bak |
There was a problem hiding this comment.
why do we need to do this? does the dynflow task modify the environment?
There was a problem hiding this comment.
We need to change the current environment to always migrate the db associated with development, regardless of what ::Rails.env is set to. It felt right to restore the previous value when we don't need it anymore
There was a problem hiding this comment.
where do we change that? iiuc this runs before the migration script
There was a problem hiding this comment.
Erm, now it is being done here https://github.com/theforeman/foreman/pull/6962/files#diff-e0bcc8a3c75fbb59b7937982b3fb59caR72
There was a problem hiding this comment.
Thanks @adamruzicka ! this needs a rebase though (but perhaps wait with that until GH-6974 is in)
|
Please rebase now that the other PR was merged. |
adamruzicka
force-pushed
the
dynflow-migration
branch
from
978137f
to
ba74bc3
Compare
|
Rebased |
This needs the user to run
rake dynflow:migrateagainst the target db before runningprod2dev.