Hi All. So, it doesn't look like Pulumi supports G...
# general
Hi All. So, it doesn't look like Pulumi supports Google Cloud Redis Cluster. The docs outline: •
Pulumi AI also calls out some examples - nevertheless - pulumi doesn't support Google Cloud Redis Cluster. One example using example here - pulumi cli outputs error:
Copy code
Property nodeType does not exist on 'gcp:redis/cluster:Cluster'
Other resource declarations do not cater for e.g.
Lastly, I want to ensure that pulumi is targeting Google Cloud Redis Cluster because I do need zero downtime h_scaling as opposed to, for example, memorystore for redis. Please can someone from the Pulumi Platform team help me get to the bottom of this.
It looks like nodeType was added in pulumi gcp v7.18, what version are you on?
I never specified a specific version so pulumi will use latest
Can you run
pulumi about
to confirm
Copy code
KIND      NAME           VERSION
resource  gcp            unknown
resource  google-native  unknown
language  yaml           unknown
So pulumi will infer latest from GitHub
That means it's not been able to determine the version installed, not that it'll use the latest
What language?
Let me provide some additional context:
I have built a GitOps framework using GitLab + Pulumi
I know from previous experience that if I don't explicitly specify the provider version (in the pulumi program/template) - that I'll hit errors as a function of GitHub's rate limits because of concurrent "pulumi up" pipelines running or a sizable number running sequentially in a short period of time.
So, normally, I explicitly specify the provider version. I have raised this issue separately with an Engineer called: Mitch Gerdisch
If you do not specify a specific version (and a version has not been installed locally) then pulumi will infer via github as a pre-processing task
runtime: YAML
Cool. I'm not familiar with pulumi yaml, but the error suggests the provider is out of date
That's what I thought too - think AWS + Azure gets more love than GCP
Oh - I misread
It's worth specifying the version explicitly to rule it out
There are many issues with the GCP Classic and native providers. Incomplete etc. I have already tried several declarations using online docs.
I'll give it a shot
Yeah the docs for gcp aren't great. I frequently had to fallback to reading the api reference docs in some cases. Actions between the cli, the console, and the api often don't look the same
Classic should be more complete since v7 though
Explicitly declared version: 7.21.1 (gcp classic) and it worked. Thanks @dry-keyboard-94795
Strange that
pulumi about
showed unknown for version. Clearly pulumi was using a locally installed version of the provider beforehand.
I think provider versions is a lot more complex for yaml, as each resource can specify a version
yep - funny thing is - I normally do explicitly declare the version for each resource block declaration. Well - I use stack referencing. This is to mitigate the github rate limit errors one gets via GitLab runners when running multi-project pipelines composed of multiple pulumi projects.
For the benefit of others who come across this post: Using the latest GCP Classic provider version results in a successful deploy for the follow example provider by pulumi:
Copy code
    type: gcp:redis:Cluster
      name: ha-cluster
      shardCount: 3
        - network: ${producerNet.id}
      region: us-central1
      replicaCount: 1
      authorizationMode: AUTH_MODE_DISABLED
Aye, for code use we enforce explicit providers, though that's more because some of our stacks deal with multiple accounts/orgs, so it's easier to standardise
It's a good practice to have