Missing configuration leads to poor errors about pulumi-gcp HOT 12 CLOSED

I believe @ellismg and @jen20 looked into this and concluded it isn't as easy as copying what we do in the AWS package, since you can set these on a per-resource basis.

This would be a very unfortunate conclusion. Here is a common experience with basic GCP programs, annotated with some of my own commentary/questions:

• Initialize a GCP project/stack.
• Run pulumi up:
  • Preview looks great! No errors. I hit "yes" to proceed.
  • The first GCP resource attempted to be created fails with an error, Plan apply failed: project: required field is not set
• As a new user, I have no idea how to proceed. Hopefully my tutorial tells me what to do. Google actually lands me on a bug from nearly one year ago where users were confused by this very thing!
  • Question: Why doesn't this use my default gcloud project? If I run gcloud info, it prints out the very project I want to use...
  • Eventually, I figure out to run pulumi config set gcp:project my-project
  • Question: Is there any way for the error message to tell me how to fix the problem?
• I rerun pulumi up:
  • Again, the preview looks great. I hit "yes".
  • Again a failure, and again minimal or obscure commentary on how to proceed: Plan apply failed: Cannot determine region: set in this resource, or set provider-level 'region' or 'zone'.
• Again, as a new user, I'm probably stumped. Sadly, for this one Googling doesn't help.
  • The solution is to set either the region or zone, using pulumi config set gcp:region us-east1.
  • Question: Is there any way for the error message to tell me how to fix the problem?

@ellismg I know you had feedback on the GCP getting started flow. I'm actually wondering whether this was a problem for others on the team, or whether our tutorials make it so you don't stumble here. (I'm always stumbling, but maybe I'm not paying close enough attention.) Thoughts?

Also /cc @swgillespie as I know improving errors is/was a passion of his, and I'm curious if he's ever looked into this sort of "error rewriting" we might need to do on the fly in order to improve these messages.

from pulumi-gcp.

we've been hit by it and it was confusing. I realise that upstream is not going to fix it,but it doesn't mean Pulumi can't do it's part. One way would be to do merging with ambient defaults on Pulumi side and always pass project to TF explicitly or error before even calling TF is project is not set.

from pulumi-gcp.

I actually just ran into this, and until I found this issue it wasn't at all clear what the issue way.

One thing that was very helpful with the AWS provider is that when a required field is missing, like the aws:region configuration option, you get a much more helpful error:

aws:s3:Bucket (bucket):
    error: 1 error occurred:
        * missing required configuration key "aws:region": The region where AWS operations will take place. Examples are us-east-1, us-west-2, etc.
    Set a value using the command `pulumi config set aws:region <value>`.

Can we at least make the error message clearer, or have the previous comments indicated why that isn't possible?

from pulumi-gcp.

@ellismg I know you had feedback on the GCP getting started flow. I'm actually wondering whether this was a problem for others on the team, or whether our tutorials make it so you don't stumble here. (I'm always stumbling, but maybe I'm not paying close enough attention.) Thoughts?

I did not specifically run into the project error, because I used pulumi new to create a new project using the gcp-typescript template and that flow prompted me for a project, so it gcp:project was always defined. I did hit the region/zone issue later when trying to add a serverless handler to my project, but the Cannot determine region: set in this resource, or set provider-level 'region' or 'zone'. text was sufficient enough for me to know what to do.

Regarding this:

Question: Why doesn't this use my default gcloud project? If I run gcloud info, it prints out the very project I want to use...

I have had the same question about the aws provider, where I have to set a region for every project, even though my default configuration for the AWS SDK on my machine says I want to use us-west-2.

I do wonder if the right path forward here is to further augment the configuration that would be passed to the tf provider after terraform has expanded its defaults but before we actually configure it. In that case, we could try to include information from other sources on the machine.

I'm curious if he's ever looked into this sort of "error rewriting" we might need to do on the fly in order to improve these messages.

Would it be possible to add some hooks in the bridge such that we could rewrite errors coming from the CRUD methods on the bridged provider before returning them? We could at least string sniff for stuff then and produce slightly nicer messages.

from pulumi-gcp.

@mikhailshilkov Did your recent improvements address this case?

from pulumi-gcp.

@lukehoban I believe you are referring to the open PR pulumi/pulumi-terraform#414

This issue is NOT fixed by that PR (as of its current state).

Update: I've figured out the config basics, so removed some questions. Working further...

There are several things on the way:

1. Azure location is a property of the resource with a default value pointing to the config value. I believe GCP project has a different configuration - one can't set it in the resource properties directly.

2. The GCP failure comes from a call to Create while Azure failure comes from a call to Check. I'd need to wrap the returned error after the call to p.tf.Apply too. That's doable after I understand how (1) should work. Can we make the preview fail too?

3. Small but unexpected thing: the property name is reported with quotes for Azure "location": required field is not set and without them for GCP project: required field is not set. So, I'd have to adjust the regex. Any idea about the reason?

from pulumi-gcp.

To answer my own questions, these errors come from the specific implementation of the Terraform Google provider: project error, region error, zone error.

I can add mappings from those hard-coded messages to our more descriptive errors pointing to pulumi config commands.

Do you think that would be enough here?

from pulumi-gcp.

I see - this is indeed subtly different than pulumi/pulumi-terraform#414.

Honestly a shame that upstream doesn't implement these requirements in Check - might be worth even contributing an upstream PR to move these checks forward into Check. At that point, we could almost use the existing mechanism to solve for this.

I can add mappings from those hard-coded messages to our more descriptive errors pointing to pulumi config commands. Do you think that would be enough here?

That does sound a little more unfortunate. In part, I'm not sure the errors come back in as structured of a way from Create, and also a shame to just have to do a blind grep for these messages in all errors from Create (at least in the GCP provider).

But not sure there is going to be any better option unfortunately unless upstream improves here. (Notably, all the problems noted in this thread are also problems for terraform users - so this really is a problem ideally solved in the upstream provider - whereas pulumi/pulumi-terraform#414 addresses a problem we introduced in the Pulumi provider).

from pulumi-gcp.

@lukehoban I started by creating hashicorp/terraform-provider-google#4071
Let me know if it's enough priority to give a try for a PR.

from pulumi-gcp.

Terraform said the upstream change is not feasible, so we are back to the next-best option of parsing Create errors...

from pulumi-gcp.

I honestly think at this point we should leave things as is. This really is an issue in the upstream provider, and if the upstream provider is unwilling to fix it, it's not clear we should be resorting to trying to clean up their error message post-hoc.

pulumi/pulumi-terraform#414 was quite different - as it was addressing a case where we had introduced a new behaviour in the Pulumi projection and so needed to massage error messages to be correct for Pulumi.

from pulumi-gcp.

One way would be to do merging with ambient defaults on Pulumi side and always pass project to TF explicitly or error before even calling TF is project is not set.

Could you share more details on how you would see this happening? How would this merging avoid the error message? (That error happens when the user fails to provide the project in either stack config or resource inputs).

from pulumi-gcp.