You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Durfey, Ryan" <Ry...@comcast.com> on 2017/09/01 20:16:13 UTC
Configuration Management - Rules Engine
Opening a new thread on the rules engine. Please keep responses in the email thread (vs. wiki). I will summarize once we conclude debate.
Rules Engine<https://cwiki.apache.org/#ConfigurationManagement-Rules_Engine>
* The rules engine is a part of the generic configuration concept but separates out trigger/action type configurations from parameter type configurations
* It allows non-technical users access to powerful customizations that can be validated before use and implemented in non-blocking LUA co-routines
* Service Parameters are stored in the config database as per usual operation
* Parameter Example:
* Serivce is Active or Non-Active
* Service considers Query Strings in URLs or Does Note
* Service Rules are stored in a specially formatted data table
* Rules Example:
*
Trigger
Action
Request to Origin
Sign URL using AWS v4 Signature and Key
URL format regex
Strip content from URL and add to header
Failure to connect to origin
Add cache control header to 502 response with 10 second value
*
* Rules Engine Provides
* List of Available Triggers
* List of Available Actions
* List of Required Parameters for Each Trigger / Action
* Rules for ATS and NGINX can be implemented with LUA Plugins to the C/C++ Code using LUA Scripting
* We can also potentially offer raw script fields for advanced users like CDN Owners
* Rules are generic and are interpreted in similar fashion to generic configuration parameters
* Rules engine builds in validation rules to ensure non-breaking changes
Ryan Durfey
Sr. Product Manager - CDN | Comcast Technology Solutions
1899 Wynkoop Ste. 550 | Denver, CO 80202
M | 303-524-5099
ryan_durfey@comcast.com<ma...@comcast.com>
CDN Support (24x7): 866-405-2993 or cdn_support@comcast.com<ma...@comcast.com>
Re: Configuration Management - Rules Engine
Posted by "Durfey, Ryan" <Ry...@comcast.com>.
Reviving a few conversations ahead of next week’s meetings.
Ryan Durfey M | 303-524-5099
CDN Support (24x7): 866-405-2993 or cdn_support@comcast.com<ma...@comcast.com>
From: Matthew Mills <Ma...@comcast.com>
Reply-To: "dev@trafficcontrol.incubator.apache.org" <de...@trafficcontrol.incubator.apache.org>
Date: Wednesday, September 6, 2017 at 12:06 PM
To: "dev@trafficcontrol.incubator.apache.org" <de...@trafficcontrol.incubator.apache.org>
Subject: Re: Configuration Management - Rules Engine
Hey Eric,
I think the intention of the “parameters” was to have a place to store the pieces that don’t fit into rules; I don’t think this has been very well planned out yet, and I also don’t think the examples listed make sense… I think a much better example is initial dispersion, which, while affecting the delivery services behavior, is applied in Traffic Router, where it wouldn’t make much sense to represent things in the rule format that might be used on the cache side. Another better example is the long_desc fields, they don’t have any configuration effect on the cache, but are used for various things.
-MM
On 9/5/17, 7:01:29 AM, "Eric Friedrich (efriedri)" <ef...@cisco.com>> wrote:
Actual Wiki link is here: https://cwiki.apache.org/confluence/display/TC/Configuration+Management#ConfigurationManagement-Rules_Engine
What is the difference between a parameter and a service rule? From the examples, it looks like parameters are all the legacy behaviors we have today and rules are many of the new behaviors we will shortly be adding.
Today we have a delivery service configuration that has many parameters (configuration) that are associated with implicit service rules (behaviors). For example, setting the Geoblock field contains configuration (CZF-only, which countries to allow) and there is always a hardcoded "service rule” to make use of that configuration.
The two “parameter” examples below follow the same pattern
- For active/non-active the configuration is boolean and the service rule either processes requests on that DS or rejects them
- For Query Strings, the configuration is “use”, “ignore”, “drop” and there is a service rule that implements the logic for those 3 options.
Similarly all of the Service Rules example can be broken into configuration + behavior.
It will be more work in the short term to get to this model, but IMO is more cohesive than having some behavior be parameters and some behaviors be service rules.
Re: Configuration Management - Rules Engine
Posted by "Eric Friedrich (efriedri)" <ef...@cisco.com>.
Thanks Matt-
I do think we’ll have rules on both the TR and the caches.
I also agree that there are some pieces that are simply configuration that don’t have associated rules
—Eric
> On Sep 6, 2017, at 2:59 PM, Mills, Matthew <Ma...@comcast.com> wrote:
>
> Hey Eric,
>
> I think the intention of the “parameters” was to have a place to store the pieces that don’t fit into rules; I don’t think this has been very well planned out yet, and I also don’t think the examples listed make sense… I think a much better example is initial dispersion, which, while affecting the delivery services behavior, is applied in Traffic Router, where it wouldn’t make much sense to represent things in the rule format that might be used on the cache side. Another better example is the long_desc fields, they don’t have any configuration effect on the cache, but are used for various things.
>
> -MM
>
> On 9/5/17, 7:01:29 AM, "Eric Friedrich (efriedri)" <ef...@cisco.com> wrote:
>
> Actual Wiki link is here: https://cwiki.apache.org/confluence/display/TC/Configuration+Management#ConfigurationManagement-Rules_Engine
>
>
> What is the difference between a parameter and a service rule? From the examples, it looks like parameters are all the legacy behaviors we have today and rules are many of the new behaviors we will shortly be adding.
>
> Today we have a delivery service configuration that has many parameters (configuration) that are associated with implicit service rules (behaviors). For example, setting the Geoblock field contains configuration (CZF-only, which countries to allow) and there is always a hardcoded "service rule” to make use of that configuration.
>
> The two “parameter” examples below follow the same pattern
> - For active/non-active the configuration is boolean and the service rule either processes requests on that DS or rejects them
> - For Query Strings, the configuration is “use”, “ignore”, “drop” and there is a service rule that implements the logic for those 3 options.
>
> Similarly all of the Service Rules example can be broken into configuration + behavior.
>
> It will be more work in the short term to get to this model, but IMO is more cohesive than having some behavior be parameters and some behaviors be service rules.
>
>
>
>
>
>
>
Re: Configuration Management - Rules Engine
Posted by "Mills, Matthew" <Ma...@comcast.com>.
Hey Eric,
I think the intention of the “parameters” was to have a place to store the pieces that don’t fit into rules; I don’t think this has been very well planned out yet, and I also don’t think the examples listed make sense… I think a much better example is initial dispersion, which, while affecting the delivery services behavior, is applied in Traffic Router, where it wouldn’t make much sense to represent things in the rule format that might be used on the cache side. Another better example is the long_desc fields, they don’t have any configuration effect on the cache, but are used for various things.
-MM
On 9/5/17, 7:01:29 AM, "Eric Friedrich (efriedri)" <ef...@cisco.com> wrote:
Actual Wiki link is here: https://cwiki.apache.org/confluence/display/TC/Configuration+Management#ConfigurationManagement-Rules_Engine
What is the difference between a parameter and a service rule? From the examples, it looks like parameters are all the legacy behaviors we have today and rules are many of the new behaviors we will shortly be adding.
Today we have a delivery service configuration that has many parameters (configuration) that are associated with implicit service rules (behaviors). For example, setting the Geoblock field contains configuration (CZF-only, which countries to allow) and there is always a hardcoded "service rule” to make use of that configuration.
The two “parameter” examples below follow the same pattern
- For active/non-active the configuration is boolean and the service rule either processes requests on that DS or rejects them
- For Query Strings, the configuration is “use”, “ignore”, “drop” and there is a service rule that implements the logic for those 3 options.
Similarly all of the Service Rules example can be broken into configuration + behavior.
It will be more work in the short term to get to this model, but IMO is more cohesive than having some behavior be parameters and some behaviors be service rules.
Re: Configuration Management - Rules Engine
Posted by "Eric Friedrich (efriedri)" <ef...@cisco.com>.
Actual Wiki link is here: https://cwiki.apache.org/confluence/display/TC/Configuration+Management#ConfigurationManagement-Rules_Engine
What is the difference between a parameter and a service rule? From the examples, it looks like parameters are all the legacy behaviors we have today and rules are many of the new behaviors we will shortly be adding.
Today we have a delivery service configuration that has many parameters (configuration) that are associated with implicit service rules (behaviors). For example, setting the Geoblock field contains configuration (CZF-only, which countries to allow) and there is always a hardcoded "service rule” to make use of that configuration.
The two “parameter” examples below follow the same pattern
- For active/non-active the configuration is boolean and the service rule either processes requests on that DS or rejects them
- For Query Strings, the configuration is “use”, “ignore”, “drop” and there is a service rule that implements the logic for those 3 options.
Similarly all of the Service Rules example can be broken into configuration + behavior.
It will be more work in the short term to get to this model, but IMO is more cohesive than having some behavior be parameters and some behaviors be service rules.
On Sep 1, 2017, at 4:16 PM, Durfey, Ryan <Ry...@comcast.com>> wrote:
Opening a new thread on the rules engine. Please keep responses in the email thread (vs. wiki). I will summarize once we conclude debate.
Rules Engine<https://cwiki.apache.org/#ConfigurationManagement-Rules_Engine>
* The rules engine is a part of the generic configuration concept but separates out trigger/action type configurations from parameter type configurations
* It allows non-technical users access to powerful customizations that can be validated before use and implemented in non-blocking LUA co-routines
* Service Parameters are stored in the config database as per usual operation
* Parameter Example:
* Serivce is Active or Non-Active
* Service considers Query Strings in URLs or Does Note
* Service Rules are stored in a specially formatted data table
* Rules Example:
*
Trigger
Action
Request to Origin
Sign URL using AWS v4 Signature and Key
URL format regex
Strip content from URL and add to header
Failure to connect to origin
Add cache control header to 502 response with 10 second value
*
* Rules Engine Provides
* List of Available Triggers
* List of Available Actions
* List of Required Parameters for Each Trigger / Action
* Rules for ATS and NGINX can be implemented with LUA Plugins to the C/C++ Code using LUA Scripting
* We can also potentially offer raw script fields for advanced users like CDN Owners
* Rules are generic and are interpreted in similar fashion to generic configuration parameters
* Rules engine builds in validation rules to ensure non-breaking changes
Ryan Durfey
Sr. Product Manager - CDN | Comcast Technology Solutions
1899 Wynkoop Ste. 550 | Denver, CO 80202
M | 303-524-5099
ryan_durfey@comcast.com<ma...@comcast.com>
CDN Support (24x7): 866-405-2993 or cdn_support@comcast.com<ma...@comcast.com>