[RFC] Test determinism for proposal.generate

[jschmid1]

Signed-off-by: Joshua Schmid [email protected]

Addresses #1215 ( Adding verify tests for this )

Description:

I'm not sure if that actually proves it. Please review thoroughly!

        Theory:
        The fear is that in a 'replace-disk' operation we _may_ end up with
        different osd - wal/db mappings than before. This would mean that
        a user will have to edit the profiles manually or face a migration.
        We never introduced pre-sorting of disk information that we get from
        hwinfo, which means that we can't guarantee a consistently sorted
        input.

        In order to test this, I try to do the following:

        1) Generate a profile
        2) 'replace' a disk ( replaced.disk() )
        2.1) Generate a 'new' disk ( suffixed with '_GENERATED' )
        2.2) Inject it a at a random index in the output from hwinfo
        2.3) Find the old, replaced disk to compare the wal/db pointer
        3) Compare the new and the old proposal for a match of
           old wal/db pointer and the new wal/db pointer

        To eliminate the factor of 'luck', repeat if 1000 times.

        Caveat:
          * Currently we are only testing if the newly replaced disk
            is matching it's old entry.
            Maybe we should test it for _every_ disk.
EDIT:    ->> I do. <<-
          * The number of repetitions could me reduced by adding more disks
            and therefore an increase in probability of a 'missplacement'
          * We have 3k tests more :/

---

Please find more information on how to run integration tests here

[jschmid1]

retest this please

[agraul]

I am still wrapping my head around to exact comparisons, will comment on them later.

[agraul]

As we discussed yesterday: this overwrites wal_db_replaced, turning it into a dict with prop_name as the key should be better.

[agraul]

This return is too early, only one disk_set in old_prop[prop_name] gets checked.

[agraul]

this is a bit misleading, hwinfo_out_new is not a copy hwinfo_out, just a second reference to the same list. It does not matter here because hwinfo_out is only used for the max index when inserting the new disk at a random spot, but can be confusing.

Since only one hwinfo_out is needed, we don't need to create a second reference. If we want to make the code easier to understand by having a second list, we can use list slicing to copy all values: hwinfo_out_new = hwinfo_out[:]

[jschmid1]

Adapting replacement "replacement procedure"

[jschmid1]

Closing this PR as we moved to another way of replacing disks. Introduced #1302