Proceed with destruction of other groups even if current failed

[mr0re1]

Motivation: to accommodate destruction of multi-group deployments where
non-last group failed to deploy.

• Add a prompt "Do you want to delete the next group %q [Y/n]?: ";
• Re-use --auto-approve flag.

Testing:

vars:
  project_id:  xxxx
  deployment_name: grifon

deployment_groups:
- group: a
  modules:
  - id: A
    source: /tools/identity
- group: b
  modules:
  - id: B
    source: /tools/identity
    use: [A]

(p311) @gigi:~/wp/hpc-toolkit (symphony_of_destruction %)$ ./ghpc create tst2.yaml
...
(p311) @gigi:~/wp/hpc-toolkit (symphony_of_destruction %)$ ./ghpc destroy grifon
collecting outputs for group "b" from group "a"
failed to import inputs for group "b": The configuration file "grifon/.ghpc/artifacts/a_outputs.tfvars" could not be read. - consider running "ghpc export-outputs grifon/a"
Initializing deployment group grifon/b
Testing if deployment group grifon/b requires destroying cloud infrastructure
failed to destroy group "b":
Error: exit status 1

Error: No value for required variable

  on variables.tf line 27:
  27: variable "value_A" {

The root module input variable "value_A" is not set, and has no default
value. Use a -var or -var-file command line argument to provide a value for
this variable.

Hint: terraform plan for deployment group grifon/b failed; run "ghpc export-outputs" on previous deployment groups to define inputs
Do you want to delete the next group "a" [Y/n]?:
Do you want to delete the next group "a" [Y/n]?: j
Do you want to delete the next group "a" [Y/n]?: n
destruction of "grifon" failed

(p311) @gigi:~/wp/hpc-toolkit (symphony_of_destruction %)$ ./ghpc destroy grifon
...
Do you want to delete the next group "a" [Y/n]?: y
Initializing deployment group grifon/a
Testing if deployment group grifon/a requires destroying cloud infrastructure
Cloud infrastructure in deployment group grifon/a is already destroyed

(p311) @gigi:~/wp/hpc-toolkit (symphony_of_destruction %)$ ./ghpc destroy grifon --auto-approve
...
failed to destroy group "b":
...
Testing if deployment group grifon/a requires destroying cloud infrastructure
Cloud infrastructure in deployment group grifon/a is already destroyed

[tpdownes]

I believe that the primary impact here will be to allow the destruction of the first N groups without any dependencies on preceding groups. For most blueprints, this will be the first group.

• Please fix the spelling of the function name
• The upper-case Y suggests to me that I should be able to enter empty string and get "Yes". In fact, it recycles the prompt.

I see 2 solutions for the 2nd point:

• "" == "y" (my preference)
• sed s,Y,y, ...

🤘

[tpdownes]

Additionally, the prompt should skip packer groups entirely.

[mr0re1]

Additionally, the prompt should skip packer groups entirely.

That would make a very implicit behavior, we still want to perform "destroy" them (deal with manifest), but in prompt output name of the next-non-packer group ? What if all "next" groups are packer ones, what to prompt for?

I would rather keep it as is , and hope for soon death of packer groups.

[tpdownes]

Additionally, the prompt should skip packer groups entirely.

That would make a very implicit behavior, we still want to perform "destroy" them (deal with manifest), but in prompt output name of the next-non-packer group ? What if all "next" groups are packer ones, what to prompt for?

I would rather keep it as is , and hope for soon death of packer groups.

Right now, the only action a Packer destroy takes is to print some very basic guidance to the user about how to manually delete the images. It doesn't prompt even without "--auto-approve. It seems to me that it's harmless to print those instructions no matter what. And, yes, IMO a blueprint that was all Packer modules should not generate any prompts (given our current level of support).

[tpdownes]

Based on offline discussion, I'm approving. I believe the prompt is not useful given current functionality for "packer destroy" but I think it will be useful in the future.