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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]><mailto:[email protected]> CDN Support (24x7): 866-405-2993 or [email protected]<mailto:[email protected]><mailto:[email protected]>
