Announcing Teller 2.0

[jondot]

Hi all,
I wanted to announce a project we've been working on for quite a while (which might explain our focus shift) -- which is Teller 2.0 🎊🎉😃.

What's the goals of Teller 2.0

Teller 2.0 will be written in Rust🦀, and as a "second time around" will incorporate all of the feedback from production into a new, fresh design. Our best design to come.

• ✅ A complete rewrite of Teller 1.0 which removes limitation of the current design, and opens up many more features and added security, as well as easier to add features
• ✅ Teller as a library (be able to use it anywhere as a C library, we will also provide a Python and Node native libs), to be used from your API services directly
• ✅ Provide full CRUD on providers (Teller 1.0 is optimized for Read)
• ✅ Better error story and operability model
• ✅ Multiple providers and provider naming has been a challenge in Teller 1.0 because it was an exception to the rule, after we studied how people use Teller in production, in 2.0 we design for multiple environments and providers as the standard

Why Rust?

Moving to Rust 🦀 as the primary language reduces changes of bugs, increases safety massively, and opens up a world of security tools and memory manipulation (e.g. we want to be resetting sensitive data in memory after access), as well as a better language for the model of what we're doing (we have had a lot of limitations imposed on us from Go, which we had to hack the design to work around).

In addition we will be "subscribing into" a community of security, safety, and high quality production values. We'll be enjoying a super stable platform and standard library, with super stable libraries. The name of the game for Teller 2.0 is: robustness and security by design!

What's going to happen to v1

As we start incorporating Teller 2.0 into the repo, Teller 1.0 is going to stay there with no change in order for us to be able to take care of existing PRs and last minute ties.
Then, Teller 1.0, AKA "Teller Go" is going to migrate into a branch for those still needing the Go codebase. We will merge additions into that branch but the mainline Teller will be Teller 2.0, and it will have the same feature set and quickly will also have added features that would be never possible with Teller 1.0.

• Teller 2.0 configuration format will not be compatible with 1.0, so we can unchain ourselves from the limitation of design of 1.0.
• Teller 2.0 CLI interface will be mostly similar if not directly similar to 1.0.

When is v2.0 be out?

We will be merging in a preview of 2.0 in a few days, into the current codebase so everyone can take a sneak peak. Once it is merged in, we will incrementally bring 2.0 into release-ready (setting up CI, etc.) and then we will be able to take in PRs into the 2.0 version

We thank everyone that has been part of this amazing journey🚀 , Teller is being used in small companies, startups, F500 and even F100 companies. Clearly, we solve something people really needed.

With Teller 2.0 we aim to ship better quality, better safety, better security and many more features to all of those users.

Stay tuned for 2.0!! 🚀🎊

[polarathene]

Might be better to have 2.0 as a fresh repo? teller-rs?

I don't think the repo name will matter too much to anyone and this one can clearly direct users to the new repo, especially if you have no plans to further maintain/support 1.0 beyond keeping the original source available.

That avoids the existing history with issues, PRs and discussions from the past adding any noise (since quite a bit of it won't contribute much value to the rewrite), while those landing on the issues / discussions from search queries can avoid any confusion.

Or are all open issues and discussions being closed / tagged at this transition point to minimize that issue? If you do provide one final 1.x release, please do so with the newer Go release, the last release from Oct 2022 was some time ago and a new release was requested Aug 2023, but ignored.

---

• Please get ENV parsing right with 2.0 (see my 1.0 issue).
  • Last I checked most implementations had different gaps in support and maintenance was generally lacking for them to get resolved. Teller could maintain a separate ENV crate as part of Teller 2.
  • I looked into ENV rust crates previously (I have more in-depth notes somewhere 😅 )
    • dotenvs is a less popular but more correct choice (however has a bug and doesn't appear to be maintained anymore).
    • A popular crate is dotenvy (fork), but has some parsing support issues of it's own (1, 2).
    • dotenv-lookup from dotenv-linter seemed viable but the maintainers have not been too interested in publishing it as a separate crate for library use.
    • envsubst (Go) has it's own too (link provides another use-case example that fails).
• An improved approach to release distribution would also be good.
• At the very least a better release process would be appreciated (I tried to contribute updates to the CI for the next release, but it was not a pleasant experience as a contributor).

[jondot]

Fantastic recommendation for 2.0! We will definitely cover those.
Regarding repo -- we discussed this internally a lot, the conclusion was to perform an "evolution" rather than "revolution" meaning, to say, we will keep supporting 1.0 for critical things, but moving forward to encourage to move to 2.0, for many reasons (primary one - security). The way to achieve most motivation and encouragement is through using the very same repo. We want to avoid a "split brain" mode where the two versions never converge, so that's why we want to keep all things closely located.

[darach]

When in the depths of a src hierarchy it would be nice if teller searched up through the parent file system for a .teller.yml and resolved it rather than requiring the -c <config-path> option. It would make the following just work:

cd pkg/beep/boop
teller run -- go test -v ./...

For folk using go or cargo this removes friction as it would follow the same conventions and become more intuitive

[MarkusSagen]

For version 2.0, would it also be possible to read secrets from plaintext from AWS secret manager? #133

[EnturWilhelm]

Other food for thought for Teller 2.0:

• Please create a SECURITY.md file outlining instructions for reporting any vulnerabilities
• Please clarify the ownership of the project. At the moment Teller lives under the tellerops organization on Github, but is attributed to jondot in the project license. The website itself is copyrighted to Spectral Inc.
• Please clarify your practices with regards to reviewing and adding/updating new project dependencies. The only information I could currently find on this practice was in this issue.
• CONTRIBUTING.md has not been updated since before the project was included in CNCF and contains a dead slack link.

The aforementioned issues are preventing us from adopting Teller in any official capacity. I can also see that you mention Teller already being used in companies of various sizes "Teller is being used in small companies, startups, F500 and even F100 companies". An official list with some of these companies would give extra trust to the project (see zerolog users list).

[itai-gendler]

hey there.
thanks for these amazing efforts.
any updated on 2.0 and when we can test it out?

[dbowling]

Looks like the teller Homebrew formula is pointing to 2.x now. I'm suddenly getting errors that my config isn't named correctly and has the wrong format.

Is there an upgrade guide? I don't any notes in the changelog, and the readme in the repository goes back and forth between calling the config .teller.yml and teller.yml.

[jondot]

Yes we should write one
For now you can of course use 1.0
2.0.0 is a major change

[fordneild]

Is there new documentation for 2.0? I noticed tlr.dev was down. The current situtation was pretty confusing for a new teller user like myself. May i suggest a readme update to provide clarity on the timeline?

[fordneild]

I couldnt help but notice there havent been updates in some time, is this project still being maintained? It seems like folks really like it.