jaxxstorm

you appear to be describing a peer relay: https://tailscale.com/docs/features/peer-relay

Note: I'm a tailscale employee

We have webhooks already for nodes added, but you could also use https://github.com/jaxxstorm/sentinel

I lead the customer engineering org at Tailscale.

We think this is a great idea and we're discussing internally potentially adding that to the console.

In the meantime, if you'd like to get an assessment, please feel free to open a support ticket (https://tailscale.com/contact/support?type=other&subject=sec...) and we'll happily take a look

There’s a lot wrong here, but the fact the author is upset there’s no confirmation for an API call makes me question if they should have any credentials, never mind staging

I wrote a POC for using Tailscale serve and funnel similarly to ngrok here:

https://github.com/jaxxstorm/tgate

Author of the post here.

It's always been relatively shocking to me that this is still relevant 4 years after I wrote it. Helm is as Ubiquitous as ever, despite attempts to replace it with Jsonnet, Cue and programming languages.

I've personally moved on from Jsonnet and would recommend Pulumi to anyone experiencing this problem.

Every single person who has this "you don't need state" take on IaC seems to be missing one key point.

They haven't built it, because it's really really hard to do.

We are happy to help over slack.pulumi.com

Terraform was (and I assume currently, OpenTF) under an MPL license, which is not currently compatible with the approved licenses that the CNCF supports: https://github.com/cncf/foundation/blob/main/allowed-third-p...

For them to get accepted into the CNCF would require relicensing a large amount of MPL work. What's always been confusing to me about Hashicorp's change and any subsequent relicense of OpenTF is that I know for a fact not everyone who contributed code to Terraform signed the CLA and allowed permission to relicense.

I suspect if OpenTF tries to relicense to a more permissive license like Apache 2 (rather than less in the case of BSL) license we might see some fireworks.

thanks, I've been through and fixed some issues, but any others you find please let me know!

thanks for the feedback!

this is absolutely not the experience we have when customers migrate to Pulumi, and I spend all day helping users undergo that transition.

I'm a a Pulumi employee, if you'd like to chat about how we can help add support, email me lbriggs[at]pulumi.com

Well, Pulumi is declarative, so I don’t really understand where this is coming from

You would need to bridge the Terraform provider to a Pulumi provider first. If you've written a Terraform provider, bridging to a Pulumi provider should be straightforward.

If you need help with this, please reach out to me on the Pulumi community slack at https://slack.pulumi.com and happy to help

You build a multi language component: https://www.pulumi.com/blog/pulumiup-pulumi-packages-multi-l...

You can then publish a language SDK for your supported languages, so npm for node packages, pip for python.

The invoking peer needs to have the language they're using runtime locally

The python boilerplater is here: https://github.com/pulumi/pulumi-component-provider-py-boile...

Here's an example component built in Go: https://github.com/jaxxstorm/pulumi-productionapp

Then in examples you can see it being using: https://github.com/jaxxstorm/pulumi-productionapp/tree/main/...

Pulumi employee here!

Worth noting that while lots of insights are leveraging LLMs/AI, it's only one pillar of the launch today.

The cross cloud search and analytics are really valuable additions to the product. On day 1, being able to export all your resource definitions to BI intelligence tools and drill down into specific areas of interest is something that has traditionally been very difficult.

On a personal note, being able to simply search for "who spun up this EC2 instance" without traversing through cloudtrail is a godsend, too.

> Upgrades without restarting: Sozu is always-up, meaning it upgrades itself while still processing requests.

How?

Pulumi also supports server side apply

https://www.pulumi.com/registry/packages/kubernetes/how-to-g...

This can be turned off by setting an annotation on the resources.

I don't think DSL's necessarily fail. Puppet's DSL was everywhere at one point in the late 00's and lots of people argue that Terraform's DSL is fairly ubiquitous in the IaC space.

The article brings up some fine points about why DSL's are restrictive, but the primary issue with them comes from the name: They're single use.

I meet with companies daily who have tried to adopt Terraform's DSL internally and found a few people feel comfortable with it, but the vast majority of the engineering org have zero interest in learning it because to them - what's the point? They can achieve the same goal with <insert language here> by using Pulumi or CDK. People will bring the flawed argument that Terraform's DSL stops you from footgunning yourself but I've seen plenty of awful, messy Terraform that's only maintainable by the person who wrote it.

Another consideration is just how much DSLs evolve over time. You eventually end up getting closer and closer to Turing completeness because people really want to solve problems that require it or solve them in a familiar way.

I've spoken frequently about my belief that in the long term, DSLs in the IaC space will largely be superseded by programming language based graph building and most of these thoughts come from frustrated users who are moving away from DSLs

The Pulumi github provider allows exactly this, and lots of organizations manage GitHub this way:

https://www.pulumi.com/registry/packages/github/

I have a vested interest in this argument, because it comes up all the time. From your argument, it's apparent you've never written a program in anything except a configuration language.

But by your own admission:

> You are not declaring what it looks like, you are writing instructions for how to produce declarative

If this was true, a Pulumi program would look like this:

    const bucket = new aws.s3.Bucket()

    if (bucket) {
      // do something
    } else {
      // do something else
    }

If you'd written anything in Pulumi you'd know that isn't how it works. The only imperative part of Pulumi is your ability to manipulate the DAG, for example:

    const config = pulumi.Config()
    const createBucket = config.reqiureBool("createBucket")

    if (createBucket) {
     new aws.s3.Bucket()
   }

Now, is there an imperative statement in there? Yes, but the only imperative part is your decision to include or exclude the bucket itself from the declarative end state. You do _exactly_ the same thing in Terraform but with a less intuitive syntax:

    resource "aws_s3_bucket" "example" {
      count = 0
    }

By that definition, if Pulumi is imperative, so is Terraform. It's not though, and you're wrong.

A really great write up!

Pulumi is deterministic.

I work on the solutions engineer team for Pulumi. We absolutely offer enterprise support, I'm one of the engineers that is part of that team. If you'd like to discuss further, you can contact me on lbriggs[at]pulumi.com

This isn't the point of the article at all...

This isn't how Multi-Language components work. The components only expose the inputs and outputs needed to the downstream consumer, you never have to "work in two separate files"

You’re generally lucky then I’d say. The point of the article was to try and see the other side of the equation for those people who do spend a lot of their lives writing long long YAML documents.

If you just need a configuration format for your application then none of this applies, there is however a whole school of tech job that has to deal with this every single day