Hi there, I’d noticed something different between the rule promhttp:
in 1.1
spec:
actions:
- handler: prometheus
in 1.0.6 (and in 1.1’s document ):
actions:
- handler: handler.prometheus
So which way is better in 1.1?
Hi there, I’d noticed something different between the rule promhttp:
in 1.1
spec:
actions:
- handler: prometheus
in 1.0.6 (and in 1.1’s document ):
actions:
- handler: handler.prometheus
So which way is better in 1.1?
The first one is better. The second one uses a CRD prometheus, while the first one uses CRD handler (so it’s fully qualified as prometheus.handler.istio-system).
We’d like not to have a CRD per adapter, so using the generic “handler” CRD is preferred.
I’ll go further and say that the second approach is deprecated and support for adapter CRDs will be removed in 1.2.
That is, we have moved to the following config for handlers:
apiVersion: "config.istio.io/v1alpha2"
kind: handler
metadata:
name: prometheus
spec:
compiledAdapter: prometheus
params:
metrics:
...
Config of the following form (using adapter specific kind) is deprecated:
apiVersion: "config.istio.io/v1alpha2"
kind: prometheus
metadata:
name: handler
spec:
metrics:
...
In 1.1, this behavior is controlled by the --useAdapterCRDs
flag. For certain environments and installs, it is important to set that to false
.
FYI here is a PR changing the default to stop using CRDs;
It contains many samples for converting to the new style. If there is enough interest, we can automate this with a tool.
I noticed that in Istio 1.1.1 some samples are still using the old CRD way to setup handlers.
I.e. bookinfo/policy examples.
From Kiali, we need to maintain both if not users may feel something is broken in their system.
So, I suggest
a) if examples can be upgraded to the new format,
b) documentation updated:
c) proper “deprecated” mark to indicate which config may not be recommended.
Thanks !
Hi Lucas,
Technically, we are not adding any new CRD, and only removing old CRDs.
The documentation update is on my list as part of the overall deprecation plan.
There is an issue with 1.1.1 that prevents full transition, which is why both styles are going to be supported for all of 1.1.x. The removal only happens in 1.2 and ingestion is guarded by flags, in case some CRs are migrated from 1.1.x.
–kuat