https://pulumi.com logo
Join Slack
Powered by
Hi All. So, it doesn't look like Pulumi supports G...
# general
r
Hi All. So, it doesn't look like Pulumi supports Google Cloud Redis Cluster. The docs outline: • 
google-native.redis/v1.Cluster
• 
gcp.redis.Cluster
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. 
nodeType
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.
d
It looks like nodeType was added in pulumi gcp v7.18, what version are you on?
r
I never specified a specific version so pulumi will use latest
d
Can you run 
pulumi about
to confirm
r
Copy code
Plugins
KIND      NAME           VERSION
resource  gcp            unknown
resource  google-native  unknown
language  yaml           unknown
So pulumi will infer latest from GitHub
d
That means it's not been able to determine the version installed, not that it'll use the latest
What language?
r
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
d
Cool. I'm not familiar with pulumi yaml, but the error suggests the provider is out of date
r
That's what I thought too - think AWS + Azure gets more love than GCP
Oh - I misread
d
It's worth specifying the version explicitly to rule it out
r
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
d
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
r
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.
d
I think provider versions is a lot more complex for yaml, as each resource can specify a version
r
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
cluster-ha:
    type: gcp:redis:Cluster
    properties:
      name: ha-cluster
      shardCount: 3
      pscConfigs:
        - network: ${producerNet.id}
      region: us-central1
      replicaCount: 1
      nodeType: REDIS_SHARED_CORE_NANO
      transitEncryptionMode: TRANSIT_ENCRYPTION_MODE_DISABLED
      authorizationMode: AUTH_MODE_DISABLED
d
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
Open in Slack
PreviousNext
Powered by