vania-janet/multiturn-rag-retrieval-data huggingface dataset:
--query-file or -f Optional The path to the JSON file containing queries. 
 --file or -f Optional Path to the JSON file containing the definition of an inventory. 
 --output or -o Optional Returns the command-line output in JSON format. Currently only JSON file format is supported. 
 --no-prompt Optional Set this flag to create the resource query without an interactive command-line session. 



Example

ibmcloud schematics resource-query update --id us-east.INVENTORY.inventory12312 --name inventoryname600 --description "Short description" --location us-east --resource-group Default --resource-query default.RESOURCEQUERY.string.12121







 Stop commands 

After invoking a job on a Schematics Workspaces like a plan, an apply, or a destroy. You may want to stop the running job, or want to stop provisioning resources. Stopping, or cancel a job helps you to know whether the job is stuck, does the job has lot of wait time? Schematics allows users to force-stop, interrupt, or terminate the running job.

Review the commands to force-stop, interrupt, or terminate job stop command.



 ibmcloud schematics workspace job stop 

Stops a running action or a job in IBM Cloud Schematics Workspaces.

Syntax

ibmcloud schematics workspace job stop --id WORKSPACE_ID --job-id JOB_ID [--cancel] [--force-stop] [--terminate]

Command options



Schematics job stop flags

 Flag Required / Optional Description 

 --id or -i Required The workspace ID to update. 
 --job-id or --jid Required The job ID of the job. 
 --interrupt, Optional Removes the job from the pending queue. 
 --force-stop or --fs Optional Sends a kill signal to the Terraform execution in the engine, also attempts to immediately stop the execution. 
 --terminate or -t Optional Abruptly kills the engine, marks the job as stopped, and unlocks your workspace. Data is not saved using this flag. 



Example
By default, the dashboard begins with the name "blank dashboard". You can change the name by selecting Dashboards from the sidebar, then clicking the Pencil icon next to the name.



To return to the default dashboard at any time, select Dashboards > Default Dashboards > IBM > Load Balancer Monitoring Metrics.





 Working with IBM Cloud Monitoring using the APIs 

You can also work with the monitoring instance by using the metric query APIs. You might want to do this if you need raw data points or want to consume your metrics from a command-line interface rather than using the IBM Cloud Monitoring dashboard.

After creating your monitoring instance, you must collect the following two pieces of information.



* The Monitor API token
* The endpoint of your IBM Cloud Monitoring instance



To collect this information and work with your monitoring instance using metric query API, follow these steps:



1. Access the [Monitoring home page](https://cloud.ibm.com/observe/monitoring), and click Open Dashboard next to the instance you want to work with. After the dashboard displays, select your Account Profile icon on the left sidebar, then select Settings. Your account settings display.
2. Your Monitor API token is an alphanumeric string that is located in the Monitor API Token field. Click the Copy button to the right of the key to transfer it to your clipboard.

Do not share this API token. Anyone who has this API token has full access to your metrics.
3. To get the endpoint of your IBM Cloud Monitoring instance, navigate to your main dashboard in your browser. Then, select the URL to the dashboard, which appears similar to:

https://us-south.monitoring.cloud.ibm.com//default-dashboard/ibm_is_load_balancer?last=3600

The first part of the URL (in this case, us-south.monitoring.cloud.ibm.com) is your endpoint. Make note of it.
4. After you have both the API token and the endpoint, you can format your POST request. The following POST request is an example, with all the parameters that you can modify. These parameters are:
3. From the Reserved IP side panel, have IBM select an IP address for you from the subnet that is listed, or select from existing IPs.

You can bind only one reserved IP to one endpoint gateway from each zone. To bind a reserved IP to an endpoint gateway, you must have an existing subnet. You need to also make sure that no subnets of the VPC that are bound to the same zone.
4. Specify whether you want to automatically delete the reserved IP if the endpoint gateway is deleted. Then, click Reserve IP address to bind the address to this endpoint gateway.







 Unbinding a reserved IP address 

Unbinding means that the selected reserved IP is no longer bound to the endpoint gateway. However, the IP address is still reserved and available to be bound again.

To unbind an IP address by using the IBM Cloud console, follow these steps:



1. From the Virtual private endpoint gateways for VPC page, highlight the row of the gateway in the table, then click Unbind IP from the Actions menu ![Actions menu](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc/images/overflow.png). Alternatively, you can unbind a reserved IP from an endpoint gateway's details page.
2. Click Unbind IP to confirm that you want to unbind this IP from the specified subnet.









 Binding and unbinding a reserved IP address from the CLI 

You can bind or unbind a reserved IP address by using the CLI.

Before you begin, make sure to [set up your CLI environment](https://cloud.ibm.com/docs/vpc?topic=vpc-infrastructure-cli-plugin-vpc-reference).



 Binding a reserved IP to an endpoint gateway 

To bind a reserved IP to an endpoint gateway by using the CLI, run the following command:
Select All current service instances.
5. Select the platform role Administrator.
6. Select the service role Manager.
7. Click Assign.







 Option 2. Grant permissions within the context of a resource group 

Complete the following steps to assign a user administrator role to the IBM Log Analysis service within the context of a resource group:



1. Select Assign access within a resource group.
2. Select a resource group.
3. If the user does not have a role that is already granted for the selected resource group, choose a role for the Assign access to a resource group field.

Depending on the role that you select, the user can view the resource group on their dashboard, edit the resource group name, or manage user access to the group.

You can select No access, if you want the user to have access only to the IBM Log Analysis service in the resource group.
4. Select IBM Log Analysis.
5. Select the platform role Administrator.
6. Select the service role Manager.
7. Click Assign.







 Option 3. Grant permissions in a location 

You can only provision 1 instance of the IBM Log Analysis service per location. Therefore, when you grant permissions by using this option, you are controlling access per location.

Complete the following steps to assign a user administrator role on one instance of the IBM Log Analysis service:



1. Select Assign access to resources.
2. Select IBM Log Analysis.
3. Select the instance.
4. Select the platform role Administrator.
5. Select the service role Manager.
6. Click Assign.









 Step 3. Add a user or service ID to the access group 

Continue to set up your group by adding users or service IDs.



 Add a user to the access group 

Complete the following steps to add a user:



1. From the menu bar, click Manage > Access (IAM), and select Access Groups.
2. Select the name of the group that you want to assign access to.
3. Click Add users on the Users tab.
4.
The available logical operators are case-sensitive and are AND, +, OR, NOT, and -. Range queries can run over strings or numbers.

If you want a fuzzy search, you can run a query with to find terms like the search term. For instance, look finds the terms book and took.

If the higher bounds of a range query are both strings that contain only numeric digits, the bounds are treated as numbers not as strings. For example, if you search by using the query mod_date:["20170101" TO "20171231"], the results include documents for which mod_date is between the numeric values 20170101 and 20171231, not between the strings "20170101" and "20171231".

You can alter the importance of a search term by adding ^ and a positive number. This alteration creates matches that contain the term more or less relevant, proportional to the power of the boost value. The default value is 1, which means no increase or decrease in the strength of the match. A decimal value of 0 - 1 reduces importance, making the match strength weaker. A value greater than one increases importance, making the match strength stronger.

Wildcard searches are supported, for both single (?) and multiple () character searches. For example, dat? would match date and data, and dat would match date, data, database, and dates. Wildcards must come after the search term.

Use : to return all results.

Result sets from searches are limited to 200 rows, and return 25 rows by default. The number of rows that are returned can be changed by using the [limit parameter](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-cloudant-searchquery-parameters-search).

If the search query does not specify the "group_field" argument, the response includes a bookmark. If this bookmark is later provided as a URL parameter, the response skips the rows that were seen already, making it quick and easy to get the next set of results.
If any date or date/time field supports any of the above comparisons, all date and date/time fields which the collection can be filtered on MUST support all of the above comparisons.





 Identifier and enumeration fields 

Identifier and enumeration fields MAY support the following comparisons:



* Not equal, by prefixing a value with not:
* In a set, by providing a comma-separated list of values
* Not in a set, by prefixing a comma-separated list of values with not:



If any enumeration or identifier field supports any of the above comparisons, all enumeration and identifier fields which the collection can be filtered on MUST support all of the above comparisons. Identifier and enumeration values MUST be matched case-insensitively.





 String fields 

String fields MAY implicitly match fields which contain the provided value instead of requiring an exact match. String field matching also MAY be case-insensitive. Additionally, string fields MAY support prefixing a value with not: in order to invert the default matching logic.







 Advanced querying 

Careful consideration should be given to providing any advanced query syntax. It is preferred that any syntax exposed not constrain future technology choices to a specific backend technology. For this reason, services SHOULD expose only a well-specified, standardized query syntax. If the service itself parses queries, care should be taken that it does so in a robust, secure manner.
The number must be a positive integer between 1 and 200. The default value is -1. 
 --offset or -m Optional The position of the resource query in the list of resource queries. For example, if you have three resource queries in your account, the command returns these resource queries as a list with three elements. To see a specific resource query in this list, you must enter the position number that the resource query has in the list. To list the first resource query in the list, enter 0. To list the second resource query, enter 1 and so forth. Negative numbers are not supported and are ignored. The default value is -1. 
 --output or -o Optional Specify the output format. Only JSON format is supported. 



Example

ibmcloud schematics resource-query list --output listoutput.json





 ibmcloud schematics resource query update 

Update or replace a resource query creates a copy of an resource query and relaunches an existing resource query by updating the information of an existing IBM Cloud Schematics resource query.

Syntax

ibmcloud schematics resource-query update --id ID --name RESOURCE_QUERY_NAME [--type RESOURCE_QUERY_TYPE] [--query-file QUERY_FILE_PATH] [--file FILE_NAME ] [--output OUTPUT] [--no-prompt]

Command options



Schematics resource query update flags

 Flag Required / Optional Description 

 --id or -i Required The resource query ID. 
 --name or -n Required The unique name for a resource query. 
 --type or -t Optional The type of the resource query. such as vsi 
 --query-file or -f Optional The path to the JSON file containing queries. 
 --file or -f Optional Path to the JSON file containing the definition of an inventory. 
 --output or -o Optional Returns the command-line output in JSON format. Currently only JSON file format is supported. 
 --no-prompt Optional Set this flag to create the resource query without an interactive command-line session. 



Example
Exporting and importing the query history 

The Presto coordinator stores the query history in system.runtime.queries table. But system.runtime.queries table truncates when you restart Presto, resulting in loss of query history. To mitigate this issue, you can export query history as a csv file and also import the query history from the system.runtime.queries table to a non-system table.

It is recommended to periodically export the query history to avoid losing it.

To import and export the query history, you must install the Presto CLI. For more information, see [Connecting to Presto server](https://cloud.ibm.com/docs/watsonxdata?topic=watsonxdata-con-presto-serv).



 Exporting query history 

To export the query history, run the following command.

export PRESTO_PASSWORD=<your api_key>

./presto --server https://<port:host> --catalog system --schemaruntime --execute "select * from queries" --user ibmlhapikey --output-format CSV_HEADER > history.csv --password

This command generates a CSV file, which contains exported query history.



* Example



./presto --server https://8dac613f-ba5b-4c3c-8c96-
ce8de101f7cf.cdc406pd09pasng7elgg.databases.appdomain.cloud:30929 --execute "select * from system.runtime.queries" --output-format CSV_HEADER --user ibmlhapikey output-format CSV > history.csv --password





 Importing query history 



1. To import the query history, create a schema in a catalog in which you have the write access.

create schema <non-system-catalog.schema-name> with (location=' s3a://<bucket-name>/<schema-name>')



* Example
--output or -o Optional Specify the output format. Only JSON format is supported. 



Example

ibmcloud schematics resource-query list --output listoutput.json





 ibmcloud schematics resource query update 

Update or replace a resource query creates a copy of an resource query and relaunches an existing resource query by updating the information of an existing IBM Cloud Schematics resource query.

Syntax

ibmcloud schematics resource-query update --id ID --name RESOURCE_QUERY_NAME [--type RESOURCE_QUERY_TYPE] [--query-file QUERY_FILE_PATH] [--file FILE_NAME ] [--output OUTPUT] [--no-prompt]

Command options



Schematics resource query update flags

 Flag Required / Optional Description 

 --id or -i Required The resource query ID. 
 --name or -n Required The unique name for a resource query. 
 --type or -t Optional The type of the resource query. such as vsi 
 --query-file or -f Optional The path to the JSON file containing queries. 
 --file or -f Optional Path to the JSON file containing the definition of an inventory. 
 --output or -o Optional Returns the command-line output in JSON format. Currently only JSON file format is supported. 
 --no-prompt Optional Set this flag to create the resource query without an interactive command-line session. 



Example

ibmcloud schematics resource-query update --id us-east.INVENTORY.inventory12312 --name inventoryname600 --description "Short description" --location us-east --resource-group Default --resource-query default.RESOURCEQUERY.string.12121







 Stop commands 

After invoking a job on a Schematics Workspaces like a plan, an apply, or a destroy. You may want to stop the running job, or want to stop provisioning resources. Stopping, or cancel a job helps you to know whether the job is stuck, does the job has lot of wait time? Schematics allows users to force-stop, interrupt, or terminate the running job.
datetime
clientCountryName
}

The query response follows:

{
"firewallEventsAdaptive" : [
{
"datetime": "2018-11-12T00:00:00Z",
"clientCountryName": "US"
},
{
"datetime": "2018-11-12T00:00:00Z",
"clientCountryName": "UM"
}
]
}







 Filtering 

Filters constrain queries to a particular account or set of zones (domains), requests by date, or a specific query agent. Without filters, performance might degrade, and results might include unimportant data.



 Structure 

The GraphQL filter is represented by the [GraphQL Input Object](http://spec.graphql.org/June2018/sec-Input-Objects).

Filters can be used as an argument on the following resources:



* Zones (Domains)
* Tables (data sets)
* Accounts







 Zone (domain) filter 

The zone filter allows querying zone-related data by zone (domain) ID (zoneTag).

zones(filter: {zoneTag: "your domain (zone) ID"}) {
...
}

The zone filter must conform to the following grammar:

filter
{ zoneTag: t }
{ zoneTag_gt: t }
{ zoneTag_in: [t, ...] }

Compound filters (comma-separated, AND, OR) are not supported. Zones always sort alphanumerically.





 Table (data set) filter 

Table filters require that you query at least one node. The AND operator can be used to create and combine multi-node filters.





 Accounts filter 

Account level filtering is supported, and there is a required filter parameter. For example:

accounts(filter: {accountTag: $accountTag}) {
...
}





 Operators 

Operator support varies, depending on the node type and node name. The following operators are supported for all types:
Query system notices [GET /v1/environments/{environment_id}/collections/{collection_id}/notices](https://cloud.ibm.com/apidocs/discoveryquerynotices) [GET /v2/projects/{project_id}/collections/{collection_id}/notices](https://cloud.ibm.com/apidocs/discovery-dataquerycollectionnotices) 
 Query multiple collection system notices [GET /v1/environments/{environment_id}/notices](https://cloud.ibm.com/apidocs/discoveryfederatedquerynotices) [GET /v2/projects/{project_id}/notices](https://cloud.ibm.com/apidocs/discovery-dataquerynotices) 
 Get Autocomplete suggestions [/v1/environments/{environment_id}/collections/{collection_id}/autocompletion](https://cloud.ibm.com/apidocs/discoverygetautocompletion) [GET /v2/projects/{project_id}/autocompletion](https://cloud.ibm.com/apidocs/discovery-datagetautocompletion) <br>See the [query notes](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-migrate-to-v2-apimigrate-to-v2-api-queries-notes). 



Some query result configurations are applied to the service by default based on the type of project that you create. For more details, see [Default project settings](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-project-defaults).



 Query notes 



* v2 queries return results from all of the collections in the project. To restrict the query to use only certain collections within the project, use the collection_ids query parameter. You cannot query multiple collections that are added to different projects with one v2 query request.
* v2 results include a confidence field, but not a score field.

The confidence score replaced the score information in v1, but score was retained for backward compatibility.
* For use cases where many users interact with the application that uses Discovery, you can estimate by calculating the number of searches per user times the number of expected users. For example, 50% of the questions that are submitted by users to a virtual assistant are likely to be answered by Discovery. With 100,000 users per month and an average of 3 questions per user, you can expect 15,000 queries per month. (10,000 users/mo * 3 queries/user * 50% to Discovery = 15,000)







 Querying with document-level security enabled 

IBM Cloud Pak for Data

IBM Cloud Pak for Data only

This information applies only to installed deployments.

If you enable document-level security for a collection, only documents that the current user has permission to access are returned in search results. For more information, see [Configuring document-level security](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-collection-typesconfiguredls).

To return search results that adhere to the security restrictions, the current user must meet these requirements:



* Have access to your Discovery instance.
* Have access to the data source.



If the current user does not meet these requirements, no search results are returned.

The username that is associated with your Discovery instance is used to generate an authorization token. The token is used to authenticate Discovery queries.

To generate each access token, run the following command:

curl -u "{username}:{password}" "https://{hostname}:{port}/v1/preauth/validateAuth"

Replace {username} and {password} with the user's Discovery credentials.

Use the bearer token that is associated with the user when you run the query.

curl -H "Authorization: Bearer {token}" 'https://{hostname}/{instance_name}/v2/projects/{project_id}/collections/{Collection_ID}/query?version=2019-11-29'
* The resolver for virtual server 1 is an on-premises DNS server, so the DNS query is sent to 192.58.5.2.
* The DNS server is based on the forwarding rule, and sends the query to the custom resolver 10.20.30.5.
* The custom resolver is based on the forwarding rule, and sends the query to Private DNS 161.26.0.7/8.
* The Private DNS responds with database.ibmcloud.example.com A 10.20.30.50.
* The custom resolver responds to the query and caches the response.
* The DNS server responds to the query to virtual server 1 and caches the response.





In this example, Direct Link is used to connect to on-premises DNS service/clients with a custom resolver in the VPC. Direct Link can be replaced with a transit gateway to connect other VPCs or public gateways in a subnet with a custom resolver.







 Forwarding DNS queries to DNS Services servers 

To forward DNS queries on a specific DNS zone to DNS Services servers, enter the forwarding IP addresses 161.26.0.7 and 161.26.0.8.





 Forwarding DNS queries to a public resolver 

To forward DNS queries on a specific DNS zone to public resolvers on the internet, create a public gateway and attach it to the subnet used for the custom resolver location. Do this before entering the public resolver IP addresses as the forwarding IP.

For more information about connecting to external networks, see [External connectivity](https://cloud.ibm.com/docs/vpc?topic=vpc-about-networking-for-vpcexternal-connectivity).





 Forwarding DNS queries across VPCs 

You might want to create custom resolvers on multiple VPCs and use these custom resolvers to follow the spoke-and-hub paradigm. In this configuration, you must interconnect the VPCs through a transit gateway in advance.