Currently, for the ObjectBucket XRD and composition we use provider-kubernetes and its Object resource to watch the namespace of the claims. We need that to figure out the APPUiO Cloud organization name for billing purposes (see more: https://kb.vshn.ch/appuio-cloud/references/architecture/metering-data-flow.html). This organization information is in the namespace labels where the claim resides.
The current approach is to copy that appuio.io/organization label to the managed resource, so that the metrics collectors can pick up this information from the managed resources.
Idea
it may be beneficial if the metrics collector directly query the Kubernetes API and figure out this namespace label themselves. We reduce complexity of the compositions, but only slightly increase complexity in the metrics collector. The collectors would have to simply GET the namespace objects for each managed resource.
Impact
cloudscale-metrics-collector gets the organization from the Objects user metadata tags that the cloudscale API offers. This project would need the plumbing to query the organization from namespace instead of the tags. However, exoscale-metrics-collector has this plumbing already so should be fairly easy to adapt as well.
The composition no longer provision provider-kubernetes Object resources
Out of Scope
Commodore component does not need to be updated yet.
Alternatives
Continue using the current watch-and-patch approach.
Acceptance Criteria
Extend cloudscale-metrics-collector with:
Boilerplate to setup Kubernetes client
listing Namespaces and organization label (make this part reusable for exoscale-metrics-collector)
querying all managed resources
Stop using tags from cloudscale API
Compare objects from kubernetes with buckets from cloudscale API
Adjust composition so that
it doesn't use provider-kubernetes anymore (and stops patching the ns label in managed resource)
it stops using tags for cloudscale API
Test out the composition and collector on our Lab cluster
mweibel
commented
1 year ago
Context
Currently, for the ObjectBucket XRD and composition we use provider-kubernetes and its Object resource to watch the namespace of the claims. We need that to figure out the APPUiO Cloud organization name for billing purposes (see more: https://kb.vshn.ch/appuio-cloud/references/architecture/metering-data-flow.html). This organization information is in the namespace labels where the claim resides.
The current approach is to copy that
appuio.io/organizationlabel to the managed resource, so that the metrics collectors can pick up this information from the managed resources.Idea
it may be beneficial if the metrics collector directly query the Kubernetes API and figure out this namespace label themselves. We reduce complexity of the compositions, but only slightly increase complexity in the metrics collector. The collectors would have to simply GET the namespace objects for each managed resource.
Impact
Out of Scope
Alternatives
Continue using the current watch-and-patch approach.
Acceptance Criteria