[verdverm]

We just went back to TF after giving Pulumi a try. Prefer declarative syntax for infra and more abuse of Yaml ("fn::..." here) is not what I'm after.

We are working on wrapping TF in CUE since you can CUE->JSON->TF

https://github.com/hofstadter-io/cuelm

Many more CUE experiments are going on in the devops space

[AaronFriel]

Pulumi has a few languages other than YAML and Pulumi is declarative[1], and the programs you write are only as complex as you want them to be. This python program declares an S3 bucket and declares ten objects to exist in it.

    from pulumi_aws import s3

    bucket = s3.Bucket('bucket')

    for i in range(10):
        s3.BucketObject(
            f'object-{i}',
            s3.BucketObjectArgs(
                bucket=bucket.id,
                key=str(i),
            )
        )

Even so, Pulumi YAML has a "compiler" option, so if you want to write CUE or jsonnet[1], or other[2] languages, it definitely supports that.

Disclaimer: I led the YAML project and added the compiler feature at the request of some folks internally looking for CUE support :)

[1] https://www.pulumi.com/blog/pulumi-is-imperative-declarative...

[2] https://www.pulumi.com/blog/extending-pulumi-languages-with-...

[3] https://leebriggs.co.uk/blog/2022/05/04/deploying-kubernetes...

[verdverm]

I'm aware of the SDKs, but we don't want them because they are an imperative interface, no matter how you want to spin it as "declarative". I have access to all the imperative constructs in the underlying language and can create conditional execution without restriction.

Even if I use the Yaml compiler for CUE (which we did) I still have to write `fn::` strings as keys, which is ugly and not the direction our industry should go. Let's stop putting imperative constructs into string, let's use a better language for configuration, something purpose built, not an SDK in an imperative language. These "fn::" strings are just bringing imperative constructs back into what could have been an actual declarative interface. Note, Pulumi is not alone here, there are lots of people hacking Yaml because they don't know what else there is to do. CEL making it's way to k8s is another specific example.

This cannot be the state-of-art in ops, we can do much better, but I get that Pulumi is trying to reach a different set of users than devops and will end up with different choices and tradeoffs

(I maintain https://cuetorials.com and am very active in the CUE community)

[lmm]

An imperative for loop is somehow declarative now? Lol.

[jjnoakes]

This seems extremely dismissive and shallow.

The imperative part of that code appears to be analogous to templating. The actual work done under the covers is not imperative, but is based on the difference between the result of the template execution and the current state of the system. That's what makes it declarative.

[verdverm]

It really depends on the interaction between the user's Pulumi script and the Pulumi engine.

If there is more than one back and forth, you become declarative, even if you imperatively generate a "declarative" intermediate representation (not really sure what state file at a point in time could ever be imperative), you then would get back some data from the engine, then make choices about what to send off to the engine in the next request.

It's important to understand that with Pulumi, you can end up in either situation. You have to be careful to not become imperative overall is probably the better way to consider this.

https://www.pulumi.com/docs/languages-sdks/javascript/#entry...

Another way this can break down is if the user writes code to call the same APIs in the middle of a Pulumi script. I meant to try this myself to verify it works, but I would assume that Pulumi is not stopping me from doing something like this.

[jjnoakes]

In general maybe, but in the specific context above, I think calling that loop declarative is accurate, and laughing at that classification is a poor response rooted in a deep misunderstanding.

[verdverm]

    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

[verdverm]

I was just wondering what stops me from reading and writing to a cloud bucket like an infinite tape?

https://www.pulumi.com/registry/packages/gcp/api-docs/storag...

[lmm]

> This seems extremely dismissive and shallow.

When someone tries to make a sophisticated argument that up is down and white is black, dismissive and shallow is the right response.

> The actual work done under the covers is not imperative

Having a declarative layer somewhere in the stack doesn't make something declarative, if that's not the layer you actually use to work on and reason about the system. See the famous "the C language is purely functional" post.

[Pet_Ant]

I’m guessing this is the reference?

http://conal.net/blog/posts/the-c-language-is-purely-functio...

[jjnoakes]

> When someone tries to make a sophisticated argument that up is down and white is black

This is where the deep misunderstanding is coming from.

[verdverm]

you can have loops and still be declarative, CUE has loops, though they are considered comprehensions more technically, but there is no assignment or stack in CUE

One of the interesting aspects of CUE is that it gives us many of the programming constructs we are used to, but remains Turing incomplete, so no general recursion or user defined functions. There is a scripting layer where you can get more real world stuff done too

The CUE language is super interesting, has a very unique take on things and comes from the same heritage as Go, containers, and Kubernetes

https://cuelang.org | https://cuetorials.com