Skip to content
This repository has been archived by the owner on Jan 16, 2022. It is now read-only.

Introduce an attribute specialization framework #78

Closed
geeknoid opened this issue Jun 8, 2017 · 1 comment
Closed

Introduce an attribute specialization framework #78

geeknoid opened this issue Jun 8, 2017 · 1 comment
Assignees
Milestone

Comments

@geeknoid
Copy link

geeknoid commented Jun 8, 2017

We want to express caching in the proxy in terms of attributes. If a specific set of attributes remains constant for a given time and given # of uses, we can use a cached result for Check.

The attributes we have today often do not play well with the above goal because they aren't specific enough, leading to potentially completely ineffective caching. More specifically, there are cases where several different attribute values should be treated similarly from a caching perspective and are not. Some examples of this:

  • The quintessential example of this is request.size, where the semantics we'd like is "all request.size values < XXX".

  • Another example is request.time where we'd like to say things like "all requests between 12:00AM and 6:00AM".

  • Finally, request.url contains method names which we want to operate on specifically, having different cached answers for different methods.

The solution to these problems involves introducing an attribute specialization model within the client such that it can produce derived attributes based on its existing set. These derived attributes would be sufficiently fine-grained to allow effective caching. This can be driven by relatively simple code and simple configuration within the client. For example:

  • request.size. Generate the request.size.scale attribute which is a string assigned via config based on the range of the size. For example, the config can specify small:0..20, medium:21..200, large:201

  • request.time. Generate a variety of attributes automatically such as request.time.hour, request.time.dayOfWeek, etc. Also, generate the config-driven request.time.scheduledEvent attribute with stuff like offtimes: 0:00-6:00,18:00-23:59

  • request.url is broken down per Swagger
    In other words, we have specialized attribute processing algebra for a variety of attributes which is intended to produce new finer-grained attributes against which policies are applied in Mixer. To improve caching, we will encourage Mixer config to be authored using these derived attributes when possible.

We need to look at the individual attributes we produce and figure out what kind of specialization makes sense for each, and what kind of config syntax we want to control this. Finally, we need to decide which of these derived attributes are the most useful in the short term in order to prioritize implementation work.

@geeknoid geeknoid added this to the mixerclient beta milestone Jun 21, 2017
@sakshigoel12 sakshigoel12 modified the milestones: Istio 0.2, Istio 0.3 Sep 28, 2017
@geeknoid
Copy link
Author

geeknoid commented Mar 8, 2018

Issue moved to istio/proxy #1199 via ZenHub

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants