vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Kubernetes v1.17.9 v1.17.11 See the [Kubernetes release notes](https://github.com/kubernetes/kubernetes/releases/tag/v1.17.11). 
 Kubernetes add-on resizer 1.8.5 1.8.11 See the [Kubernetes add-on resizer release notes](https://github.com/kubernetes/autoscaler/releases/tag/addon-resizer-1.8.11). 
 Kubernetes configuration N/A N/A The Kubernetes API server audit policy configuration is updated to include auditing of all API groups except apiregistration.k8s.io and coordination.k8s.io. 
 Kubernetes Metrics Server v0.3.6 v0.3.7 See the [Kubernetes Metrics Server release notes](https://github.com/kubernetes-sigs/metrics-server/releases/tag/v0.3.7). 
 Kubernetes NodeLocal DNS cache configuration N/A N/A Increased the pod termination grace period. 







 Change log for worker node fix pack 1.17.11_1537, released 17 August 2020 

The following table shows the changes that are in the worker node fix pack 1.17.11_1537. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.



Changes since version 1.17.9_1535

 Component Previous Current Description 

 Kubernetes v1.17.9 v1.17.11 See the [Kubernetes change logs](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.17.mdv11711).
However, for better readability, Due Date is now available in incident issues so that users know the date when the fix is due without calculating it from the grace period.

If an issue such as vulnerability or CVE is found in production, and the same problem is also found in a build, the build does not make the situation worse. The feature can be deployed, and the team can focus on fixing the issue in production.





 Configuring custom grace periods on the CC pipeline 

The Continuous Compliance (CC) pipeline calculates the due dates of incident issues based on the severity of an issue. You can change the default grace period values and replace them with custom values.

The pipeline calculates the grace period according to the following table:



Table 1. Default grace periods

 Severity Grace Period 

 Informational 90 days 
 Low 45 days 
 Medium 45 days 
 High 15 days 
 Critical 15 days 



To change the default configuration, create a new property in the CC pipeline's environment properties named grace-period-configuration. This environment property must be a JSON string and match the following format:

{
"informational": 50,
"low": 40,
"medium": 30,
"high": 20,
"critical": 10
}

If the environment property does not match the expected format or is not a valid JSON string, the pipeline uses the default values.

The environment property grace-period-configuration sets due dates for issues that do not have a due date set already. For issues that have a due date set, reconfiguring the grace-period-configuration does not update those due dates.



 Due date calculation 

The date of finding is when the continuous compliance (CC) pipeline runs and finds the issue in the production environment. If the issue exists, CC updates it with the Due Date that is calculated from that moment.

<due date> = <date of finding the issue in prod> + <grace period in days (determined by severity)>





 Due date format 

Due date is in ISO 8601 format and shows as YYYY-MM-DD.

Example: Due Date: 2022-04-01





 Use cases
*  CLI







  Excluding all metrics by using the drop action 

You can configure IBM Cloud® Metrics Routing to exclude (drop) metrics based on a configured rule. Dropped metrics are not sent on to a target.



  Prereqs 



1.  [Install the IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-install-ibmcloud-cli).
2.  [Install the IBM Cloud Metrics Routing CLI](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-metrics-router-cli-config).
3.  Ensure you have the [correct IAM permissions to configure IBM Cloud Metrics Routing routes.](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-iam)
4.  Log in to IBM Cloud. Run the following command: [ibmcloud login](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_cliibmcloud_login).







  Configure the route 

Run the following command to exclude all metrics received by IBM Cloud Metrics Routing across all regions in the account.

ibmcloud metrics-router route create --name drop-all-route --rules '[{"action":"drop"}]'

The output of the command looks as follows:

Your request includes a drop rule. Do you want to continue? [y/N]> y
OK
Route
Name:         drop-all-route
ID:           4966172b-75c9-4adf-9cbb-36562a421b5b
CRN:          crn:v1:bluemix:public:metrics-router:global:a/xxxxxxxx::route:4966172b-75c9-4adf-9cbb-36562a421b5b
Rule 0:       [drop, ]]
Created At:   2023-05-30T14:52:02.148Z
Updated At:   2023-05-30T14:52:02.148Z
The autorization that you define for the IBM Cloud Metrics Routing service requires that you have Administrator role for the IBM Cloud Monitoring service.

To authorize a source service access to a target service, use the [IAM Policy Management API](https://cloud.ibm.com/apidocs/iam-policy-managementcreate-a-policy). See the following API example for Create a policy method with the type=authorization specified.

The supported attributes for creating an authorization policy depend on what each service supports. For more information about the supported attributes for each service, see the documentation for the services that you're using.



* Curl
* Java
* Python
* Go
* Node



curl --request POST --url https://iam.cloud.ibm.com/v1/policies --header 'Authorization: Bearer <token>' --header 'Content-Type: application/json' --data '{
"type": "authorization",
"subjects": [
{
"attributes":
{
"name": "accountId",
"value": "<account-id>"
},
{
"name": "serviceName",
"value": "metrics-router"
}
]
}
],
"roles": [
{
"role_id": "crn:v1:bluemix:public:sysdig-monitor::::serviceRole:Publisher"
}
],
"resources": [
{
"attributes":
{
"name": "accountId",
"value": "<account-id>"
},
{
"name": "serviceName",
"value": "sysdig-monitor"
}
]
}
]
}'

SubjectAttribute accountSubjectAttribute = new SubjectAttribute.Builder()
.name("accountId")
.value(exampleAccountId)
.build();
* Connections use TLS/SSL encryption for data in transit. The current supported version of this encryption is TLS 1.2.
* The storage where the configuration is stored is encrypted with LUKS using AES-256.







 Metrics data 

You can define 1 or more routing rules that define how metrics are routed in the account.



* Metrics data from an IBM Cloud service to your target service in IBM Cloud is secured via private connection. The connection supports TLS 1.2.
* You must define a service to service authorization to enable the IBM Cloud Metrics Routing service to send data to a IBM Cloud Monitoring instance.



You can store metrics data to an IBM Cloud Monitoring instance. You manage the instance and the data that is collected in the instance. For more information, see [Data security](https://cloud.ibm.com/docs/monitoring?topic=monitoring-mng-data).







 Deleting your data 



 Configuration data 

IBM Cloud Metrics Routing stores configuration data only.

You can delete any route, and target by using the API, the CLI or terraform scripts.

To stop IBM Cloud Metrics Routing from routing data to the configured targets, complete the following steps:



1. Delete all the routes in the account . For more information, see [Deleting a route](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-route-manage&interface=cliroute-manage-cli-delete).
2. [Remove any default targets](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-target-default-reset).



To delete a target, you must delete the target definition. Check that the target is not configured in a route. If it is, update the route to remove it.

To delete completely all the configuration data of the account, complete the following steps:



1. Delete all the routes in the account.
Use this command to get information about an IBM Cloud Metrics Routing route.

ibmcloud metrics-router route get --route ROUTE [--output FORMAT]



 Command options 

--route <ROUTE_ID>
: The name or ID of the route.

--output FORMAT
: If JSON is specified, output is returned in JSON format. If JSON is not specified, output is returned in a tabular format.

help | --help | -h
: List options available for the command.







 ibmcloud metrics-router route ls 

Use this command to list all the configured routes for IBM Cloud Metrics Routing in the account.

ibmcloud metrics-router route ls [--output FORMAT]



 Command options 

--output FORMAT
: If JSON is specified, output is returned in JSON format. If JSON is not specified, output is returned in a tabular format.

help | --help | -h
: List options available for the command.







 ibmcloud metrics-router target create 

Use this command to create a target to be used to configure a destination for platform metrics.

Targets must be IBM Cloud Monitoring instances.

ibmcloud metrics-router target create --name TARGET_NAME --destination-crn DESTINATION_TARGET_CRN [--region REGION] [--output FORMAT]



 Command options 

--region REGION | -r REGION
: Name of the region, for example, us-south or eu-gb. If not specified, the region that is logged into, or targeted, is used.

--name TARGET_NAME
: The name to be given to the target.

Do not include any personal identifying information (PII) in any resource names.

--destination-crn DESTINATION_TARGET_CRN
: The CRN of the service instance or resource to receive the metrics sent by IBM Cloud Metrics Routing. Ensure you have a service authorization between IBM Cloud Metrics Routing and your IBM Cloud resource. For more information, see [Managing authorizations to grant access between services.]
: API endpoint in the region where you plan to configure or manage a route. For more information, see [Endpoints](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-endpoints).

ROUTE_NAME
: The name to be given to the route.

Do not include any personal identifying information (PII) in any resource names.

RULES
: JSON formatted rules array definition in single quotes that define how metrics are routed. For more information, see [Defining routing rules](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-route_rules_definitions).

For example, you can use the following cURL request to create a route:

curl -X POST https://private.us-south.metrics-router.cloud.ibm.com/api/v3/routes -H "Authorization: $ACCESS_TOKEN" -H "content-type: application/json" -d '{
"name": "My-route",
"rules": [
{
"action": "send",
"targets":
{
"id": "50375218-7cff-4234-bbb4-171bebab8408"
},
{
"id": "c7519d8a-5f97-498b-a229-8542f60955cd"
}
],
"inclusion_filters":
{
"operand": "location",
"operator": "is",
"values": "us-east"]
},
{
"operand": "service_name",
"operator": "in",
"values": "atracker","containers-registry"]
}
]
}
]
}'





 Updating a route using the API 

You can modify the name of a route and rules.
By default, you'll receive only the summary of metrics which gives a minimum amount of information about DNS query requests, DNS query results, and custom resolver location health.

Open a Support case to enable the total metrics set.

Platform metrics are priced per usage.

Enabling the total metrics set increases the amount of metrics you receive, and can incur a greater cost depending on your usage.



 Data path summary metrics 

The data path summary metrics provide the request count and response count with the corresponding response codes.



Table 2. Data path metrics summary

 Metric name Labels 

 ibm_dns_svcs_dns_requests_summary not available 
 ibm_dns_svcs_dns_responses_summary rtype 



The labels correspond to the following definitions:



* rtype - Response type: NOERROR, SERVFAIL, and so on







 Data path total platform metrics 

Data path total platform metrics collect the following set of metrics in a DNS Services instance:



Table 3. Total DNS requests

 Metric name Labels 

 ibm_dns_svcs_dns_requests_total qtype, proto, family, accountid, zoneid, zonename, instanceid, vpcid, mtype 
 ibm_dns_svcs_dns_responses_total rtype, accountid, zoneid, zonename, instanceid, vpcid, mtype, cachehit 



The labels correspond to the following definitions:



* qtype - Resource records type: A, AAAA, CNAME, NS, MX, TXT, and so on
* rtype - Response type: NOERROR, SERVFAIL, and so on
* proto - Protocol type: UDP or TCP
* family - Transport family: IPv4 or IPv6
* accountid - ID of the account which owns the DNS Service instance configured for this query
* zoneid - ID of the zone for which the DNS query is configured for
* zonename - Name of the zone for which the DNS query is configured for
* instanceid - ID of the DNS Service instance configured for this query
Both CPU and memory have tunable "base" and "per node" settings used to compute a total request.

- baseCPU
- cpuPerNode
- baseMemory
- memoryPerNode

Where:

cpuRequest = baseCPU + cpuPerNode * number_of_nodes
memoryRequest = baseMemory + memoryPerNode * number_of_nodes

{: pre}

The number of nodes in these calculations comes from a set of "bucket sizes" and has a minimum size of 16 nodes.

CPU is requested in cores, with value such as 1 or fractional values such as 100m (100 millicores).

Memory is requested in bytes with an optional suffix of: - base 2 (1Ki = 1024): Ki (kilobytes), Mi (megabytes), Gi (gigabytes). - metric (1k = 1000): k, M, G.

If the number of nodes in a cluster is expected to grow (or just change) over time, you might want to adjust the "per node" setting. If the number of nodes is static, adjust the "base" setting. In the end, the total CPU and memory values are set in the metrics-server deployment resource requests.

You can change the default resources by editing the metrics provider's configmap. Do not modify the resource requests or limits directly in the metrics-server deployment, the values are overwritten by the metrics-server-nanny container.

The default metrics-server-config configmap is:

apiVersion: v1
kind: ConfigMap
metadata:
labels:
addonmanager.kubernetes.io/mode: EnsureExists
kubernetes.io/cluster-service: "true"
name: metrics-server-config
namespace: kube-system
data:
NannyConfiguration: |-
apiVersion: nannyconfig/v1alpha1
kind: NannyConfiguration

This example shows a ConfigMap with all values defined.

apiVersion: v1
Any specified value that is different from when the route was originally created will be updated to the value specified in the command.

ibmcloud metrics-router route update --route ROUTE [--name ROUTE_NAME] ( --rules RULES | --file RULES_DEFINITION_JSON_FILE ) [--output FORMAT] [--force]



 Command options 

--route ROUTE
: The ID or current route name.

--name route_NAME
: The name to be given to the route.

Do not include any personal identifying information (PII) in any resource names.

--rules RULES
: JSON formatted rules array definition in single quotes that define how metrics are routed. For more information, see [Defining routing rules](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-route_rules_definitions).

--file RULES_DEFINITION_JSON_FILE
: JSON file that includes the routing rules that define how metrics are routed. For more information, see [Defining routing rules](https://cloud.ibm.com/docs/metrics-router?topic=metrics-router-route_rules_definitions).

--output FORMAT
: Currently supported format is JSON. If specified, output will be returned in JSON format. If JSON is not specified, output will be returned in a tabular format.

help | --help | -h
: List options available for the command.





 Example 

The following is an example using the ibmcloud metrics-router route update --route my-route --name my-new-route-name command.

ibmcloud mr route update --route target1 --name target2
OK
Route
Name: target2
ID: 06a29ca2-40f5-4371-ae3c-76a896577bd3
Using custom Certificate Authority Signed Certificate See [Replace machine SSL certificates with custom certificates](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.authentication.doc/GUID-BF92822E-8005-4954-8BB5-09479A7B2165.html). 
 Configure vSphere monitoring vSphere includes a user-configurable events and alarms subsystem, which tracks events from vSphere components and stores the data in log files and the vCenter Server database. Events (Information, Warning, and Error) are records of user or system actions that occur on vSphere objects. Alarms are notifications that are activated in response to state of an vSphere object. Alarms have the following severity levels: Normal – green, Warning – yellow, and Alert – red. Alarm actions are operations that occur in response to an alarm, for example, an email notification is sent. For more information about how you can configure and use the vSphere monitoring, see [Monitoring events, alarms, and automated actions](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.monitoring.doc/GUID-9272E3B2-6A7F-427B-994C-B15FF8CADC25.html). 
 Adding clusters Your vCenter Server instance was deployed with a cluster of vSphere ESXi hosts. You can add more clusters to your instances to expand the compute and storage capacity. For more information, see [Adding clusters to vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_addingclusters). 
 vCenter Server capacity You can expand or contract the capacity of your VMware vCenter Server instance according to your business needs, by adding or removing vSphere ESXi servers or Network File System (NFS) storage.
For example, you can name the view Upload AT Frankfurt to indicate archive files into the bucket from an IBM Cloud Activity Tracker instance located in Frankfurt.

The data that is displayed through the view reports write actions of archive files to the archive bucket.







 Step 3. Define an alert to notify the absence of new archive files 

Complete the following steps to define an absence alert that notifies you when archiving is not happening:



1. Select the view name.

![Select view name](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker/images/archive-view-2.png)
2. Select Attach an alert. The following page opens.

![Select alert type](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker/images/archive-view-3.png)
3. Select View-specific alert.
4. Choose the notification channel.
5. Configure an Absence alert.

![Sample absence alert](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker/images/archive-view-3.png)

Archiving is configured hourly. Consider configuring the absence alert over a period of 24 hours to monitor archiving daily.



For more details on how to configure an alert, see [Creating alerts](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-alertsalerts_create).







 Configure an alert to detect unauthorize access to the bucket
"filter": null,
"type": "MANUAL",
"condition": "avg(timeAvg(uptime)) <= 0",
"timespan": 600000000,
"notificationChannelIds": [],
"reNotify": false,
"reNotifyMinutes": 30,
"segmentBy": [
"host.hostName"
],
"segmentCondition": {
"type": "ANY"
},
"severityLabel": "LOW"
}
}





 Update an alert 

To update an existing alert, you need the ID of that alert.

You can use the following cURL command to update an alert:

curl -X PUT <REST_API_ENDPOINT>/api/alerts/<ALERT_ID> -H "Authorization: $AUTH_TOKEN" -H "IBMInstanceID: $GUID" -H "TeamID: $TEAM_ID" -H "content-type: application/json" -d @alert.json

Where



* <REST_API_ENDPOINT> indicates the endpoint targetted by the REST API call. For more information, see [Monitoring REST API endpoints](https://cloud.ibm.com/docs/monitoring?topic=monitoring-endpointsendpoints_rest_api). For example, the public endpoint for an instance that is available in us-south is the following: https://us-south.monitoring.cloud.ibm.com/api
* You can pass multiple headers by using -H.

Authorization and IBMInstanceID are headers that are required for authentication.

TeamID is optional. When you specify this header, you limit the request to the data and resources available for the team specified.

To get an AUTH_TOKEN and the GUID see, [Headers for IAM Tokens](https://cloud.ibm.com/docs/monitoring?topic=monitoring-mon-curlmon-curl-headers-iam).
* <ALERT_ID> defines the ID of the alert that you want to modify.
* <REST_API_ENDPOINT> indicates the endpoint targetted by the REST API call. For more information, see [Monitoring REST API endpoints](https://cloud.ibm.com/docs/monitoring?topic=monitoring-endpointsendpoints_rest_api). For example, the public endpoint for an instance that is available in us-south is the following: https://us-south.monitoring.cloud.ibm.com/api
* You can pass multiple headers by using -H.

Authorization and IBMInstanceID are headers that are required for authentication.

TeamID is optional. When you specify this header, you limit the request to the data and resources available for the team specified.

To get an AUTH_TOKEN and the GUID see, [Headers for IAM Tokens](https://cloud.ibm.com/docs/monitoring?topic=monitoring-mon-curlmon-curl-headers-iam).
* You can pass data to create the alert in the alert.json file by using -d.

When you create an alert, include the following parameters: type, name, severity, timespan, condition, segmentby, segmentConditionn, filter, notificationChannelIds, enabled

For more information, see [Alert schema](https://cloud.ibm.com/docs/monitoring?topic=monitoring-alert_apialert-api-schema-req).



The following sample shows the request body parameters that you can set to create an alert:

{
"alert": {
"version": null,
"name": "My Alert!",
"description": null,
"teamId": null,
"enabled": false,
"filter": null,
"type": "MANUAL",
"condition": "avg(timeAvg(uptime)) <= 0",
"timespan": 600000000,
"notificationChannelIds": [],
"reNotify": false,
"reNotifyMinutes": 30,
"segmentBy": [
"host.hostName"
"ibmenapnsbody": "{"en_data":{"alert":"alert","url":"https","badge":9,"sound":"bingbong.aiff","payload":{"myaarray":["cc75e4a6-edd8-3bec-a7c3-dfca6572a03b"]},"type":"DEFAULT","subtitle":"dummy","title":"dummy1","body":"body","ios_action_key":"key","interactive_category":"interactiveCategory","title_loc_key":"titleLocKey","loc_key":"GAME_PLAY_REQUEST_FORMAT","launch_image":"image.png","title_loc_args":["Shelly","Rick"],"loc_args":["Shelly","Rick"],"attachment_url":"some url","apns_collapse_id":"12","apns_thread_id":"1","apns_group_summary_arg":"apnsGroupSummaryArg","apns_group_summary_arg_count":1}}"







 ibmenchromebody(string/json) 

This attribute is needed if you want to send push notification to a chrome device. This is the body that you want to send to web server, this must be JSON in string format. For more information regarding chrome body, follow this documentation [here](https://developer.mozilla.org/en-US/docs/Web/API/Notification).

You can follow these examples for quick start:

"ibmenchromebody": "{"title":"Hello Chrome", "options": {}}"





 ibmenfirefoxbody(string/json) 

This attribute is needed if you want to send push notification to a Firefox device.