Mike Dame

just checking in, is this still marked stale? I think mdatagen is still broken without it

@diurnalist are you still working on this? Or could we close in favor of the fix from @mmorel-35? I'm also happy to take this, as it's blocking us from an...

I still have a problem with mdatagen after https://github.com/open-telemetry/opentelemetry-collector/pull/11812, the new `metadatatest` package doesn't compile for my components. My generated files are missing [this import](https://github.com/bogdandrutu/opentelemetry-collector/blob/5421d1570906cf8d18c428e1568120d84803e8be/exporter/exporterhelper/internal/metadatatest/generated_telemetrytest_test.go#L13), ie `/internal/metadata`. Clearly it works...

Actually, I just ran mdatagen on one of the samples and that import was also removed too, so I think it's a bug still

Turns out the template does not add this import, but `goimports` does. Sorry for the spam

@maw1146 could you provide the whole descheduler config? You can also wrap it in 3 backticks (```) for multiline code to preserve indentation

@dvdmuckle sure, feel free to post your config here. If you have descheduler logs too, that would also help

Would it be better for some of these to use the [`InstrumentationStatus`](https://github.com/open-telemetry/opentelemetry-operator/blob/main/apis/v1alpha1/instrumentation_types.go#L149) field, so that the information is in one spot vs applied over (possibly many) workloads?

> Correct, the information should be in the status field. As a starting point then, what about just adding status conditions to the crd? https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#manage-cr-status-conditions I see that CollectorStatus implemented...

I opened a POC pr at https://github.com/open-telemetry/opentelemetry-operator/pull/1228, happy to discuss other possibilities or suggestions