-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Auto-configure middleware pipelines via priority and pipeline type properties #6660
Comments
Middleware does not target components, so I'm not clear on why or how a component would be used to specify a middleware. As a refresher, middleware apply to incoming HTTP requests to the Dapr API and outgoing HTTP requests to the app's API. As an aside, Configurations are not global. |
I like this proposal which I think makes using middlewares simpler. The current 2-step process can be confusing: it requires coordinating what's in the Component resource (defining the middleware and its spec) with the Configuration resource (actually enabling the middleware). A few questions:
|
Is the goal here to simplify the setting of a middleware? It'd be great to have a visualization of a priority chain with 2 middlewares with example YAMLs. If this is the intended proposal: apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: routerchecker1
spec:
type: middleware.http.routerchecker
version: v1
metadata:
- name: rule
value: "^[A-Za-z0-9/._-]+$"
- name: pipelineType
value: appHttpPipeline
- name: priority
value: 1 apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: routerchecker2
spec:
type: middleware.http.routerchecker
version: v1
metadata:
- name: rule
value: "^[A-Za-z0-9/._-]+$"
- name: pipelineType
value: appHttpPipeline
- name: priority
value: 2 And the intended outcome is that The issues I have are mainly around backwards compat and that Also, what happens if there are two middleware components with the same priority? this leads to the following question - if developers/operators want to change priority, how many and which steps would be required in order to do that? In the Configuration method, the call chain is visualized explicitly and changing priorities requires touching a single resource. |
Yes the goal is to simplify the activation of middleware and their ordering. This can be done via the middleware components themselves. It does not need to live in the Configuration CRD - but that can be maintained for backwards compatibility. Of course we can choose different reserved metadata fields. Keep in mind |
If both methods are defined, who wins? |
They are components. I know they don't target components. The idea is that config can shift into each components so that by looking at all components we can auto-generate / load / configure what today lives in the Configuration object for each app.
I always get confused about the ordering where it is applied. So thanks for the correction.
Ah, I forgot about the annotation |
Agree. We need to make sure that:
Yes we have lots of precedents, including "actorStateStore", "direction" (for bindings), etc.
My recommendation here is to show a warning and randomize the order they are loaded. We need to randomize them so users don't rely on an order "always" being returned. Also worth highlighting that a pattern is to allow priorities to be non-sequential. So users can define priorities "-100, -200, 0, 100, 200, 300" etc |
I like the simplicity offered here, for sure. |
Can we add an error to the components CRD controller for this and fail to apply the component? Or we can show a warning and apply a random ordering as @ItalyPaleAle mentions. For legacy reason let's not use a default priority value - if no priority is defined the middleware component isn't using the new approach.
Since priority do not need to be sequential the best practice would be to leave adequate spacing. This is not unlike DNS record priority best practices! You then only need to update a single component with the new priority value. If remember which component has which priority is a struggle (though hopefully you keep your component definitions in code), then maybe we can also update the METADATA API to show the effective ordering (and priorities) for each middleware pipeline for the given app. |
I think whenever an app uses the explicit Configuration CRD way to configure middlewares we should disregard the priority approach. The Configuration CRD is most explicit and therefore should always win, even if this is not the recommended approach (because it isn't the easiest approach) in the future. Only if the Configuration CRD doesn't configure the pipelines then we should inspect the priorities and build the pipeline automatically. What do you think @yaron2 @ItalyPaleAle ? |
I don't have a strong opinion either way. To recap the options for when there's a conflict (both a pipeline defined in the Configuration CRD, and one or more middleware(s) with the
IMHO they are all valid options (maybe 3 is the least desirable one, but still valid). |
Conceivably a given component could be used in both pipelines at the same time. So maybe it should be: - name: pipelineType
value: appHttpPipeline,httpPipeline
- name: priority
value: 2 or what about a way to configure distinct priorities for the different pipeline types - this would also support future pipeline types: - name: priority
value: appHttpPipeline:2
- name: priority
value: httpPipeline:5 Or that could be combined as: - name: priority
value: appHttpPipeline:2,httpPipeline:5 |
IMHO if you need to do that, create 2 separate components. One with |
Yes, that's preferable to different string variations. Re: conflict behavior, I support letting Configuration win if pipelines are present. |
This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions. |
keep-alive |
Since this is in the 1.13 milestone, I'm recapping here the final design. Goal: Simplify how middleware pipelines are defined, so users don't need to work with 2 separate kinds of resources (Component and Configuration). The current method will continue to work for backwards-compatibility and there's no plan to deprecate it at the moment (more on that later). Defining pipelines in Component metadata
The "priority" indicates the order of the component in the pipeline.
As per usual, Dapr only loads components that are scoped to that app ID. Interactions with the pipeline specified in the Configuration CRD If the Configuration CRD contains the definition of a middleware pipeline, Dapr uses the pipelines defined in there, ignoring pipelines that may be defined in Components (we will print a warning if we find that both are defined). This allows preserving backwards-compatibility. Using the Configuration CRD to define pipelines continues to be a supported method and we have no plans to deprecate this. We will continue to have tests to ensure this is not broken. However, this will become the "legacy" method. The new, simplified method is what we'll guide new users towards, and what we'll include in docs as the recommended approach. |
/assign |
This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions. |
This is a proposal to add a new mechanism for configuring Middlewares, directly from the component YAML instead of the Configuration CRD.
Each middleware would support the optional
priority
property via which the ordering can be determined in which a middleware components should be applied to a pipeline.Another property should be
pipelineType
with valueshttpPipeline
andappHttpPipeline
at this time.This also will allow scoping of middleware components to individual apps in Kubernetes without having to rely on a global configuration which may be invalid for an individual app.
The text was updated successfully, but these errors were encountered: