When set to false, no namespace label will be set by the adapter based on the namespace
portion of the url in the request path.
This allows individual consumers to set namespace independent of the source kubernetes resource.
---
Example:
Given an adapter config like this:
```
externalRules:
- seriesQuery: 'nsq_topic_depth'
resources:
namespaced: false
```
An HPA could target a different namespace by setting it in the selector:
```
- type: External
external:
metric:
name: nsq_topic_depth
selector:
labelSelector:
topic: my-topic
namespace: nsq
```
This is useful for scaling on metrics from services that run in a differnt namespace than the source resource.
When querying custom-metrics, the metric label selectors weren't
populated in the resulting values.
Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>
Pick up changes to 1.17 to custom-metrics-apiserver and the latest
changes in metrics-server to allow us to show table results for
podmetrics and nodemetrics. Fix import and interface changes as
necessary.
The localvendor directory is an artifact of a change in sigs.k8s.io:
sigs.k8s.io/metrics-server now requires this dependency in order to
resolve, even though we do not use the scraper package.
go: sigs.k8s.io/metrics-server@v0.3.7 requires
k8s.io/kubernetes/pkg/kubelet/apis/stats/v1alpha1@v0.0.0: reading k8s.io/kubernetes/pkg/kubelet/apis/stats/v1alpha1/pkg/kubelet/apis/stats/v1alpha1/go.mod at revision pkg/kubelet/apis/stats/v1alpha1/v0.0.0: unknown revision pkg/kubelet/apis/stats/v1alpha1/v0.0.0
According to documentation LabelValuesByName is supposed to render "|" separated values.
Currently it is returned as a slice per label name. This fixes it
Fixes #191
This introduces support for the resource metrics in the adapter.
The individual queries and window sizes are fully customizable via a new
config section. This uses just the generic machinery from
metrics-server to serve the API.
This extracts the label-to-resource conversion to a separte "naming" package for
use across different providers.
Early versions of the commit were done by antoinne85 in #79.
It's fairly common to have a label pattern that matches lots of
irrelevant labels, so this makes the "error" about being unable to
normalize/resolve a label to a GVR a V(9) info log, instead of an error
log.
