 All right. Hello everybody. Thanks for coming to our presentation. So we're here to tell you more about Open Tofu, which was announced to be a part of the Linux Foundation just yesterday. And generally tell you where we started and where we're heading, where we are now, etc. Quickly give you like a breakdown of what happened in the last month and what's happening in the next few weeks. I'm Kuba, with me is Ronnie. We're part of the Open Tofu core team and basically happy to tell you more about it. So to start with somewhat of an intro, first, what even is Open Tofu Terraform? So Open Tofu is a system to declaratively manage your infrastructure by describing it through code. But what does declaratively mean? So you describe the desired state of your infrastructure like I like to have three as three buckets. You give it to Open Tofu and Open Tofu figures out the rest. So it takes a look at what you have now. It takes a look at what you want to have and figures out like the path between creating resources, changing resources, maybe destroying resources even, and it figures out all of those pesky details so that you don't have to. Now, why are we doing this, all of this Open Tofu stuff? So Terraform a while ago changed its license to the BSL, commonly known as business source license, which is, well, not open source anymore. And we believe that Terraform's like main value proposition is the ecosystem of providers and modules around it. We believe that this ecosystem could flourish because everybody knew that Terraform is open source. They knew that if they build providers for it, they'll be able to use it forever to come. They could trust that the open source system remains open source and that all the customers will be able to use it with their, for example, cloud platform or other backend system as Terraform supports, you know, it has over 2,000 providers. It supports all kinds of systems on the back ends. And other projects are benefiting from those providers too, you know, like Pulumi which we use at the beginning Terraform providers to get started. Modules which people are preparing so you don't have to write everything yourself so that you can reuse existing security standards other people have thought about. Now, Open Tofu is meant to keep in line with this open spirit and is a fully open source fork of Terraform and is supposed to stay open source and continue this ecosystem the same way it was before and even in a bit more open way. Now over to Ronnie to tell you about the route so far. Hey everyone. So it's been a busy month. And yeah, we started August 10th where Hashi Co-op announces the license change. The very next day we had a group of founders of various products and projects around the Terraform ecosystem including open source and commercial products looking to discuss the impact of said license change on the ecosystem. On August 14th we've published a manifesto, the OpenTF manifesto as it was called and at the essence the manifesto was really a plea to Hashi Co-op to either maintain the open source license or and as we recognize maintaining an open source as a sole contributor or maintainer has its upsides but also comes with a great cost. So one of the pleads was possibly to perhaps consider contributing it to CNCF or Linux Foundation and much like other have done before in similar circumstances. We've also then at August 18th sent that as an open letter really to Hashi Co-op to plead their response. As companies started to pledge developers from their own companies and also individual developers have also started to pledge we've assembled our engineering team and we started discussing what is it we're going to focus on for the next coming weeks. And the first goal was to really to adopt names and documentation then look at stabilizing the version as we've forked from Terraform 1.6 in an alpha version and then kind of focus on the pivotal feature of that release which is the testing feature. Moving on to August 24th is where Hashi Co-op actually changed their registry terms of service. Now this is an interesting one because essentially it had denied access to the public API by any tool other than Terraform. So that was something we had to cope with and then we looked at interim registry design and long-term RFCs. Cuba will elaborate on that a little later on. The response from the community was overwhelming honestly. It was within just two weeks we've got over 9,000 GitHub stars. We've had trending positive trends on Hacker News and Reddit and on GitHub making headlines in Forbes and TechCrunch and hundreds of individual developers pledged including several dozens coming from companies who have pledged their development time as core maintainers. September is where we've finalized our terms of handing over the project to the Linux Foundation. This was always the goal honestly going to the Linux Foundation or CNCF. We believe that these are exactly the kind of terms that this kind of project or product deserves and can flourish in. We've then gone public with our GitHub repository and then kicked off a new discussion about namings which is always fun. Selecting a new name due to trademarks. TOFU had actually seemed to quickly became a crowd favorite which is a playful pun on the project being a sustainable alternative for a more healthy ecosystem while keeping the project initials. After a single week again of the repository being live we've hit over 5,000 stars and over 35,000 stars for the manifesto pledging Hashi to either contribute the project or carry on. The Linux Foundation actually on September 12th got ahead and approved the name and yesterday we officially launched as the Linux Foundation project. And now we're looking ahead and looking at timeline. We've got an early release that is 100% open source and is a drop in replacement for your Terraform 1.5.x and 1.6 preview. Again 1.6 is not officially out yet from the Terraform side and that's coming up next week. It has the polished version of the new testing feature we've been working on getting live and ready for an official release. It also includes the experimental provider and module registry approach which is again to bypass the new terms of service. A GA release is coming later this quarter. The only reason why the preview release is said to be a preview or development preview is the exact issue with the registry we described as an experimental other than that we consider it to be stable. That's what we're pending. There's a public roadmap that's coming up this quarter. There's a steering committee that's assembled based on the best practices of the Linux Foundation. It is highly driven by GitHub issues so we really invite you all to participate. This is a great time to be part of this community. Heading over to Kuva to elaborate on the official registry. As Ronnie said, the official registry is the main blocker for the early release. Now I'll tell you a bit more about how the registry worked, what changed and how we're designing it. First, what is the registry? What do you use the main core central registry for? First of all, it's storage for providers and modules. Terraform uses providers to interface with various cloud providers, to interface with various systems. It uses modules for code reuse so the registry basically hosts all of these and lets Terraform resolve those. Then there's discoverability. You want to find the providers and modules that you want to use for the cloud provider you want to use for the use case you want to use. Documentation, even though the docs are generally hosted in the GitHub repo of the provider, for example, the registry is responsible for actually nicely rendering this to you when you want to look something up, render it to you by resource, by version and let you browse that. Now, also, signing key storage. Binary is assigned. You want to know that they're coming actually from who you think they're coming and you want to make sure there was no supply chain attack. Now, since the official HashiCorp registry changed its terms of service, you now can't use it as as Ronnie said with anything other than HashiCorp Terraform. So presumably any folks you make of your own as well. And this obviously includes OpenTofu. Now, it's worth noting regarding the architecture of this registry that it really is kind of a GitHub redirector at its core. So it gets the versions from the GitHub releases list of a repository that houses a provider. And the artifact download URL it gives to Terraform is usually just a URL of the release on GitHub. Now, step by step, basically, you know, a Terraform provider with a Terraform execution wants to use a Fastly provider, for example, 1.2.0. It asks the registry, hey, this is the version I want. How can I get it? What does the registry say? It says, okay, here's the signing key that it should be signed by. And you can download it from there where there is actually a GitHub releases artifact. It's a bit different for some providers like the official Hashi ones because they're hosted on the registry. But that's the general mechanism on which the registry works. Now, as Ronnie said, for the preview, we're making a first go at a custom solution here. And this initial registry implementation we're doing will operate on top of GitHub and be fully compatible with all existing providers, giving you basically a fully drop-in replacement experience. All providers still available, all modules still available, since everything is actually on GitHub, still. Now, initially, it will just be for artifact resolution, not the documentation, not the discoverability. This will come later. For now, we just want to get going with the preview release so that you can actually use it, test-drive it, give feedback what is working well, what isn't. Now, we're also consulting with multiple other projects and companies here, like Artifact Hub, Terorack, Fastly, to better understand various approaches here and what we can use to also handle bandwidth, to reuse as much work as has already been done in the open source on the registry and see what we can find here. After the preview release, once this is out next week, we'll actually start discussions on the final design of this registry that will actually be here to stay for the stable release. Now, this design might be an extension of the current design, so a custom registry hosted by us as a GitHub redirector, but it might also be adapting an existing project or even using an existing hosted registry that could be used for this. Another thing is the testing feature. As Ronnie said, this is one of the notable features coming in OpenTofu 1.6, and what it allows you to do is it allows you to unit test your modules, your Terraform code. It lets you write assertions. It lets you check what the values of various attributes, the relationship of those values. Now, in practice, oh, sorry, most of it was already committed to the code we forked as it was developed over time alongside major versions being released, so we just polished the code, we found a few bugs, we found a few edge cases, we wrote an extensive test suite for it and basically polished it for primetime use. We believe it's generally ready and stable, but in practice, we await your feedback out of the preview release that is coming next week. Now, over to Ronnie. Right, so I'm here to talk a little bit about the vision of our project and really what we're meant to be doing here. Before I do that, I really want to, first of all, say that we're really thankful for everything that HashiCorp has done for this community, right? Building it is a huge, huge, huge accomplishment and we wouldn't have been here without them and it's really true for the entire ecosystem. However, we'll look to carry on the open source torch now. Starting with a drop in migration, which is just to be a backwards compatible version with telephone 1.5.7 and 1.6 of the upper version, allowing everyone to really migrate easily and be in a drop in replacement. Another lesson learned is, you know, remain open source forever. It means that no commercial company will own this project. It'll be driven by the Linux Foundation looking towards the CNCF as well. It will always be under a well-known and widely accepted license that companies can trust that will not suddenly change in the future. We're looking to be community-driven, which is also kind of a step forward. So we want the community to be governing the project for the community itself. It means that pull requests will be regularly reviewed and accepted really based on the merits of what they bring to the table. And finally, to be impartial. Again, so this is a valuable feature and fixes will be accepted under value and not be impacted by any commercial vendor or a single one. Cuba, to talk about our development process. Yeah, so as Rani said, it's important for us for open tofu to be developed really in the open. And major change will always go for a public RFC process with open tofu. Anybody can raise their opinions, discuss it, maybe even make a POC. The final call obviously will be done by the steering committee, which will be made up of a diverse set of companies and projects ensuring that we generally don't have a roadmap that's guided by the commercial interest of a single company. So in effect, community discussion with a final call by the steering committee in general making the roadmap planning much, much more open. However, we also have some ideas of our own what we could improve in open tofu right away. Now, we won't be doing this right away because those will also go through the RFC process, those will also be discussed in the open. Some of those are actually already being discussed in the open and will then be called on by the steering committee. The first idea is state encryption. This is something that people have asked for in Terraform for, well, a long time. Since state files and plan files generally contain sensitive values very often, you have to trust the state back end with it. So you know you store it on S3, then you will store the state on S3. You sometimes store plan files in S3 when you have like multi-part workflows where in the meantime you have to store the plan file somewhere. Now this means you have to trust your back end that those sensitive values won't be leaked. So what we want to introduce is optional end-to-end encryption here. So no trust is needed. You'll be able to provide an encryption key or integrate with KMS, for example. The beautiful thing is that the contributor who already created the pull request and proposal for Terraform is now working on getting disintegrators with open tofu. They're working on the RFC, they're working on the POC. It's really a great experience and we're very grateful to them for this work. Another thing is OCI registry support. So we talked a lot about registries in this talk and it's worth knowing that that registry is a custom implementation specifically just working for Terraform. Now there isn't anything actually very special about this registry as far as functionality goes. So in fact we would like to also support other kinds of registries. Other registries are like Docker Hub, GitHub Container Registry, Amazon ECR. Now usually they're used for container images. But in practice you can store arbitrary blobs with some metadata on them. Example of a project that does its theme pipe, for example, for SQL and its plugins. Now instead of relying on a custom registry protocol, this way it would be very easy to sell those registries for modules and providers because you could just reuse those registries and they really solve the exact use case of just storing arbitrary blobs of data, arbitrary metadata and just handle it for you with your existing infrastructure. Now both these features, if they get accepted and implemented, will only come after the stable release. For the stable release 1.6 we're really targeting to stabilize what we have and to get something in your hands as soon as possible. Further feature development regarding major features will happen afterwards. The discussions will start afterwards. And also an actual roadmap will also be published in the following months pending this RFC discussion, pending an RFC steering committee call after the stable release is out and we have fine tuned our process. And this is actually it. This is really everything that's happened over the last, a little bit over a month I believe or actually a month. It's also what will be happening in the very close future. You can engage with OpenTofu on GitHub in the repository. You can create issues, feature requests, RFCs, bug fixes. You can engage with us on our Slack community or GitHub discussions. You're all welcome to participate and we'd love to have you there. And yeah, that's it. And we're also very happy to answer any questions you might have. Any questions? Yeah. Hi, maybe two. Is it on? Okay, can you hear me? Great. Maybe two questions, first question. What happens to already open issues and known bugs? Like how does the transition look from the Hashi Co-op repository to your fork? Thanks. That's a great question. So we've actually had quite a few of those already. Essentially the community has been kind enough and aware enough to start opening those. Any issue that's been promoted or got enough traction was actually reopened. We've seen a lot of those. We've actually also seen not only references, but also pull requests being opened by the same contributors. So issues, pull requests, whatever the community pushes forward over to our report, we'll be happy to push forward. But that's right now the path ahead for that. So we'll not be digging for the issues ourselves to say that directly. If there is an issue you have in Terraform and there is like a bug report in an issue in Terraform, just write it yourself on the OpenTofu repo and we'd love to look at it. Okay, great. And second question, I know this is all about OpenTofu and Terraform. Do you know anything about the other components like pack, console, vault? No. Not really. We will definitely be concentrating on OpenTofu. We believe this is enough of a project. It's already big enough as it is. It's also what the companies and projects backing it specialize in. So this is what we'll be focusing on. We're not aware of any other projects or initiatives trying to do this for alternatives. All right. There's a bunch of providers out in the wild for Terraform. Did you figure out any good workaround for making all of those all providers available for OpenTofu? Yes. So basically when I described the thing with the registry, in practice the registry is really a GitHub Redirector in the most part. So with our registry, we hope to basically adapt this and you'll be able to use all of those providers, drop in without any action taken. What will be on GitHub will work. We're also doing a mirror of the Hashi providers so that you can obviously use those two. And I think that's that. Was that what you meant? Pretty much. One follow up. I'm not quite sure how the current registry works. But if you choose a provider like the Azure provider or something, there's got to be some kind of forwarding or some index or something, leading from the registry to GitHub. Are you somewhere getting the data from or would it have to be? So two parts to that. First of all, I want to mention that the license of all of the providers and modules remains the same. It is still MPL or Apache or whatever they wrote those with. And they're all still open source. The ones maintained by Hashi are also committed by them to be maintained that way. And they're actually not even maintained by Hashi. They're usually maintained by one of the cloud providers, depending on what it is. And in terms of how they're resolved, like Cuba mentioned, the registry in terms of not, so there are two parts to it, right? There's one is a catalog where you get to browse and look at things. And the second part really is just a glorified proxy. Whatever you publish a package, it has to comply with a naming convention of your GitHub repository, your organization repository, and so on. Which means since it's a very strong and imposed convention, this is how we resolve those. And also all the metadata, whatever releases there are, the readme, all of those stuff that are nicely presented in that catalog, are essentially readme is pulled off of GitHub based on that naming convention. And we're going to do that. Okay, thanks. That's super cool. Hi there. Will you and how will you be remaining compatible with newer versions of Terraform? In short, we'll try at least for the foreseeable future to remain as compatible as possible, but we're still ironing out the details of that process. So I can't tell you anything specific yet. We're working on getting a process here in place. In practice, if there is something that will be missing from for you, you can always submit it as an issue and it will be always looked on. So this is certain, but regarding the details of exact compatibility with future releases worked on. So we're looking really for your input, right, as to which issues you want to implement and how exactly those need to be implemented. There's a certain label that's being pulled for us to kind of reflect on those. And those at least right now as we're looking at the early versions and what, like we said, the compatibility is a big issue for us. And it is highly likely that we'll get high demand from the community and also from the steering committee. Thank you. Hi, thanks. I have some questions, mostly about the registry actually. Do you plan to do a re-implementation of the registry metadata API? Because we have a dependent to provide information to our users that way. And if yes, there's definitely some issues of us open out there like the H1 versus HH deprecation, which opensends three years. There's one to deprecate the HH from the API. Will this be any plans around that? So in terms of implementing the registry, right now we're not changing anything on the API. The concept is to essentially anything that goes through the default registry has to be rerouted to not violate the new terms of service. It rewrots to a different server that resolves based on the naming convention right now. And this is looked for the alpha release. Now we're also looking to extend but not to break the compatibility API, which means one of the considerations of one of the RFCs is to start supporting, like Cuba said, either an OCI registry or also Artifact Hub, which is a hub where any artifacts from the CNCF projects are stored, such as Helm, OPA, and so on. So also to be able to resolve those from there. If we do that, it will always be to extend the API. It means private registries of Terraform will remain with the same APIs. And this is all being discussed. Again, RFCs are open and you're welcome to participate. But for the initial alpha, no. It's just the same old API, no changes though. Okay. Thank you. A second question. Is there any plans to differentiate between TF and TOEFL code, especially in the log files maybe? So in terms of code, no, there is no difference. The code remains the same. File extensions remain the same. Variables remain the same. As we said, we're prioritizing backwards compatibility. The only thing you will have to change to switch over is the command itself. Instead of running Terraform, you'll be running TOEFL. Okay, thanks. Hi, thanks for this. I'm pretty excited. Just as some general feedback about encrypted states, I would say that for my organization, if you were to do that, that would give us a big ability to push our organization to completely adopt it. So kudos to that. That's great. And maybe you just need to do a little bit of education for me. So I want to commit to this and I want to convince everybody in my organization that, okay, if we're going to go to this project, they're not going to change the license on us in six months. So how is this permanent licensing working? What is the steering committee? How can I basically make that transparent inside of my organization? Okay. So I understand this is not a question. This is feedback to have a website to have this described. Where's this question? No, this is, I legit don't know what you mean by like the license isn't going to change. And what is the steering committee means to you guys? Very enough. Can you do some education to me? Sure. Sure. Of course. So basically with this going to the Linux foundation, first of all, there's basically a governance model that is fairly common across Linux foundation projects. And it's based around the steering committee. This means that basically various main backers, both projects and companies get seats at the steering committee, which then vote on any issues. This in practice means that, yeah, it will stay open source. It's not like a single company will decide, okay, right now you can't use it if you're competitive or something like that. I don't think it's in any way possible. Another thing is that's, well, even though we have the MPL license of the Terraform code at forking time, we don't have a copyright to that. So we can do a real license ourselves of existing code from MPL to something else. So this is also something that gives you some additional guarantee here. I think the key point to understand is that the project itself, all of its assets, all of its properties does not rely anymore on any commercial vendor. Okay, it's at the hands of the Linux foundation. The steering committee is a technical steering committee trying to make decisions as to which issues should be moved toward, how to prioritize, how to build a roadmap and so on. And the seats there are not limited by any means to commercial vendors. On the contrary, there's going to be seats that are available for members of the community as well. Speaking of commercial vendors, has a commercial vendor, has HashiCorp gotten in touch with you guys yet and given you any feedback one way or the other, have they responded anyway? I mean, we did get some legal letters, or at least some of the backers. Wasn't a positive one so far. But it is actually, but it's a key point to say, okay, I mean, the pleats are still out there, the letter is still out there, the manifesto is still out there, right? I mean, we would love for HashiCorp to participate in this project as well as a vendor. Yeah, actually, if they'd want to, most likely would be a steering committee seat for them ready if they ever want to take it. All right, any other questions? Nothing online? Okay, thanks everyone. Thanks a lot for attending.