Cannot kustomize build hack/observability/kube-state-metrics / cannot use gitops for hack/observability/kube-state-metrics

[cwrau]

What steps did you take and what happened?

We're trying to include the new kube-state-metrics concept for our CAPI setup but we ran into the following problem while trying to use a flux kustomization;

Error: accumulating resources: accumulation err='accumulating resources from '../namespace.yaml': security; file '/tmp/kustomize-2769474050/hack/observability/namespace.yaml' is not in or below '/tmp/kustomize-2769474050/hack/observability/kube-state-metrics'': must build at directory: '/tmp/kustomize-2769474050/hack/observability/namespace.yaml': file is not directory

What did you expect to happen?

I expected flux, and kustomize build, to be able to build the folder.

Cluster API version

N.A. / main

Kubernetes version

N.A. / 1.25.8

Anything else you would like to add?

Locally kustomize build hack/observability/kube-state-metrics also fails with;

Error: accumulating resources: accumulation err='accumulating resources from '../namespace.yaml': security; file '/home/cwr/projects/cluster-api/hack/observability/namespace.yaml' is not in or below '/home/cwr/projects/cluster-api/hack/observability/kube-state-metrics'': must build at directory: '/home/cwr/projects/cluster-api/hack/observability/namespace.yaml': file is not directory

Label(s) to be applied

/kind bug
/area metrics

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[sbueringer]

To be honest. This folder only exists for usage within our tilt development environment, not for folks to consume our "hack" kube-state-metrics chart and configuration.

[cwrau]

To be honest. This folder only exists for usage within our tilt development environment, not for folks to consume our "hack" kube-state-metrics chart and configuration.

Ok then, do you have an official way to export these metrics?

Or put plainly, how is the end-user supposed to get these metrics if not through kube-state-metrics combined with your config?

[sbueringer]

The plan was to eventually release the configuration as part of the release artifacts: #7229

In the meantime the only option is to copy it, which is not great.

We should discuss it on the other issue, but we can consider publishing it with the next releases without implementing #7158 first. I would be fine with that and it should be relatively easy to implement.

[cwrau]

Ah, ok, depending on how that will be implemented that would be the longterm preferred solution.

But, in the short term, fixing this would already allow us to not have to copy the file as we can just roll-out the kustomization with the kube-state-metrics deployment 😁

[sbueringer]

Yeah it's just that basically we're on the hook to maintain a dev monitoring stack in a way that folks can use it in production. This will be just the first support request of many

[fabriziopandini]

+1 to not invest in making hack/observability/ usable outside of CAPI (and close this issue with won't fix)

We already already have a plan to bring observability to a more "production" ready place, not only for CAPI, but for all the providers (and even more, given that we are working on tooling that can be used for any CRD).
Let's keep going, and if we can possibly get some help from folks interested in this work, we can get it implemented faster

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.