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 <matthew_mi...@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)" <efrie...@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. > > > > > > >
