Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The OpenTF Manifesto

opentf.org

Post reply on HN
Print view View original

301–310 of 392 posts

Re: The OpenTF Manifesto

#301

Post by verdverm »

jjnoakes wrote: post #297
verdverm wrote: post #296

Earlier quoted context omitted.

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 engin…

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.

    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

Re: The OpenTF Manifesto

#302

Post by docandrew »

AtNightWeCode wrote: post #179
0xbadcafebee wrote: post #142

Actually, can we just kill Terraform? Please? Terraform has a bad design. It's a configuration management tool, first and foremost, and configuration management tools need to do one thing well: fix things. Not just "change state", but functionally, actually fix some software to make it work again. Terraform is really bad at this. It's difficult to configure, difficult to operate, and it likes to find any reason at al…

This is perhaps the most incorrect post you will ever find on HN. I am not a huge fan of Terraform. However, TF is made for infra not config. There are several tools out there to manage config like Salt, Ansible and so on.

You can definitely use Ansible to provision infra as well. Whether that’s the right tool for the job is a matter of taste.

Re: The OpenTF Manifesto

#303

Post by Brian_K_White »

hadlock wrote: post #143
dijit wrote: post #72

Earlier quoted context omitted.

The issue with that is the ownership of the name. Name is identity, and thus the canonical representation of "Terraform" is now BSL. However, if you don't have an identifier such as the trademarked name and you look at the project itself then I think you're right.

It can be rebranded, that's pretty straightforward for something that's such an industry standard. "Oh yeah? Earthworks? That's the open source fork of Terraform" pretty simple. If it were a lesser known technology it would be an issue but most of the (modern) internet runs on it, whatever they name the fork will be well known pretty much instantly

No one asked "How does one rebrand?"

The whole point of this thread is the premise that it's not a fork.

Hashicorp's copy is the fork, and it's backwards that the fork gets to keep the name and the original must rename itself.

Re: The OpenTF Manifesto

#304

Post by pxc »

Atotalnoob wrote: post #256
hdaz0017 wrote: post #204

Earlier quoted context omitted.

Hopefully it's not down to CTOs to be picking tools for their company but a process within DevOps/Engineering teams etc. Does anyone else see this as the Nagios Effect all over again, there must be lots to learn from history?

What is the nagios effect?

I didn't know either, so I did some Googling and found an old announcement[1] from 2009:

> A group of leading Nagios protagonists including members of the Nagios Community Advisory board and creators of multiple Nagios Addons have launched Icinga – a fork of Nagios, the prevalent open source monitoring system. This independent project [is based upon a] broader developer community. [...] Icinga takes all the great features of Nagios and combines it with the feature requests and patches of the user community.

It also looks like in 2014, Nagios centralized and appropriated a domain name and website used for hosting Nagios plugins, away from the community (its plugin developers)[2]:

> In the past, the domain "nagios-plugins.org" pointed to a server maintained by us, the Nagios Plugins Development Team. The domain itself had been transferred to Nagios Enterprises a few years ago, but we had an agreement that the project would continue to be independently run by the actual plugin maintainers.¹ Yesterday, the DNS records were modified to point to web space controlled by Nagios Enterprises instead. This change was done without prior notice.

> To make things worse, large parts of our web site were copied and are now served (with slight modifications²) by http://nagios-plugins.org/>. Again, this was done without contacting us, and without our permission.

> This means we cannot use the name "Nagios Plugins" any longer.

There's some previous discussion of those controversies on HN here: https://news.ycombinator.com/item?id=9452013

From that article[3]:

> [Icinga developer]: "Six months before the fork, there was a bit of unrest among Nagios' extension developers [...] Community patches went unapplied for a long time[.]"

> [...]

> Two years ago, more or less when the split happened, [Nagios author] was having problems resolving [trademark] issues with a company called "Netways".

I'm still not sure what the effect is supposed to be tbh.

--

1: https://icinga.com/blog/2009/05/06/announcing-icinga/

2: https://www.monitoring-plugins.org/archive/devel/2014-Januar...

3: https://web.archive.org/web/20160314090137/http://www.freeso...

Re: The OpenTF Manifesto

#305

Post by xyzzy_plugh »

Alupis wrote: post #275
candiddevmike wrote: post #259

Earlier quoted context omitted.

Most companies are probably using the secret manager provided by their cloud platform instead of Vault, especially after they tried to buy Vault.

Which is more than likely Vault + new carpets and paint.

No, it's astronomically unlikely to be Vault at all.

Re: The OpenTF Manifesto

#306

Post by pxc »

VectorLock wrote: post #282
dbingham wrote: post #23

I appreciate the letter and trying to work with Hashicorp -- I used to have a ton of respect for Hashicorp. But honestly... at this point... ...just fork it into a foundation. Don't wait for Hashicorp's response. I get wanting to have the appearance of working with Hashicorp, but we've been shown again, and again, and again, and a-fucking-gain that private corporations cannot be trusted to maintain public goods. Only…

I don't think you can just "fork it." Hashicorp already owns all that code because they make contributors sign it away to them.

They can't retroactively take source code away from people who they already granted access to it under the MPL. The old code is still available under the MPL forever- even if they take down all of their own public copies of it, anyone with the old Terraform code is still free to upload their copy for the creation of a new fork. That's kinda the whole idea with these open-source licenses :)

Re: The OpenTF Manifesto

#307

Post by jen20 »

diarrhea wrote: post #154
cyberax wrote: post #76

Terraform core is kinda crappy. The language is awful, and the module infrastructure sucks. I would support (with my own money) a fork that would re-use the Terraform providers, and reimplement the language as something not so insane.

Having recently picked up Rust (yes, sorry for mentioning it, I promise it's relevant), I picked up Terraform the other day. I was shocked by how weak its language-level developer experience story is. I am working in VSCode, which by and large tends to be the editor supported best, with the most mindshare. Terraform has static and mostly strong typing, yet some testing revealed I was able to pass an argument of the w…

The IntelliJ support for Terraform is far more complete.

FWIW, the Rust support is also better in CLion than VS Code.

Re: The OpenTF Manifesto

#308

Post by glenngillen »

tedivm wrote: post #42
marcinzm wrote: post #34

As I see it Hashicorp has failed to create a viable business model in an environment where there isn't unlimited perpetual VC money. Now they're at the stage of giving up and simply trying to shake down those who have managed to make better business models. It's usually not a good idea to be near a company flailing like this since who knows what their next rent seeking approach will be. A company with nothing to lose…

The worst part is they did create a viable business model. They were profitable when they had their IPO. They then pretended that the IPO was just another Series X investment, blew all the money, and went negative on their cashflow. Hashicorps problem isn't that their business model doesn't work, it's that they are really bad at their jobs. They ignore customer feedback, laid off support people, and then jacked their…

Blew all that money? They still had about $1B in the bank at the last earnings, and they only raised $1.2B in the IPO iirc

Re: The OpenTF Manifesto

#309

Post by xyzzy_plugh »

This was inevitable after Hashicorp's move.

After thinking about it for a few days, I think Hashicorp's move is actually net great for everyone. The products that matter will be forked and maintained in the open. Hashicorp would choose wisely to merge mature forks back into their product, if they can, and now you have a pretty standard model of up selling enterprise features on an open product that's developed in the actual open. It frees Hashicorp up to focus on the enterprise, which they have already been doing, but they've been neglecting their OSS, like Terraform (what the actual fuck is going on with the development of Terraform over the last two years?)

This is great. I'm really looking forward to using freed forks that pop up in the months ahead.

This is Hashicorp's sink or swim moment.

If you asked me when they announced the license change, I'd say bet the horse on Pulumi and move on. But now I actually think this could really rejuvenate the TF ecosystem.

Re: The OpenTF Manifesto

#310

Post by jen20 »

yjftsjthsd-h wrote: post #252
jen20 wrote: post #28

How exactly do the companies involved plan to fund a fork? It would require at minimum 3-4 full time engineers, and no one is going to do that work for free. It’s also telling that this manifesto blithely suggests TF could become Apache 2, which is wholly untrue.

> It’s also telling that this manifesto blithely suggests TF could become Apache 2, which is wholly untrue. Why is it untrue? If Hashicorp has the ability to relicense to BSL, what would prevent them relicensing to anything else?

They can make their own contributions going forwards BSL licensed. They can also make their own contributions Apache 2 _going forward_.

They could only make my contributions to Terraform Apache 2 with permission, so at best it could be MPLv2 with Apache 2 files interspersed.

Post reply on HN