old_mixer_repo

old_mixer_repo copied to clipboard

Mixer configuration uses reference to other configuration elements. A fully qualified name of the resource includes namespace of that resource.

In case of an action

  handler: shortName.$namespace
  instances:
  - instance1_ShortName.$namespace
  - instance2_ShortName.$namespace

We can (and do) elide namespace. If a reference is not fully qualified, it is also assumed to be from the same namespace.

This however does not extend to adapter configuration. Prometheus config for example lists additional configuration by instance names, which must be fully qualified at present. Same is true with memquota.

apiVersion: config.istio.io/v1alpha2
kind: memquota
metadata:
  name: handler
  namespace: istio-config-default
spec:
  quotas:
  - name: requestcount.quota.istio-config-default    # <-- This should be shortName for 
                                                     # portable config
    maxAmount: 5000
    validDuration: 1s

The problem this creates it that someone must do a search and replace on the instance names to suit the desired namespace.

The other place namespace is used in config files is Resource.Metadata.Namespace, however we can remove this as well. istioctl -n or kubectl -n are both capable of setting a namespace while sending it to the server.

Question Is portable configuration desirable?

Options

1. Add on optional SetMetadata call to the builder. If the build implements this interface, we will it and set the configuration metadata. This includes namespace, name, etc.
2. Add a proto option. The adapter author add a proto option on fields that denote instances. Mixer will correctly convert them to fully qualified names based on context. 2b. We add a more generic annotation for references. The proto author annotates a field as being a reference. Mixer can handle it correctly.

Do they need to be fully qualified? Can we say like, shortName will point to the object in the same namespace?

@jmuk, yes shortName pointing to current namespace is the fix. The way you achieve it is by using one of the two options specified. I think this is a good goal to have.

istioctl -n or kubectl -n are both capable of setting a namespace while sending it to the server.

+1, if a namespace metadata property is not specified in the yaml, it should default to "default" unless overriden by the -n flag of istioctl. and then using the shortname when referencing other resources should qualify as the current namespace.