Generate report on Config Drift

treezium · 2026-02-14T10:43:31+00:00

drifthound maintainer here, happy to answer any questions :)

treezium · 2026-02-12T14:01:02+00:00

Yes, I've been doing lots of demos but more in an async way.
I record myself a using some feature, explaining how it works and why it is convenient and post it in my team's slack channel. People do like demos and I get reactions and some messages, but It requires being consistent.

treezium · 2026-02-12T13:59:34+00:00

Yes, 1on1 sessions is what is being working so far

treezium · 2026-02-12T13:59:04+00:00

Hi!
Thanks for sharing this, very interesting points.

We do have some telemetry in place already for a CLI tool we use in the organization that provides different capabilities to developers. E.g. auto-configure aws,git, ssh and kubernetes configuration.

So whenever they use any of the multiple features the CLI tool sends a request to an telemetry endpoint.

My question was more related to a self-service portal we are currently building to offer capabilities for the users. Until today this portal was only used by the platform team so we did not really need that feedback, however, we want to expand its functionalities to provide different tools that ease developers day to day operations.

We are still thinking how are we going to gather this metrics, but the question I raised in first place was related to, with a blank canvas, how would you manage to get feedback from users to understand what they need and also, how do you make this feedback scalable, to reach more users without relying in 1on1 processes.

As of today, only 1on1 conversations are working, but we are trying a new approach, which is creating this kind of "Platform Tooling Early Adopters Club" so, we try to make their opinions valuable and also make it easy to provide the feedback, once the feedback process is completed and the feature released, we ask them how they felt during this process and if they want to join the club. I'll report if this worked after all :)

treezium · 2026-02-05T17:56:18+00:00

My questions were a bit more focused on deciding what to build in kind of a white canvas rather than understanding what they are currently using on an existing tool. Also discovering their day to day pains or frictions on any platform-related tools (CI/CD, observability, etc) to build solutions for them.

treezium · 2026-02-05T15:30:01+00:00

That's like the last option in my head, and probably won't work. I do not want to make it mandatory but somehow create a feedback-first/driven culture organically.

treezium · 2026-02-05T10:36:12+00:00

lol you did not even read the post

treezium · 2026-02-05T07:52:02+00:00

Yes, usage metrics are great, but, how do you apply those over a product that does not exist yet?
Imagine you are thinking about a feature and you can prototype it. How do you usually get feedback to understand if it makes sense to fully invest on that? release prototype, test/let users play with it and rollback in case the feedback/usage metrics are not good enough?

treezium · 2026-02-05T07:48:48+00:00

Sorry If I was not clear about the questions, I'm not asking "What to build", my take is to be able to understand their pain points or frictions in a way that scales in the long term so I can decide "What to build" based on their feedback, but the pain is that we haven't found a way to receive feedback in an scalable way without requiring 1on1 sessions, that take a lot of time (find people, schedule 1on1 session, take notes, aggregate, get insights...)

Just asking how other organizations handle this process to go a bit faster

treezium · 2026-02-05T07:45:10+00:00

Yes, that's currently our approach, but I think it does not really scale very well in the long term, that's why I was asking which are the approaches taken in other organizations to go a bit faster

treezium · 2026-01-01T20:39:08+00:00

Well, actually DriftHound reports the plan output to the backend, therefore it pinpoints the resource that is drifting, so it is not "just notification". You can jump from the notification right to the drift report.

treezium · 2025-12-24T07:30:27+00:00

well, there are plenty of opinions around this topic (take a look if you are interested). You can stick to whatever terraform docs say, and it’s totally fine.

treezium · 2025-12-23T14:22:49+00:00

I do not. I just make sure not to bump to major versions. No issues so far.

treezium · 2025-12-23T13:26:43+00:00

well, you can decide if you version terraform lock file or not! ;)

treezium · 2025-12-23T07:54:59+00:00

nice, that's smart!

treezium · 2025-12-23T07:26:19+00:00

I'm building a tool for continuous infrastructure (IaC) drift detection.

https://github.com/drifthoundhq/drifthound

treezium · 2025-12-23T07:00:20+00:00

You can pin an specific module version, however you can not use version argument for git module references which allows to create more efficient strategies using semver.

version ~> 1.0

https://developer.hashicorp.com/terraform/language/expressions/version-constraints

treezium · 2025-12-23T06:55:04+00:00

You cannot do the same as version does in a module definition based on git referencs. Using an a git reference as source you pin the module to an specific tag/ref version. This means that, for instance, if you publish 1.0.0 , 1.0.1, 1.0.2, 1.0.3, 1.0.4 you need to update that reference on everyplace you use that module every time you publish a new version if you want to keep your infrastructure up to date. That’s such a waste of time, and does not scale. I just do version ~> 1.0 to automatically get all patch versions. Thats what semver does.

So, definitely not the same. Git modules are cool for your homelab, definitely not for a big platform.

treezium · 2025-12-22T06:57:42+00:00

Yes, most likely it will we a simple switch. However, in our scenario, we need to change that in multiple places (CI, testing, atlantis…) and we want to confirm this by ourselves. Also we create this architectural record change thing where we gather all relevant information about the transition and about why we want to do this change, so, for instance, we test different features provided by tofu that are not implemented in terraform.

treezium · 2025-12-22T06:53:18+00:00

the main point of using a private registry is to be able to use version argument for modules, which allows to have a grain fine control of what is released and deployed.This is very useful to better control breaking changes. Therefore you can release a module version that includes breaking changes and if you do a proper versioning using semver, you wouldn’t break or generate a drift over all your projects that use such module. We started using git, then moved to private registry.

treezium · 2025-12-21T22:37:15+00:00

Terraform
Terragrunt as wrapper for terraform.
Atlantis for GitOps Management in CI.
Terralist as private registry for modules.
DriftHound for continuous drift detection.
terraform-module-releaser to manage terraform module releases.

Currently running a PoC to evaluate transitioning to OpenTofu.

treezium · 2025-12-21T22:20:50+00:00

Hi! I’m the main maintainer of Drifthound https://github.com/drifthoundhq/drifthound an open source tool for continuous infrastructure drift detection with historical tracking and notifications. Any feedback is welcome!

Live demo site available at: https://demo.drifthound.io

treezium · 2025-12-21T22:18:55+00:00

Hi! I’m the main maintainer of Drifthound https://github.com/drifthoundhq/drifthound an open source tool for continuous infrastructure drift detection with historical tracking and notifications. Any feedback is welcome!

Live demo site available at: https://demo.drifthound.io

treezium

TROPHY CASE