vania-janet/multiturn-rag-retrieval-data huggingface dataset:
"id": "r134-411a798c-5816-4082-8ecb-554a440f83de",
"name": "my-instance-data"
},
"user_tags": []
}







 Viewing snapshots with Terraform 

You can use Terraform to view your snapshots.

To use Terraform, download the Terraform CLI and configure the IBM Cloud Provider plug-in. For more information, see [Getting started with Terraform](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-getting-started).

VPC infrastructure services use a regional specific based endpoint, which targets to us-south by default. If your VPC is created in another region, make sure to target the right region in the provider block in the provider.tf file.

See the following example of targeting a region other than the default us-south.

provider "ibm" {
region = "eu-de"
}



 Listing all snapshots with Terraform 

Import the details of a collection of snapshots as a read-only data source. You can filter the collection of snapshots by source_volume, resource_group, name, and so on.

data "ibm_is_snapshots" "example" {
}

For more information, see [ibm_is_snapshots](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/data-sources/is_snapshots).





 Listing details of a snapshot with Terraform 

Import the details of a snapshot as a read-only data source. You can specify either the snapshot ID or the snapshot name.

data "ibm_is_snapshot" "example" {
identifier = "r138-e6664842-b370-496a-9ae7-da3fb647707c"
}

data "ibm_is_snapshot" "example" {
If you apply the join() method to the values in the returned array, the flight codes are displayed in a comma-separated list. For example, you can use the following syntax in a response:

The flights that fit your criteria are:
<? T(String).join(",", $flights_found. ?>flight_code]

Result: The flights that match your criteria are: OK123,LH421,TS4156.







 JSONArray.joinToArray(template, retainDataType) 

This method extracts information from each item in the array and builds a new array that is formatted according to the template you specify. The template can be a string, a JSON object, or an array. The method returns an array of strings, an array of objects, or an array of arrays, depending on the type of template.

This method is useful for formatting information as a string you can return as part of the output of a dialog node, or for transforming data into a different structure so you can use it with an external API.

In the template, you can reference values from the source array using the following syntax:

%e.{property}%

where {property} represents the name of the property in the source array.

For example, suppose your assistant has stored an array containing flight details in a context variable. The stored data might look like this:

"flights": [!
{
"flight": "AZ1040",
"origin": "JFK",
"carrier": "Alitalia",
"duration": 485,
"destination": "FCO",
"arrival_date": "2019-02-03",
"arrival_time": "07:00",
"departure_date": "2019-02-02",
"departure_time": "16:45"
},
{
"flight": "DL1710",
"origin": "JFK",
"carrier": "Delta",
"duration": 379,
"destination": "LAX",
Local ensures that the source IP of your system is preserved when you curl the external IP of the LoadBalancer in the next step.

kubectl patch svc webserver-lb -p '{"spec":{"externalTrafficPolicy":"Local"}}'
5. Using the value from your cheat sheet, verify that you can still publicly access the NLB external IP address.

curl --connect-timeout 10 <loadbalancer_IP>:80

Example output

Hostname: webserver-855556f688-76rkp
Pod Information:
-no pod information available-
Server values:
server_version=nginx: 1.13.3 - lua: 10008
Request Information:
client_address=1.1.1.1
method=GET
real path=/
query=
request_version=1.1
request_scheme=http
request_uri=http://<loadbalancer_IP>:8080/
Request Headers:
accept=/
host=<loadbalancer_IP>
user-agent=curl/7.54.0
Request Body:
-no body in request-

In the Request Information section of the output, the source IP address is, for example, client_address=1.1.1.1. The source IP address is the public IP of the system that you're using to run curl. Otherwise, if you are connecting to the internet through a proxy or VPN, the proxy or VPN might be obscuring your system's actual IP address. In either case, the NLB sees your system's source IP address as the client IP address.
6. Copy your system's source IP address (client_address=1.1.1.1 in the previous step output) into your cheat sheet to use in later lessons.



Great! At this point, your app is exposed to the public internet from the public NLB port only. Traffic to the public node ports is blocked. Your cluster is partially locked down from unwanted traffic.
If you remove any access policies created by the source service for its dependent services, the source service is unable to complete the workflow or access the target service.

To delete an authorization policy, use the [IAM Policy Management API](https://cloud.ibm.com/apidocs/iam-policy-managementdelete-policy) as in the following sample request:



* Curl
* Java
* Python
* Go
* Node



curl -X DELETE 'https://iam.cloud.ibm.com/v1/policies/$POLICY_ID' -H 'Authorization: Bearer $TOKEN' -H 'Content-Type: application/json'

DeletePolicyOptions options = new DeletePolicyOptions.Builder()
.policyId(examplePolicyId)
.build();

service.deletePolicy(options).execute();

response = iam_policy_management_service.delete_policy(
policy_id=example_policy_id
).get_result()

print(json.dumps(response, indent=2))

options := iamPolicyManagementService.NewDeletePolicyOptions(
examplePolicyID,
)

response, err := iamPolicyManagementService.DeletePolicy(options)
if err != nil {
panic(err)
}

const params = {
policyId: examplePolicyId,
};

iamPolicyManagementService.deletePolicy(params)
.then(res => {
console.log(JSON.stringify(res, null, 2));
})
.catch(err => {
console.warn(err)
});

If the source service is removed from the account, any policies that are created by that service for its dependent services are deleted automatically. Similarly, if the dependent service is removed from the account, any access policies that are delegated to that service are also deleted.
* [Set up your Code Engine CLI environment](https://cloud.ibm.com/docs/codeengine?topic=codeengine-install-cli).
* [Create and work with a project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).





1. Run a build to build an image from a public Git repo and let Code Engine automatically store and access the image. For example, the following buildrun submit command runs a build run that is called helloworld-buildrun that builds from source in the public Git repo https://github.com/IBM/CodeEngine.

ibmcloud ce buildrun submit --name helloworld-buildrun --source https://github.com/IBM/CodeEngine --context-dir /hello



* In this example, the command uses the default dockerfile strategy, and the default medium build size.
* Because the branch name of the repository is not specified with the --commit option, Code Engine automatically uses the default branch of the specified repository, which is main for this Git repo.
* By not specifying the location of the image registry or a registry secret, Code Engine pushes the build output to IBM Cloud Container Registry with automatic access.
* Code Engine automatically determines whether your source resides in a repo or on a local workstation, based on the value of the --source option.



Example output

Submitting build run 'helloworld-buildrun'...
Creating image 'private.us.icr.io/ce--27fe9-glxo4k7nj7d/buildrun-helloworld-buildrun'...
Run 'ibmcloud ce buildrun get -n helloworld-buildrun' to check the build run status.
OK

The following table summarizes the options that are used with the buildrun submit command in this example.
From your source client in the IBM Cloud private network, test the connection to your Satellite endpoint by using the address. For example, depending on your source client, you might send a curl request to the endpoint.

curl http://<linkserver_hostname>:<port>







 Setting up source lists to limit access to endpoints 

Control which clients can access destination resources by creating a source list for an endpoint.

If no sources are configured, any client can use an endpoint to connect to the destination resource. For example, for a location endpoint, any client that is connected to the IBM Cloud private network can use the endpoint to connect to the destination resource that runs in your Satellite location. You can restrict access to your destination resource by adding only the IP addresses or subnet CIDRs of specific clients to the endpoint's source list.

Currently, you can create source lists only for endpoints of type location. You cannot create source lists for endpoints of type cloud.



1. From the [Satellite Locations dashboard](https://cloud.ibm.com/satellite/locations), click the name of your location.
2. From the Link endpoints tab, click the name of your endpoint.
3. In the Source list section, click Add source.
4. Choose an existing source or configure a new source and add it to the source list.



* To add an existing source, select the source name and click Add.
* To configure a new source, click Configure source to enter a source name and the IP address or subnet CIDR for the client that you want to connect to the endpoint, and click Add. Separate multiple IP addresses or subnet CIDRs with a comma (,).



5. Use the toggle to enable the source to connect to the destination resource. After you enable a source, network traffic to the destination through the endpoint is permitted only from clients that use an IP address in the range that you specified in the source. Network traffic from other clients that is sent to the destination resource through the endpoint is blocked.
6.
From this directory, run the git clone command; for example,

git clone https://github.com/IBM/CodeEngine
2. Go to the directory where your source code is on your workstation. For example, go to the CodeEngine subdirectory as this is the directory where the Code Engine Samples reside.
3. From the directory where your source code resides, submit the build run. The following example runs a build that is called buildrun-local-dockerfileand uses the build-local-dockerfile build configuration. The --source option specifies the path to the source on the local workstation to the helloworld sample.

ibmcloud ce buildrun submit --name buildrun-local-dockerfile --build build-local-dockerfile --source ./helloworld

Example output

Getting build 'build-local-dockerfile'
Packaging files to upload from source path './helloworld' ...
Submitting build run 'buildrun-local-dockerfile'...
Run 'ibmcloud ce buildrun get -n buildrun-local-dockerfile' to check the build run status.
OK
4. Monitor the progress of your build run by using the [ibmcloud ce buildrun get](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-build-get) command. For example, to check the status of the build run from the previous example,

ibmcloud ce buildrun get --name helloworld-build-run

Example output

Getting build run 'buildrun-local-dockerfile'...
Run 'C:Program FilesIBMCloudbinibmcloud.exe ce buildrun events -n buildrun-local-dockerfile' to get the system events of the build run.
Run 'C:Program FilesIBMCloudbinibmcloud.exe ce buildrun logs -f -n buildrun-local-dockerfile' to follow the logs of the build run.
OK
In the following example, to create the build configuration, use the [ibmcloud ce build create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-build-create) command. Use tutorial-build as the name of the build and specify https://github.com/IBM/CodeEngine as the location of the source code and /s2i-buildpacks as the context directory folder that contains your source. Use the dockerhub registry secret that was created previously for registry access. Specify buildpacks as the build strategy to compile the source code and specify small as the build size.

ibmcloud ce build create --name tutorial-build --source https://github.com/IBM/CodeEngine --commit main --context-dir /s2i-buildpacks --registry-secret dockerhub --image docker.io/<your_docker_ID>/tutorial --size small --strategy buildpacks

Example output

Creating build 'tutorial-build'...
OK

The size option specifies the size for the build, which determines the amount of resources that are used. Valid values are small, medium, large, xlarge. The size reflects the build requirements for your source code for your app or job. If the build fails due to lack of memory or disk space, or is not fast enough, try switching to a larger size. A larger build size also means that more memory and CPU cores are assigned to the build process. Increasing this size can probably speed up the build process, but this action also increases the cost. For more information about builds, check the [troubleshooting tips](https://cloud.ibm.com/docs/codeengine?topic=codeengine-troubleshoot-build).





 Step 3: Submit a build run 

Now that your build configuration is created, you can run a build based on that build configuration by using the [ibmcloud ce buildrun submit](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-buildrun-submit) command.
The build strategy option is allowed only if the --build-source option is set. If not specified, the build strategy is determined by Code Engine if --build-source is specified and the source is on your local machine. This value is optional. The default value is dockerfile.

--build-timeout, --bto
: The amount of time, in seconds, that can pass before the build must succeed or fail. The build timeout option is allowed only if the --build-source option is set. This value is optional. The default value is 600.

--cluster-local, --cl
: Deploy the application with a project-only endpoint. Setting a project-only endpoint means that your app is not accessible from the public internet and network access is only possible from other Code Engine components that are running in the same project. This value is optional. The default value is false.

--command, --cmd, -c
: Set commands for the application. Specify one command per --command option; for example, --cmd cmdA --cmd cmdB. This value overrides the default command that is specified within the container image. This value is optional.

--concurrency, --cn
: The maximum number of requests that can be processed concurrently per instance. This value is optional. The default value is 100.

--concurrency-target, --ct
: The threshold of concurrent requests per instance at which one or more additional instances are created. Use this value to scale up instances based on concurrent number of requests. If --concurrency-target is not specified, this option defaults to the value of the --concurrency option. This value is optional. The default value is 0.

--cpu
: The amount of CPU set for the instance of the application. For valid values, see [Supported memory and CPU combinations](https://cloud.ibm.com/docs/codeengine?topic=codeengine-mem-cpu-combo). This value is optional. The default value is 1.

--env, -e
For examples of setting the service's FQDN for the specific SDK language, see [SDK API examples](https://cloud.ibm.com/apidocs/transit-gateway?code=goapi-endpoint).





 Using Terraform 

If you plan to access the Transit Gateway service using Terraform, make sure to set the IBMCLOUD_TG_API_ENDPOINT environment variable to private.transit.cloud.ibm.com. For example:

export IBMCLOUD_TG_API_ENDPOINT=private.transit.cloud.ibm.com

For more information, see [Transit Gateway resources](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-tg-resource) and [Transit Gateway data sources](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-transit-gateway-ds).
--build-clear, --bc
: Remove the association of a build from this function. The build clear option is allowed only if your function currently has an associated build. This value is optional. The default value is false.

--build-commit, --commit, --bcm, --cm, --revision
: The commit, tag, or branch in the source repository to pull. This value is optional.

--build-commit-clear, --commit-clear, --bcmc, --cmc
: Clear the commit, tag, or branch in the source repository to pull. The commit clear option is allowed only if your function currently has an associated build. This value is optional. The default value is false.

--build-context-dir, --context-dir, --bcdr, --cdr
: The directory in the repository that contains the source code for your function. This option is allowed only if the --build-source option is set. This value is optional.

--build-git-repo-secret, --git-repo-secret, --bgrs, --grs, --repo
: The name of the SSH secret, which contains the credentials to access the private repository that contains the source code to build your image. This value is optional.

--build-git-repo-secret-clear, --git-repo-secret-clear, --bgrsc, --grsc
: Clear the SSH secret. This option is allowed only if your function currently has an associated build. This value is optional. The default value is false.

--build-source, --source, --bsrc, --src
: The URL of the Git repository or the path to local source that contains your source code; for example https://github.com/IBM/CodeEngine or .. This value is optional.

--build-strategy, --strategy, --bstr, --str
: The strategy to use for building the image.
For example, to set the prefix for all variable names of keys in secret secretName to CUSTOM_, use the value CUSTOM_=secretName. If the secret secretName contains KEY_A, the environment variable name is CUSTOM_KEY_A.
* To add environment variables for individual keys, use the format NAME:KEY_A,KEY_B. For example, to add an environment variable for a single key key1 in a secret that is named secretName, use the value secretName:key1. To assign a different name to a referenced key, use the format NAME:NEW_NAME=KEY_A. For example, to add an environment variable named myKey for a single key key1 in a secret that is named secretName, use the value secretName:myKey=key1.



This value is optional.

--force, -f
: Do not verify the existence of specified configmap and secret references. This value is optional. The default value is false.

--inline-code
: Specify the path to a file containing the source code for your function. The code is stored inline with the function. This value is optional.

--main, --fn-main
: Specify the name of your main function in the provided source code. This option is required when the name is not main. This value is optional. The default value is main.

--maxexecutiontime, --met
: The maximum execution time in seconds for this function to complete its run. This value is optional. The default value is 60.

--memory, -m
: The amount of memory that is set for the function. Use M for megabytes or G for gigabytes. For valid values, see [Supported memory and CPU combinations](https://cloud.ibm.com/docs/codeengine?topic=codeengine-mem-cpu-combo). This value is optional. The default value is 1G.

--no-wait, --nw
: Do not wait for the build run to complete. This value is optional. The default value is true.

--output, -o
curl "<public_URL_of_Kafka_sender_app>?topic=<your_topic_name>&num=<number_of_messages_to_produce>"

For example,

curl "https://kafka-sender-app.abcdabcdabc.us-south.codeengine.appdomain.cloud?topic=kafka-topic1&num=1"
3. View events in logs. When your Kafka event subscription is created with a broker, topics and an access secret that are valid, and you have a Kafka application that produces messages on that topic (such as kafka-sender-app), then you can see events in logs for your destination Code Engine application that receives Kafka messages, such as kafka-receiver-app. When you use the Kafka receiver app (icr.io/codeengine/kafka-receiver), search for Event data in the logs for the receiver application to see the messages that are received.

ibmcloud ce app logs -n kafka-receiver-app

Example output

Getting logs for all instances of application 'kafka-receiver-app'...
OK

kafka-receiver-app-00001-deployment-66976f7988-9xttm/user-container:
2022/03/31 22:19:45 Listening on port 8080
2022/03/31 22:19:46 ----------
2022/03/31 22:19:46 Path: /
2022/03/31 22:19:46 Header: Accept-Encoding=[gzip]
2022/03/31 22:19:46 Header: Ce-Id=[partition:0/offset:167]
2022/03/31 22:19:46 Header: Ce-Source=[/apis/v1/namespaces/glxo4k7nj7d/kafkasources/mykafkasubscriptionkafka-topic1]
global <br>Always included <br>boolean Allow global routing for a transit gateway <br>Example: true 
 status <br>Always included <br>string The status of the transit gateway. The list of enumerated values for this property may expand in the future. Code and processes using this field must tolerate unexpected values. <br>Possible values: [available,failed,pending,deleting] 
 resource_group <br>ResourceGroupReference The resource group to use. If unspecified, the account's [default resource group](https://console.bluemix.net/apidocs/resource-managerintroduction) is used. 
 <br><br> * id <br> Always included <br> string<br><br><br> The unique identifier for this resource group <br>Possible values: Value must match regular expression ^[0-9a-f]{32}$ <br>Example:56969d6043e9465c883cb9f7363e78e8 
 <br><br> * href <br> Always included= <br> URL<br><br><br> The URL for this resource group <br>Possible values: Value must match regular expression ^http(s)?://([^/?])([^?])(?([^]))?((.))?$ <br>Example:https://resource-manager.bluemix.net/v1/resource_groups/56969d6043e9465c883cb9f7363e78e8 
 updated_at <br>date-time The date and time that this gateway was last updated. 





Table 4. Status codes

 Status code 

 200 The Transit Gateway was updated successfully. 
 400 The supplied Transit Gateway patch was invalid. 
 404 A Transit Gateway with the specified identifier could not be found. 
 409 The Transit Gateway could not be updated as there are pre-existing cross-region connections attached. 





 Example Response 

This response indicates that the transit gateway was updated successfully:

{
See [CE_DATA for cron events](https://cloud.ibm.com/docs/codeengine?topic=codeengine-subscribe-cronsubcron-envvar-cedata). 
 CE_ID A unique identifier for the event, unless an event is replayed, in which case, it is assigned the same ID. 
 CE_SOURCE A URI-reference that indicates where this event originated from within the event producer. For cron events, this is a URI-reference with sub-domain for the project and the name of the cron subscription, in the following format: /apis/v1/namespaces/[PROJECT_SUBDOMAIN]/pingsources/[SUBSCRIPTION_NAME]. 
 CE_SPECVERSION The version of the CloudEvents spec. This value is always 1.0. 
 CE_TIME The time that the event was generated. 
 CE_TYPE The type of the event. For cron events, this is dev.knative.sources.ping. 





 CE_DATA environment variable 

For Periodic timer (cron) events, the CE_DATA environment variable contains the event itself and is in the format that you specify when you create or update the subscription.

Example output

CE_DATA={ "message": "Hello world!" }
CE_ID=abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f
CE_SOURCE=/apis/v1/namespaces/1234abcd1a2/pingsources/mycroneventjob
CE_SPECVERSION=1.0
CE_TIME=2021-04-13T17:41:00.429658447Z
CE_TYPE=dev.knative.sources.ping









 Defining additional event attributes 

When you create a subscription, you can define additional event attributes to be included in any events that are generated. These event attributes appear similar to any other CloudEvent attribute in the event delivery. If you choose to specify the name of an existing CloudEvent attribute, then it overrides the original value that was included in the event.