invenio-cli services setup --force should always work

[fenekku]

Running invenio-cli services setup --force will not work if the file with expected service status has them not setup. This happens on a first run or in actual inconsistent states where we do want to forcefully reset services (e.g. file says services not setup but some containers are running).

This is perhaps minor, but clashes with pre-existing experience with other tools that provide a --force option. As an administrator running that command, I expect it to always reset my services.

Describe the solution you'd like

The crux of the problem is here:

    def _cleanup(self):
        """Services cleanup steps."""
        steps = [
            # this shouldn't check if services are setup first because then --force can't always be used
            FunctionStep(func=self.services_expected_status,
                args={"expected": True},
                message="Checking services are setup..."
            ),

We would need the commands to be idempotent or to have FunctionStep allow the commands there to exit with error but continue to next FunctionStep.

[avivace]

@fenekku How does adding a "skippable" boolean option to FunctionStep sounds to you? It would allow the step to have errors but the "chain" to continue

[fenekku]

@avivace Yes, that sounds fair for now. It should be accompanied with a printing of the cause of the skip (just print the error).

In an ideal world, there would be:

• a dedicated invenio cache destroy command (so we clean up that ugly code)
• all destroy subcommands would be idempotent i.e. asking to destroy something already destroyed would not be an error
• the initial check if services were setup would be removed

Those points should be made into separate issues and tackled in the future (responsibility of other more general invenio modules). Could you do that (I may have created some of these tickets in the relevant modules)?

[avivace]

@fenekku Fair points, thanks for the insights.

Could you do that (I may have created some of these tickets in the relevant modules)?

Sorry I didn't quite get this. Should I open those issues or expect them to be already there?

Yes, that sounds fair for now.

Do you think the non-breaking "skippable" flag would be still useful in a scenario with a working invenio cache destroy command?

[fenekku]

Should I open those issues or expect them to be already there?

You should open them if they are not there :) . For instance this inveniosoftware/invenio-db#126 exists, so no need to create an issue for it. If the issues for the index and the cache don't exist, you can create them.

Do you think the non-breaking "skippable" flag would be still useful in a scenario with a working invenio cache destroy command?

If all commands are idempotent, then the skippable flag should not be needed. It's a tradeoff of efforts here, but if you want to be bold and do these changes in the different repositories I will back you :)