Description of problem: if in topology file device specified for brick has "dos" signature, cns-deploy will never finish due to that. Version-Release number of selected component (if applicable): cns-deploy-3.1.0-14.el7rhgs.x86_64 How reproducible: always Steps to Reproduce: 1. try to create cns cluster using devices with "dos" signature on them Actual results: cns-deploy hangs and never gets back Expected results: cns-deploy to finish. Inside pod there is run below command to create physical volume : # pvcreate --metadatasize=128M --dataalignment=256K /dev/sde if this very same command is executed on device with "dos" signature it will report back # pvcreate --metadatasize=128M --dataalignment=256K /dev/sde WARNING: dos signature detected on /dev/sde at offset 510. Wipe it? [y/n]: so it will wait, and will not by default delete "dos" signature. solution : - either run wipefs -a /dev/sdd - pvcreate -fy /dev/sdd I think it is fine to use these destructive commands as devices will be specified in topology file and it is responsibility of topology.json creator / owner to ensure it is correct. Additional info: NA
In my opinion, we should not force erase a disk with existing partition, but I agree that the command to error out and exit. Will work on this next release.
We might be able to fix this using the feature in https://github.com/kubernetes/kubernetes/pull/33366 . Should experiment.
https://github.com/heketi/heketi/pull/778
patch merged upstream.
This bugs has been sent to heketi-devel for further discussion. We may still be able to take this in for cns-3.10 if there is a quick agreement. http://lists.gluster.org/pipermail/heketi-devel/2018-May/000267.html
There has been an agreement that a --force option would be useful. When passing this option, the data on the device will be destroyed with 'wipefs --all'. Most likely the option will be called --destroy-existing-data so that users are warned about the potential danger of using it.
I've tried to create a CNS cluster using devices with dos signature on them. cns-deploy doesn't hang and continues with the deployment. Hence, moving this bug to verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:2686