-
Notifications
You must be signed in to change notification settings - Fork 51
Rip out all the code that implements VirtualMachine processing, older… #1474
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
Conversation
I think you forgot to add the migration that leads to schema revision 20250224221218 |
You also forgot to create a data migration to clean up old ApplicationRecord that no longer exist |
You have the scema migration but still don't have a data migration |
BrainPortal/db/schema.rb
Outdated
end | ||
|
||
create_table "tool_configs", force: :cascade, options: "ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_unicode_ci" do |t| | ||
create_table "tool_configs", force: :cascade, options: "ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci" do |t| |
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 tool_configs table's definition has changed; this happens when your dev DB is different from the one we use for the standard codebase. Just revert this line (450) with a manual commit.
Please add a data migration for your changes. I think maybe you don't know what it means. You now have two schema migrations, which changes the columns or tables of the database. But your pull request also remove some model classes and the database could still have records associated with the removed classes. This would make the system crash, if at any point those rows were accessed. So the database need also its DATA to migrated. Thus the data migration. This will be a migration that only has a |
I see you added a migration to destroy the objects in the table task_vm_allocations. That is useless given you're already dropping the entire table anyway! This is not at all what I was talking about in my comments. I was talking about modifying the database for objects that are other existing tables. Look at your PR and all the things it does, it should be obvious! What are you erasing/modifying that has impact on other things? I'll give you the info because it's doesn't seem clear to 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.
The data migration is still missing, see my previous comment.
Also, the migration that destroys objects in the task_vm_allocations table should be removed from this PR because it's useless.
Also, please test your data migration thoroughly by creating objects in the console and running it up and down. Make sure the migration really performs what you expect it to do. |
Please rebase and please add the missing migration, as I explained |
This PR looks good now. I will test it and merge it if everything is OK. |
Rip out all the code that implements VirtualMachine processing, older cloud related attributes in bourreaux and tool configs, ec2 etc.. see #1375 for discussion