Project still alive?

[spr-mweber3]

Hey there,

just wanted to check whether this project is still alive as the last release is already a quarter of a year old and Q3+Q4/2023 roadmap items doesn't seem to have been met.

I can see that there seems to be activity in the repository, but I'd like to get a better feeling on how much this is focussed towards getting the roadmap items done.

To me they seem really important when planning to get tf-controller used in production more.

[ilithanos]

My guess is that it is still alive, but i am starting to worry a little here as well.
I'm seeing bugs marked as fixed in November, but no releases since 0.16-rc3.

But based on the repo activity i would say it's still alive.

[yitsushi]

It is an active project, a new release has been planned for a while, but we have not yet found the right time for a full manual test and create a new release.

[shabe]

Hi @yitsushi @chanwit @LappleApple - is there a release planned anytime soon or an update to the roadmap to reflect the current state of the project? Thanks!

[creatorKoo]

I'm very much waiting for the terraform version selection feature update!
Please update this project!

[yitsushi]

I know we are very silent now, and not much work happened on the surface.

As a quick overview of the "why" and future plans:

1. The legal entity (Weaveworks) has issues. As far as I know, no public statements have been made yet, so I'll not go into details.
2. As a result of the 1st point, the future of the repo owner org is not clear yet.
3. The project is alive, at least some of us are still working on it, at least plan to do it.
4. Either the org will be renamed and keep all repos here, or we'll move this repo to under a different org. @chanwit suggested to use the TF Controller Community org. I don't have administrative access to even initiate this process, so I made zero steps (communication with that org) on that until we have clear road ahead of us.
5. I'm still working on encrypted BLOB cache. As all mentioned in the 1st step was very sudden, most of us took a long break from everything to process things and prepare for the future (e.g. looking for a new job).

My personal short-term plans with the project:

• Finish BLOB cache (the only important thing prevents it to be reviewed and merged is to push it behind a feature flag)
• Submit an RFC to use an abstraction over tf-exec (like Runtime interface) and make the runner ruse that everything. That way we can implement Runtime for Terraform and OpenTofu. My (not well refined) idea is to get to a point where the runner can use either of them based on an ENV value, that way we only have to create separate docker images with separate binaries, and the runner can do the magic. That could possibly solve versioning issues too as we can have more than one Runtime implemented for the same tf-exec lib, so if breaking changes happen, we can just create a new implementation and keep the old one.
• As we don't have to deal with Weaveworks vs HashiCorp legal issues, as a project it clearly does not violate any ToS of Terraform, I hope we can support OpenTofu more openly.
• Add extra storage layer handling to BLOB cache. Now it saves the encrypted cache archive to a volume attached to the controller, but for example it could be an S3 bucket.
• Try to organise a discussion about the future of the project with other maintainers (like who can configure, who wants to continue, and what is their idea of the future of the project).

About a release: I never did it, but I'll try when I'm done with BLOB cache. Unless someone wants to create one (for example: @yiannistri or @chanwit)

Sorry for the long silence. I wanted to write an update, but for a long time I didn't know what can be publicly said and what's not. Now I still don't know, but I have more confident I don't get in trouble about what I write down.

[austinloveless-liatrio]

@yitsushi

Sorry to hear about the changes. This is very unfortunate news...

[ilithanos]

ah damn, sorry to hear that. Hope the project survives in some form, and that you all find a new home in the job market soon.

[demisx]

Sounds like Weaveworks is going under. It laid off its developer force. I hope FluxCD and this project find a new home soon. We really need them.

[yitsushi]

Note: Flux is already under CNCF for a long time now and has its own github org.

[demisx]

@yitsushi Thank you for clarification. I am not 100% sure how this works, so please forgive me for asking stupid questions. Does this mean that TF Controller project will continue to receive an adequate support in the future? just trying to figure out if we can count on it in prod moving forward.

[yitsushi]

this mean that TF Controller project will continue to receive an adequate support in the future?

From me, it will. @chanwit said he wants to continue maintaining he project as well. Hopefully we can get more contributions, but even if with a bit slower pace, I'll work on this project still.

[rmvangun]

What's stopping this from folding in to the fluxcd organization? I always imagined a close affiliation between Flux and this project, I discovered it via Flux's documentation, etc... it would be amazing if this had the same guidance and support under CNCF as the greater Flux project.

[kingdonb]

We learned some lessons from rolling Flagger into the Flux organization, I think. There is absolutely close affiliation, and I would like to deepen the connection and supportive links as long as we can keep developing both projects!

It's important IMO to be clear about the specific benefits we expect from making such a change. There are also concerns about conflating the projects together, since they are not at the same maturity level.

The flux project has @fluxcd-community org to host projects that are not in the CNCF umbrella, so if it's moral support, material support in the form of infrastructure, CI resources, testing, release engineering, or anything else we can provide, it will be less red tape to move it there, rather than making it another sub-project of the FluxCD org. I don't speak for the whole group and this is not the last word, of course.

But either way I think from a moving orgs perspective it's flip a switch... the question is, what do we hope to achieve with it!

If it's about the maturity of the project and signaling, I think it's better for a project to join in sandbox/incubation and work through the issues. Either way I will be glad to contribute anything I can here, as a maintainer of fluxcd/community, and help facilitate this conversation if anyone wants to spend more time on exploring it.

I think this is a worthy project and it should continue!

[danielloader]

It'll be nice to see where this lands, however it does.

I'm currently evaluating tf-controller against crossplane and pulumi operator and there's pros and cons against them all as anyone who's gone fishing in this arena knows.

That being said, while I really like the tf-controller approach if the project isn't stable/maintained it's signing my company up to some nasty surprises down the line.

As an aside to the above, tf-controller is winning on a bunch of the criteria - enough to justify this reply. I hope it settles and a roadmap for the project is decided on.

Edit: Oh and there's https://developer.hashicorp.com/terraform/cloud-docs/integrations/kubernetes but the forced integration with terraform cloud rules it out for me, and anyone who has a preference for their own state.

[yitsushi]

There are talks in the background, soon we can get something out of it. We plan to support the project and work on it, it is a bit trickier when I spend a lot of time with interviews, negotiations, etc to get a job 🤣 (waiting on a final contract draft so it's not that bad).

About the "forced integration with terraform cloud". I like tf-controller, and we aim to support OpenTofu, right now it's not supported and with the terraform binary and its tf-exec lib, sadly (still think that was the worst business decision of the millennium, worst than any X/Twitter related) HashiCorp requires a business licence from the user in order to use other backends than their terraform cloud if their work/project conflicts with their "competitive product" definition. So, don't forget to put that into your research, check if you need a business licence if you want to use terraform (doesn't matter if you intend to use it with tf-controller or not, it's purely a terraform question).

[danielloader]

Interesting that you mention this, if hashicorp are going to chase people who use terraform automation I wonder where the line is drawn?

Is running terraform in a cronjob on an ec2 box going to cross that line?

Going to be quite frustrating if this project loses steam because of this ambiguous line in the sand around competition with their cloud product.

Given that ambiguity I suspect I would just use OpenTofu if the option was available just to not worry or think about the blurry grey lines between being sued or not.

[yitsushi]

It's more about how and why you are using it. I'm not a legal expect and I didn't really dig deep into it, but I think the main target was all the providers "re-selling" terraform and/or terraform cloud-like product, but they worded it very vaguely so I have no idea what they do or what's their intention in practice. Please check their blog/sites/licence details.

[chanwit]

we started fresh now with new name. this project has become a 100% community project so any small contributions would be really appreciated.

[o6uoq]

Edit: Oh and there's https://developer.hashicorp.com/terraform/cloud-docs/integrations/kubernetes but the forced integration with terraform cloud rules it out for me, and anyone who has a preference for their own state.

^ @danielloader is there no way to BYO state e.g. S3?