import pulumi
from pulumi_gcp import storage
bucket = "hof-io--develop-internal"
name = "pulumi/hack/condition.txt"
cond = False
msg = "running"
cnt = 0
while not cond:
cnt += 1
key = storage.get_bucket_object_content(name=name, bucket=bucket)
print(cnt, key.content)
if key.content == "exit":
msg = "hallo!"
break
pulumi.export('msg', msg)
pulumi.export('cnt', cnt)
769 exit
770 exit
771 exit
772 exit
773 exit
774 exit
775 exit
Outputs:
cnt: 775
msg: "hallo!"
Resources:
+ 1 to create
info: There are no resources in your stack (other than the stack resource).
Do you want to perform this update? [Use arrows to move, type to filter]
yes
> no
details
Of note, all but the last exit had a newline, until I `echo -n` the file I copied up
---
ooo...
348 what?!?!
349 what?!?!
350 what?!?!
351 what?!?!
352 what?!?!
353 what?!?!
354 what?!?!
355 what?!?!
356 what?!?!
357 what?!?!
358 what?!?!
359 exit
Outputs:
cnt: 359
msg: "hallo!"
Resources:
+ 1 created
Duration: 27s
I uploaded a different file while waiting to be asked to continue, and then proceeded to get different outputs
Note, while I can get the contents of a bucket in TF, I cannot build a loop around it as I have above
https://registry.terraform.io/providers/hashicorp/aws/latest...
TF might be susceptible to the same file contents manipulation between plan & apply as well, but then again, you can save a plan to a file and then run it later, so maybe not? Another experiment seems to be in order
1. Creating a resource where created is not the same as ready. This is extraordinarily common with compute resources (a virtual machine, a container, an HTTP server, a process) where attempting to create follow-up resources can result in costly retry-back-off loops. Even when creating Kubernetes resources, Pulumi will stand up an internet-connected deployment more quickly than many other tools because you can ensure the image is published before a pod references it, the pod is up before a service references it, and so on. (The Kubernetes provider bakes some of these awaits in by default.)
2. Resources graphs that are dynamic, reflecting external data sources at the moment of creation. Whether you want to write a Kubernetes operator, synchronize an LDAP directory to a SaaS product, or one of my favorite examples. When I set up demos, I often configure the authorized public IPs dynamically:
import * as publicIp from 'public-ip';
new someProvider.Kubernetes.Cluster('cluster',
{
apiServerAccessProfile: {
authorizedIPRanges: [await publicIp.v4()],
enablePrivateCluster: false,
},
}I'm telling you this is not how a potential user sees the same situation, that it is a disadvantage and was one of the reasons we are not making the switch.
This example above is exactly the kind of code we don't want in ops, it depends on the user environment and physical location at the time they run the command, bad practice. Thanks for an extra talking point though
The claim I keep seeing from Pulumi folks is that Pulumi is declarative, which is is not, as shown in multiple posts by many people. Please stop calling it such, it demonstrates dishonesty towards users
https://www.pulumi.com/registry/packages/gcp/api-docs/storag...