fix: idempotence issue when binding fails to be added

[sergio-correia]

Enhancement:

Fix idempotence issue when binding fails to be added

Reason:

Sometimes, the role will not be able to add the required bindings, in which case it is expected to rollback and undo any change it has done.

In certain cases, the rollback was not performed correctly, and caused idempotence issues. We fix that by performing a backup of the LUKS header before doing the operations, so that we can properly restore it in the case the operation cannot be completed successfully.

Result:

The role now performs correctly and maintains the idempotence property in the cases where the binding failed to be added.

Issue Tracker Tickets (Jira or BZ if any): https://issues.redhat.com/browse/RHEL-84891

[rjeffman]

[citest]

[sergio-correia]

[citest]

[richm]

lgtm - how will we test this to ensure idempotence?

[richm]

lgtm - how will we test this to ensure idempotence?

@sergio-correia do you want to merge this now and work on testing later?

[richm]

@sergio-correia what should we do with this PR?

[richm]

for the dd command you'll need to add coreutils to __nbde_client_packages wherever it is defined, and to .ostree/packages-runtime.txt

otherwise, lgtm

[sergio-correia]

for the dd command you'll need to add coreutils to __nbde_client_packages wherever it is defined, and to .ostree/packages-runtime.txt

otherwise, lgtm

Thanks for taking another look. I updated the vars to include coreutils, however I am a bit lost as to the .ostree/packages-runtime.txt -- also, it would be great if those qemu tests ran properly; are those failures expected?

[richm]

for the dd command you'll need to add coreutils to __nbde_client_packages wherever it is defined, and to .ostree/packages-runtime.txt
otherwise, lgtm

Thanks for taking another look. I updated the vars to include coreutils, however I am a bit lost as to the .ostree/packages-runtime.txt

The format is one package per line in alphanum order - so just add it in a line between clevis-systemd and iproute

-- also, it would be great if those qemu tests ran properly; are those failures expected?

Yeah :-( working on it

[richm]

[citest]

[richm]

tests are failing because some test is not cleaning up after itself, causing the tests_bind_high_availability.yml to fail

[richm]

@sergio-correia sergio-correia#1

[richm]

[citest]

[richm]

sergio-correia#2

[richm]

[citest]

[richm]

[citest]