Promethues or handler?

Hi there, I’d noticed something different between the rule promhttp:

in 1.1

    - handler: prometheus

in 1.0.6 (and in 1.1’s document ):

  - 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.

1 Like

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: ""
kind: handler
  name: prometheus
  compiledAdapter: prometheus

Config of the following form (using adapter specific kind) is deprecated:

apiVersion: ""
kind: prometheus
  name: handler

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 :slight_smile: 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.