Updating details for physical switches

[saulotoledo]

Removes details from switches table, since due to later changes we can now use asset_details table to store the same information. We also add the part_number column to the asset details and rename the relationship in the hardwares table, since we will use physical_switches as the model in the core PR.

[saulotoledo]

@bdunne, @agrare, could you take a look in the lint?

I think I should not have to fix the Style/MethodCallWithArgsParentheses rule above. There is no commit in the project by using parentheses. Here is an example.

[agrare]

@saulotoledo don't worry about that something must be wrong with the rubocop exceptions in this repo, /cc @bdunne

[bdunne]

That's correct, I updated the ignored methods list in ManageIQ/guides#299

[saulotoledo]

@rodneyhbrown7, @agrare, @bdunne, I think this is ok for review.

[agrare]

You should be fine with switch_id here since the table is still called switches the fk should be switch_id. Physical_switches is just the name of the association

[saulotoledo]

@agrare Done

[agrare]

LGTM

[miq-bot]

Checked commit saulotoledo@055aa80 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
2 files checked, 0 offenses detected
Everything looks fine. 🍰

[gtanzillo]

@Fryguy You ok with merging this one?

[Fryguy]

@saulotoledo Is there a corresponding PR where the callers of these columns are changed such that they are no longer used? I'm concerned that if I merge, then master will be broken.

[agrare]

@Fryguy ManageIQ/manageiq-providers-lenovo#132 updates the parser to work with the new columns

[Fryguy]

@agrare So that means that ManageIQ/manageiq-providers-lenovo#132 needs to merged in tandem with this one?

[saulotoledo]

@Fryguy @agrare It is safe to merge this one. The only code who uses these columns is ManageIQ/manageiq-providers-lenovo#132, so this one needs to be merged first. These colums were created by me on #160 and are only used in my PRs (provider and UI on WIP state yet).

Also, there is no need to merge them at the same time, because there is no code in the provider that can break.

[gtanzillo]

@saulotoledo We're (me and @Fryguy) ready to merge this PR but, we just need to know for certain that the columns that you're removing here are NOT referenced in any other code, including ManageIQ/manageiq-providers-lenovo#132

+    remove_column :switches, :product_name,  :string
+    remove_column :switches, :part_number,   :string
+    remove_column :switches, :serial_number, :string
+    remove_column :switches, :description,   :string
+    remove_column :switches, :manufacturer,  :string

Please confirm, thanks

[saulotoledo]

@gtanzillo @Fryguy @rodneyhbrown7 Yes, I confirm that.

The long answer: I created them to work in that PR only, but the same colums were created into asset_details table in another PR meanwhile. I just updated the ManageIQ/manageiq-providers-lenovo#132 code to use the asset_details table and those columns are not necessary anymore. There is no other place using them, not even the ManageIQ/manageiq-providers-lenovo#132 code.

[Fryguy]

@saulotoledo I guess what Greg and I are asking is, if we merge the schema change, does the code in master currently use those removed columns, which could lead to a crash on the master? Or, do I have to merge ManageIQ/manageiq-providers-lenovo#132 into master simulatenously as I merge the schema change?

[rodneyhbrown7]

@Fryguy There is currently no code that is using the columns that are being removed. Those columns were added but no code was developed to put data into the column.

ManageIQ/manageiq-providers-lenovo#132 is dependent on the addition of the asset_details column in this PR. It was decided to add the data to that table instead of adding the data to the native columns here, so we are requesting removal of the unused columns.

[saulotoledo]

@Fryguy @gtanzillo Yes, I am trying to say what @rodneyhbrown7 said. Sorry for the misunderstanding.

[Fryguy]

Great. Thanks for the clarification.