scanner: correct the autoProvision mechanism

[Vicente-Cheng]

- we should not set both `Spec.Filesystem.Provisioned` and
  `Spec.Provision` or the remove operation would be blocked if
  we only change one of these to false.

This is a side-effect that comes from 1877a4ef1743e4bb01b81179aacfe5b32da059ed.
For now, we will remove one of these two fields to ensure the delete operation
work. We still need mutator to help convert these two fields.

Problem:
The removal operation would be blocked if we only changed one of these to false.

Solution:
For now, we will remove one of these two fields to ensure the delete operation work.

Related Issue:

Test plan:

[Vicente-Cheng]

The CI will fail because the autoProvisioned behavior will be called on the current master code.

[tserong]

Shouldn't we remove bd.Spec.FileSystem.Provisioned = true and keep bd.Spec.Provision instead?

Also, there's another instance of this where we set both to true in updateDeviceStatus() in pkg/controller/blockdevice/controller.go

[Vicente-Cheng]

Shouldn't we remove bd.Spec.FileSystem.Provisioned = true and keep bd.Spec.Provision instead?

Both are ok to me.
I would like to keep bd.Spec.FileSystem.Provisioned = true because I want to align with the test case.
The current integration test still targets this field.

I am working on the mutator. After that, we can move the whole Spec.FileSystem.Provisioned to Spec.Provision
WDYT?

Also, there's another instance of this where we set both to true in updateDeviceStatus() in pkg/controller/blockdevice/controller.go

Nice catch, updated!

[tserong]

I am working on the mutator. After that, we can move the whole Spec.FileSystem.Provisioned to Spec.Provision
WDYT?

Cool, makes sense.

[Vicente-Cheng]

@Mergifyio backport v0.7.x

[mergify]

backport v0.7.x

✅ Backports have been created

• #148 scanner: correct the autoProvision mechanism (backport #147) has been created for branch v0.7.x