Skip to content
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

Fix resetting proposal settings #889

Merged
merged 10 commits into from Apr 4, 2019

Conversation

dgdavid
Copy link
Member

@dgdavid dgdavid commented Apr 3, 2019

Problem

Initial settings are not being restored before each proposal attempt because

Yast.deep_copy is quite a fail that only copies one level, leaving the second level as references instead of copies. — extracted from Ancor's comment

See also,

Solution

Overwrite the ProposalSettings#dup Added a ProposalSettings#deep_copy method to make a copy based on a Marshal serialization instead of use Yast.deep_copy because

It did its job with the YCP -> Ruby translation, but it should never be used in new code because it does not do what it promises. We should use Ruby mechanisms for performing deep copies, such as Marshall. — extracted from Ancor's comment

Testing

  • Added a new unit tests
  • Fixed some existing tests

@dgdavid dgdavid force-pushed the feature/bsc-1130392-fix-reset-proposal-settings branch from 6c981bf to 15d4fb0 Compare April 3, 2019 07:33
@dgdavid dgdavid changed the title Feature/bsc 1130392 fix reset proposal settings [WIP] Fix reset proposal settings Apr 3, 2019
@dgdavid dgdavid force-pushed the feature/bsc-1130392-fix-reset-proposal-settings branch 2 times, most recently from a92c6b3 to fdb2724 Compare April 3, 2019 08:56
@dgdavid dgdavid changed the title [WIP] Fix reset proposal settings Fix reseting proposal settings Apr 3, 2019
@dgdavid dgdavid changed the title Fix reseting proposal settings Fix resetting proposal settings Apr 3, 2019
@dgdavid dgdavid force-pushed the feature/bsc-1130392-fix-reset-proposal-settings branch from fdb2724 to 00bc177 Compare April 3, 2019 09:21
src/lib/y2storage/proposal_settings.rb Outdated Show resolved Hide resolved
src/lib/y2storage/initial_guided_proposal.rb Outdated Show resolved Hide resolved
@dgdavid dgdavid force-pushed the feature/bsc-1130392-fix-reset-proposal-settings branch from ebe3607 to 89d70fb Compare April 3, 2019 10:15
package/yast2-storage-ng.changes Outdated Show resolved Hide resolved
test/y2storage/proposal_settings_test.rb Outdated Show resolved Hide resolved
test/y2storage/proposal/settings_generator/ng_test.rb Outdated Show resolved Hide resolved
@dgdavid dgdavid force-pushed the feature/bsc-1130392-fix-reset-proposal-settings branch from 89a93ce to 54987c0 Compare April 3, 2019 14:30
Copy link
Member

@lslezak lslezak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks OK, but I'd leave the final approval on @ancorgs 😉

Copy link
Contributor

@ancorgs ancorgs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree the #to_s based tests may look a bit weird, but I don't think it makes the situation any worse than it was with those tests. So LGTM

@lslezak
Copy link
Member

lslezak commented Apr 3, 2019

Yes, looks better to me.

src/lib/y2storage/proposal_settings.rb Outdated Show resolved Hide resolved
test/y2storage/proposal_settings_test.rb Outdated Show resolved Hide resolved
@joseivanlopez
Copy link
Contributor

joseivanlopez commented Apr 3, 2019

I see some tests are starting to fail because "singleton can't be dumped". I suspect this is happening because "double" objects cannot be marshaled. Maybe we can fix it by replacing double by instance_double, for example here https://github.com/yast/yast-storage-ng/blob/master/test/y2storage/dialogs/guided_setup/select_filesystem/ng_test.rb#L38

Or even better, we can avoid doubles at all, and simply create "real" VolumeSpecification objects.

@dgdavid dgdavid force-pushed the feature/bsc-1130392-fix-reset-proposal-settings branch from a75490e to aa372fe Compare April 4, 2019 06:52
@dgdavid
Copy link
Member Author

dgdavid commented Apr 4, 2019

@joseivanlopez

Thank you for your feedback.

I already updated the PR with your suggestions, but I fix those tests that are failing. Using instance_double do not fix them.

@joseivanlopez
Copy link
Contributor

@dgdavid I was not sure about that solution (I was only guessing). First of all, we have to be sure that the problem is the combination of Marshall + mocking. This can be easily checked. And if we confirm that, then we have 3 options:

a) try to use real VolumeSpecification objects in tests, although I don't like it because we force to always use real settings.
b) do not redefine ProposalSettings#==. The problem I see with this is that settings == settings.dup but settings != settings.deep_copy.
c) do not use Marshal to redefine ProposalSettings#==, but maybe a good solution would require too much effort.

So, if finally the problem is Marshal + mocking, IMHO I would go with option b) iff settings != settings.deep_copy is not a problem (not sure if this could affect in some parts of the code).

@ancorgs How do you see it?

@ancorgs
Copy link
Contributor

ancorgs commented Apr 4, 2019

I wouldn't redefine ProposalSettings#== just to have nicer tests. That's a change with potentially many implications, definitely not something to do in the SLE-15-SP1 branch at this point in time.

Fixing the deep dup is the further I would go.

@dgdavid
Copy link
Member Author

dgdavid commented Apr 4, 2019

@joseivanlopez, @ancorgs

So, I'll undo the latest changes and keep the PR as it was 20 hours ago. ProposalSettings#== redefinition. — (edited after a chat with @joseivanlopez ;)).

Thank you!

@dgdavid dgdavid force-pushed the feature/bsc-1130392-fix-reset-proposal-settings branch 2 times, most recently from 8adfcd3 to 3a01573 Compare April 4, 2019 11:45
dgdavid and others added 10 commits April 4, 2019 12:53
Based on a Marshal (de)serialization.
The default #dup creates a shallow and we were changing the semantic.
Renaming it to a `deep_copy` is more consistent with its behavior.
Co-Authored-By: David Díaz González <dgonzalez@suse.de>
After changes done in SettingsGenerator, InitialGuidedProposal does not
need to copy the original settings. Keeping a reference to them is
enough.
Based on suggestions from code review

Co-Authored-By: José Iván López González <jlopez@suse.com>
@dgdavid dgdavid force-pushed the feature/bsc-1130392-fix-reset-proposal-settings branch from 3a01573 to cdfced4 Compare April 4, 2019 11:56
Copy link
Contributor

@joseivanlopez joseivanlopez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@dgdavid dgdavid merged commit 042eef9 into SLE-15-SP1 Apr 4, 2019
@dgdavid dgdavid deleted the feature/bsc-1130392-fix-reset-proposal-settings branch April 4, 2019 12:03
@coveralls
Copy link

Coverage Status

Coverage increased (+0.0003%) to 97.378% when pulling cdfced4 on feature/bsc-1130392-fix-reset-proposal-settings into 5518494 on SLE-15-SP1.

@dgdavid dgdavid mentioned this pull request Apr 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants