[WIP]: Add a `failed_up_message` to complement to `post_up_message`

[timvisher]

Users of the Vagrantfiles that I have maintained have always had trouble spotting when vagrant has failed to create or provision a box. I've scripted around this in the past and emitted at various times a rocket ship blasting off for success and a mushroom cloud explosion for failure. This has always seemed to make it clearer to my users whether things worked or not or at least has allowed me to ask "Did you see the rocket ship?" rather than asking them whether the box creation worked or not.

I was excited recently to find the post_up_message configuration and started using that immediately, but I'd really like a complementary failed_up_message (not married to the name) that allowed me to specify what to do in the case of a failure.

This changeset should get that.

---

WIP:

• [x] Add the failed_up_message property to VagrantPlugins::Kernel_V2::VMConfig class.

• [ ] Use failed_up_message if applicable during error handling of reload and up. Both messages, IMHO, could be useful for provision as well but we don't need to open that can of worms just now as then the property name should likely change.

  Help Needed: I'm not actually sure how to do this. I don't see any error handling code in up/command.rb or reload/command.rb so I'm assuming that's somehow part of the framework here which may or may not make this harder than I thought it would be?

[timvisher]

Ping on this. :)

[timvisher]

Ping on this. :)

[timvisher]

Last ping on this then I'll guess I'll close it assuming we're not interested.

[chrisroberts]

I had a dig through the code to figure out how this could be implemented. It looks like it could be done with some adjustments in the command (to rescue exceptions for non-parallel runs and and customize the error with the failed message) and in the batch action runner.

My initial worry for a feature like this is that it would end up spawning requests for more logic and options to only show it for X errors, etc. But I am curious if you have looked at using an after up trigger to provide this type of behavior instead.

[timvisher]

@chrisroberts Thanks for the response! Having never heard of triggers before I have never attempted to use them for this purpose. I'll give them a go just as a stop gap.

I share your concerns about potential feature creep here. OTOH I think it would be fairly easy to document in the code or in the documentation that we provide these two symmetrical and simple options for the base cases and that you should otherwise look into triggers as mechanisms for more complex use cases.

With that in mind do you think this seems like something we should pursue as a feature (the failed_up_message property?) or if I can make it work via triggers do we not want a symmetrical option?

[timvisher]

@chrisroberts

Thanks again for the tip about using triggers. I've done some reading about them and it's not immediately obvious to me how they can be used to achieve this behavior.

Initially I was thinking that I'd use config.trigger.after :up, :reload. This indeed executes after each of the actions I care about, but…

Vagrant.configure("2") do |config|
  config.vm.box = "bento/ubuntu-20.04"
  config.vm.post_up_message = "yay"

  config.vm.provision "shell", inline: "false"

  config.trigger.after :up, :reload do |t|
    t.warn = "charnock"
  end
end

The triggers appear to not execute at all in the case of a failed provision which is exactly the situation I'd like to cover.

$ vagrant up --provision
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'bento/ubuntu-20.04' version '202012.23.0' is up to date...
==> default: Running provisioner: shell...
    default: Running: inline script
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

Even if they did trigger I don't appear to have any access to the 'state' of the run, i.e. whether it's currently suceeding or failing, which I think I'd need in order to be able to display a message only if the run is failing.

I also looked into the action hooks as a potential way to cover the behavior but they seem to suffer from the same limitations as the basic triggers, namely that they don't execute unless the hook was successful and/or they don't provide whether the run is failing or not.

Am I missing anything?

The irony here seems to be that hooks could be used for the post_up_message which is what we already have specially called out in the configuration but not for a failed_up_message like what this PR intends to provide. Extending hooks to be able to run while the run is failing or whatever might be a generically useful extension but it's also probably more work than I could hope to bite off at the moment.

[hashicorp-cla]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

---

Tim Visher seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you already have a GitHub account, please add the email address used for this commit to your account.

_{Have you signed the CLA already but the status is still pending? Recheck it.}