bbl destroy should be idempotent even if stack is missing

[robdimsdale]

see e.g. https://runtime.ci.cf-app.com/pipelines/cf-bosh-2-0/jobs/destroy-infrastructure/builds/2

I don't quite know what state the system was in before this build was run, but I would expect it to be idempotent and remove everything successfully.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/120842417

The labels on this github issue will be updated when the story is started.

[robdimsdale]

I re-ran the build, confirming the state.json is missing, and I get the same error. Maybe we just need to fail fast if the state file is missing?

[amitkgupta]

Thanks @robdimsdale

We have a story like this: https://www.pivotaltracker.com/story/show/116495635 which should make destroy re-entrant, so that it should work no matter what state your state.json was in. However, are you saying the problem here was simply a case where your state.json was missing entirely? I assume in this case bbl did indeed technically fail fast, but it did not fail with a clear error message about what's wrong, is that correct?

[Amit-PivotalLabs]

This raises an interesting question. To be idempotent, you should be able to run destroy twice. The second time you run it, there should be no state.json. Should it succeed, because it's idempotent, or fail, to indicate to the user that maybe they are running the command the first time against the wrong state-dir?

[robdimsdale]

@Amit-PivotalLabs yes I think the problem here was the state.json was missing - a different error message here should at least be helpful. I agree that it's hard to differentiate the situation where the state file was actually missing due to idempotence, vs the user misconfigured bbl.

One suggestion might be to add support for a -f/--force flag to exit successfully even if the state file cannot be found. You might want to print output stating that the state file couldn't be found but -f/--force means bbl will exit successfully anyway. That tells the user what bbl is thinking, which should help when the user misconfigures bbl by pointing it to the wrong state-dir but still allows idempotency.

[Amit-PivotalLabs]

We will support bbl destroy --skip-if-missing. bbl destroy fails if the state is missing, but with --skip-if-missing it should no-op instead (and exit 0).

[zankich]

This has been fixed in bbl 1.2