Viewing Service Details

Modifying Customized Settings

A customized configuration rule consists of the configuration condition (Setting), access version (Version), and customized running parameters (including Setting Name and Setting Value).

You can configure different settings with customized running parameters for different versions of a real-time service.

The priorities of customized configuration rules are in descending order. You can change the priorities by dragging the sequence of customized configuration rules.

After a rule is matched, the system will no longer match subsequent rules. A maximum of 10 configuration rules can be configured.

Customized settings can be used in the following scenarios:

• If multiple versions of a real-time service are deployed for gray release, customized settings can be used to distribute traffic by user.

  Table 4 Built-in variables

  Built-in Variable	Description
  DOMAIN_NAME	Account name that is used to call an inference request
  DOMAIN_ID	Account ID that is used to call an inference request
  PROJECT_NAME	Project name that is used to call an inference request
  PROJECT_ID	Project ID that invokes the inference request
  USER_NAME	Username that is used to call an inference request
  USER_ID	User ID that is used to call an inference request

  Pound key (#) indicates that a variable is referenced. The matched character string must be enclosed in single quotation marks.

  #{Built-in variable} == 'Character string'
  #{Built-in variable} matches 'Regular expression'

  • Example 1:

    If the account name for invoking the inference request is User A, the specified version is matched.

    #DOMAIN_NAME == 'User A'

  • Example 2:

    If the account name in the inference request starts with op, the specified version is matched.

    #DOMAIN_NAME matches 'op.*'

    Table 5 Common regular expressions

    Character	Description
    .	Match any single character except \n. To match any character including \n, use (.|\n).
    *	Match the subexpression that it follows for zero or multiple times. For example, zo* can match z and zoo.
    +	Match the subexpression that it follows for once or multiple times. For example, zo+ can match zo and zoo, but cannot match z.
    ?	Match the subexpression that it follows for zero or one time. For example, do(es)? can match does or do in does.
    ^	Match the start of the input string.
    $	Match the end of the input string.
    {n}	n is a non-negative integer, which matches exactly n number of occurrences of an expression. For example, o{2} cannot match o in Bob, but can match two os in food.
    x|y	Match x or y. For example, z|food can match z or food, and (z|f)ood can match zood or food.
    [xyz]	Character set, where any single character in it can be matched. For example, [abc] can match a in plain.

    Figure 1 Traffic distribution by user
    
• If multiple versions of a real-time service are deployed for gated launch, customized settings can be used to access different versions through the header.
  Start with #HEADER_ to indicate that the header is referenced as a condition.

  #HEADER_{key} == '{value}'
  #HEADER_{key} matches '{value}'

  • Example 1:

    If the header of an inference HTTP request contains a version and the value is 0.0.1, the condition is met. Otherwise, the condition is not met.

    #HEADER_version == '0.0.1'

  • Example 2:

    If the header of an inference HTTP request contains testheader and the value starts with mock, the rule is matched.

    #HEADER_testheader matches 'mock.*'

  • Example 3:

    If the header of an inference HTTP request contains uid and the hash code value meets the conditions described in the following algorithm, the rule is matched.

    #HEADER_uid.hashCode() % 100 < 10

    Figure 2 Using the header to access different versions
    
• If a real-time service version supports different runtime configurations, you can use Setting Name and Setting Value to specify customized runtime parameters so that different users can use different running configurations.

  Example:

  When user A accesses the AI application, the user uses configuration A. When user B accesses the AI application, the user uses configuration B. When matching a running configuration, ModelArts adds a header to the request and also the customized running parameters specified by Setting Name and Setting Value.

  Figure 3 Customized running parameters added for a customized configuration rule