vania-janet/multiturn-rag-retrieval-data huggingface dataset:
1. From the Devices menu, select Manage > Provisioning Scripts.
2. Select Add Provisioning Script.
3. Enter an identifying name for the provisioning script in the Name field.
4. Enter the fully qualified domain name that is associated with the script in the URL field.
5. Click Add to add the provisioning script to the account.







 Editing provisioning script details 



1. From the Devices menu, select Manage > Provisioning Scripts.
2. Click anywhere in the Name or URL column for the provisioning script to open the script for edits.
3. Update the name or URL. When you update a URL, you must use a fully qualified domain name or the change is not saved.
4. Click anywhere on the screen to save the edit.







 Next steps 

Provisioning scripts that are associated with an account can be modified or removed at any time. Provisioning scripts are saved in the IBM Cloud console until they are removed and can be associated to any new device ordered through the IBM Cloud console. If the script is associated with an HTTP URL, it's downloaded to the new device during provisioning and the administrator must log in to the device and run the script manually. Scripts that are associated with HTTPS URLs are downloaded and, when applicable, run on the new device without extra interaction required.

If you edit a script, valid updates are displayed on the screen immediately. Changes made to existing provisioning scripts do not impact devices already provisioned.
To evaluate if you have any failures in your pipeline run, check the final step of your pipeline, which has a pipeline evaluator.





 Customizing the pipeline 

Custom scripts are extension points in the pipeline where adopters, teams, and users can provide scripts to run custom tasks that are required by their continuous integration and continuous deployment strategies.

Custom scripts control the pipeline stages. Use the pipeline-config.yaml configuration file to configure the behavior of stages, script content, and the base image that runs the scripts. The scripts and configuration for pipeline stages are loaded from a Git repository (repo) that can either be the application (app) repo (similar to .travis.yml or Jenkinsfile) or a custom repo.

For more information on customizing the CI pipelines, see [Custom scripts](https://cloud.ibm.com/docs/devsecops?topic=devsecops-custom-scripts).





 Wrapping up 

By completing the CI part of this tutorial, you:



* Created a DevSecOps CI toolchain for Terraform.
* Modified some code in the infrastructure code repository.
* Ran the pr pipeline before you merge your changes.
* Ran the ci-pipeline to build, test, and deploy your changes to your dev environment.









 Related content 



* [Getting started with toolchains](https://cloud.ibm.com/devops/getting-started)
* [Getting started with Continuous Delivery](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-getting-started)







 Next steps 

Continue to [Part 3: Set up a CD toolchain for Infrastructure as Code](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-tutorial-iac-cd).
In the script field, enter a script or reference scripts that are stored in to your project’s source control.<br><br>Working directory: Specifies the directory where the script is run.<br><br>Build archive directory: Specifies the directory that contains the job's output to archive for use by a subsequent stage.<br><br>Enable test report: Select this checkbox to specify that the build job runs tests that produce result files in JUnit XML format. A report based on the result files is displayed on the Tests tab of the Job Results page. If any tests fail, the job is marked as failed.<br><br>Enable code coverage report: Select this checkbox to show more fields that you can use for the code coverage report. You can specify the Coverage runner (such as JaCoCo, and Cobertura), the location of the Coverage result file, and the Coverage result directory, relative to the Working directory. 
 Maven Builds by using Apache Maven. Pipeline image version: Runs in a container by using a built-in docker image, which provides various built-in commands. To adopt newer versions of those commands, use a newer image version.<br><br>Build script: Runs in a new Ubuntu shell whenever the job runs. In the script field, enter a script or reference scripts that are stored in to your project’s source control.<br><br>Working directory: Specifies the directory where the script is run.<br><br>Build archive directory: Specifies the directory that contains the job's output to archive for use by a subsequent stage.<br><br>Enable test report: Select this checkbox to specify that the build job runs tests that produce result files in JUnit XML format. A report based on the result files is displayed on the Tests tab of the Job Results page. If any tests fail, the job is marked as failed.<br><br>Enable code coverage report: Select this checkbox to show more fields that you can use for the code coverage report. You can specify the Coverage runner (such as JaCoCo, and Cobertura), the location of the Coverage result file, and the Coverage result directory, relative to the Working directory. 
 npm Installs dependencies with the Node package manager.
You don't need to deactivate when you run the all-backup-restore.sh script because the script handles the process.

To ensure that users don't have access to Knowledge Studio when you back up or restore a single database, stop the Knowledge Studio front-end pods before you back up or restore data.



1. Make sure that no training and evaluation processes are running. You can check job status with the following command:

kubectl -n NAMESPACE get jobs

Training jobs of Knowledge Studio are named in the format wks-train-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx, and evaluation jobs are named in the format wks-batch-apply-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. If the COMPLETIONS column of a training job reads 0/1, that job is still running. Wait until all of the training jobs finish.
2. kubectl -n NAMESPACE patch --type=merge wks wks -p '{"spec":{"global":{"quiesceMode":true}}}' kubectl -n NAMESPACE patch --type=merge wks wks -p '{"spec":{"mma":{"replicas":0}}}'
3. Ensure that no Knowledge Studio pods exist, except datastore pods, by running the following command (this may takes few minutes):

kubectl -n NAMESPACE get pod | grep -Ev 'minio|etcd|mongo|postgresql|gw-instance|Completed' | grep wks







 Reactivate Knowledge Studio 

You don't need to reactivate when you run the all-backup-restore.sh script because the script handles the process.

To reactivate Knowledge Studio, use the following command:

kubectl -n NAMESPACE patch --type=merge wks wks -p '{"spec":{"global":{"quiesceMode":false}}}'
ibmcloud ks script update [--in-place] FILE [FILE ...]

Minimum required permissions
: None

Command options:

--in-place
: Optional: Rewrite the source file with the updated command structure. If this option is not specified, you can see a summary of the changes to the script file in STDOUT.

FILE [FILE ...]
: The file that contains the scripts that you want to update.

To use this command to prepare your automation scripts for the release of version 1.0 of the IBM Cloud Kubernetes Service plug-in:



1. Run the command on a test script without the --in-place option.

ibmcloud ks script update ./mytestscript.sh
2. Review the proposed changes to the script in the difference that is shown in the command line STDOUT. Example output

--- a/script-test-2
+++ b/script-test-2
@@ -1,5 +1,5 @@
-ibmcloud ks logging-config-get --cluster mycluster
-ibmcloud ks logging-config-update --cluster mycluster --id myconfig --logsource application --type ibm --app-containers app1,app2,app3 --app-paths /var/log/path/
-ibmcloud ks logging-config-update --cluster mycluster --id myconfig --logsource application --type ibm --app-paths=/var/log/path/,/var/log/other/path/
-ibmcloud ks clusters -s --locations dal09,dal12 --output json
-ibmcloud ks subnets --locations sao01
+ibmcloud ks logging config get --cluster mycluster
+ibmcloud ks logging config update --cluster mycluster --id myconfig --logsource application --type ibm -C app1 -C app2 -C app3 -p /var/log/path/
* join_network.sh - Run this script when you want to join a peer organization to an existing channel. For more details see [Joining a network](https://ibm-blockchain.github.io/ansible-collection/tutorials/joining.html).
* deploy_smart_contract.sh - This script can be used to install a smart contract on one or more peers in your organization and instantiate it on a channel. For more details, see [Deploying the smart contract](https://ibm-blockchain.github.io/ansible-collection/tutorials/deploying.htmldeploying-the-smart-contract).



Before running any script, you need to update the console connection settings in the ordering-org-var.yml, org1-vars.yml, and org2-vars.yml files. Go ahead and try out the build_network.sh script by running the following Docker command from your tutorial folder:

docker run --rm -v "$PWD:/tutorials" ibmcom/ibp-ansible /tutorials/build_network.sh -i build

Notice that the playbooks will run even if the artifacts that you are deploying already exist. In that case, you can see in the PLAY RECAP status that changed=0, meaning the playbook detected that the node exists and did not try to re-create it. You can also run the build_network.sh with the destroy option to remove all the nodes and metadata that were created when you ran the build_network.sh script with the build option. Give it a try now by running the command:

docker run --rm -v "$PWD:/tutorials" ibmcom/ibp-ansible /tutorials/build_network.sh -i destroy





 Hints and Tips 



Table 1. Hints and tips for using the Ansible collection

 Tip Action 

 Increasing the wait timeout Some clusters perform faster than others. The scripts use a default wait timeout of 600 seconds, which is sufficient for most environments. The wait timeout represents the maximum amount of time the playbook waits for the underlying transactions to complete before it logs a failure.
All of the other configuration files are provided and do not need to be modified.





 Schematics deployment 

The configuration and script files are provided on the GitHub repository:



* ABAP: [https://github.com/IBM-Cloud/sap-netweaver-abap-hana/tree/main/schematics](https://github.com/IBM-Cloud/sap-netweaver-abap-hana/tree/main/schematics)
* JAVA: [https://github.com/IBM-Cloud/sap-netweaver-java-hana/tree/main/schematics](https://github.com/IBM-Cloud/sap-netweaver-java-hana/tree/main/schematics)



When you run the scripts with the Schematics interface, you:



* Enter workspace information.
* Enter the GitHub path for the chosen solution either on ABAP or JAVA stack.
* Modify the parameters in the Schematics interface. They are the same parameters as the input.auto.tfvars file that you use with the cli.







 Support - Terraform and Schematics 

There are no warranties of any kind, and there is no service or technical support available for these materials from IBM®. As a recommended practice, review carefully any materials that you download from this site before using them on a live system.

Though the materials provided herein are not supported by the IBM Service organization, your comments are welcomed by the developers, who reserve the right to revise, readapt or remove the materials at any time. To report a problem, or provide suggestions or comments, open a GitHub issue.





 Virtual server instance configuration 

For Netweaver primary application server:



* ibm-redhat-7-6-amd64-sap-applications-3
* ibm-redhat-8-4-amd64-sap-applications-2
* ibm-sles-15-3-amd64-sap-applications-2



For HANA DB:



* ibm-redhat-7-6-amd64-sap-hana-3
In the Script field, enter a script or reference scripts that are stored in your project’s source control.<br><br>Increment snapshot module version: Supports continuous delivery by incrementing the module version locally based on the contents of the package.json file and the current reported snapshot in the npm registry at the publish step.<br><br>Working directory: Specifies the directory where the script is run.<br><br>Build archive directory: Specifies the directory that contains the job's output to archive for use by a subsequent stage. 







 Deploy stage 

The deploy stage specifies input from a Build stage. The jobs in the deploy stage specify a Deployer type. The following Deployer types are available:



Table 2. Deployer types

 Deployer type Description Supported job types 

 Custom Docker image Deploys by using your custom Docker image with fine-grained control over the versions of node, Java™, or other tools. Pipeline image version: Runs in a container by using a built-in docker image that provides various built-in commands. To adopt newer versions of those commands, use a newer image version.<br><br>API key: The IBM Cloud API key to use to provide permissions to account resources.<br><br>Docker image name: The name of the image that this job builds and uploads to the IBM Cloud Container Registry.<br><br>Deploy script: Deploy command to run whenever the job runs. In the script field, enter a script or reference scripts that are stored in your project’s source control. 
 Kubernetes Deploys applications to Kubernetes clusters, such as those found within the IBM Cloud Container Service. Pipeline image version: Runs in a container by using a built-in docker image that provides various built-in commands. To adopt newer versions of those commands, use a newer image version.<br><br>API key: The IBM Cloud API key to use to provide permissions to account resources.<br><br>Cluster name: Name of the Kubernetes cluster; the platform that you deploy your Kubernetes components on.<br><br>Deploy script: Deploy command to run whenever the job runs.
Check out this topic on [Exploring the playbooks](https://ibm-blockchain.github.io/ansible-collection/tutorials/building.htmlexploring-the-playbooks) for more information about how each playbook works.

By now, you are probably interested in scripting these commands together to stand up or even tear down the components. The next section walks you through how to do that.





 Step five: Run a script 

At this point you've experienced how powerful the Ansible playbooks can be for programmatically deploying network components, creating channels and installing and instantiating smart contracts. But it is likely that you will want to script them together to build reproducible networks. That's why in the tutorial folder a set of scripts are provided that run groups of playbooks together in a logical order:



* build_network.sh - This is a script that runs a set of playbooks that create an entire simple network, the same one that can be created if you manually build the network by completing the [Build a network](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-build-network) tutorial. When you call the script with the build option, it configures a single node ordering service, a peer organization and a peer. It installs the FabCar smart contract on the peer, creates a channel and joins the peer to the channel. If you run the script with the destroy option it removes all of these artifacts from your cluster. For details, see [Building a network](https://ibm-blockchain.github.io/ansible-collection/tutorials/building.html).
* join_network.sh - Run this script when you want to join a peer organization to an existing channel. For more details see [Joining a network](https://ibm-blockchain.github.io/ansible-collection/tutorials/joining.html).
* deploy_smart_contract.sh - This script can be used to install a smart contract on one or more peers in your organization and instantiate it on a channel.
In such cases, you can use the SSH connection to the server to upload files with scp and then execute scripts on the server with ssh. The scripts could also retrieve software installers from the Internet, or from your on-premise systems assuming you have established a connection [such as a VPN](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-site2site-vpn) between your on-premise systems and the cloud.

The tutorial code contains a script named [uploaded.sh](https://github.com/IBM-Cloud/vpc-tutorials/blob/master/vpc-app-deploy/shared/uploaded.sh) which will be uploaded from your workstation to the virtual server instances (manually or through automation like Terraform and Ansible).

In the next sections, you will use the script [test_provision.bash](https://github.com/IBM-Cloud/vpc-tutorials/blob/master/vpc-app-deploy/test_provision.bash) to confirm that the servers have been provisioned successfully, are able (or not) to access the Internet and that the uploaded.sh script was correctly executed.







 Step 2: Using the IBM Cloud CLI and shell scripts 

The IBM Cloud CLI provides commands to interact with all the resources you can create in the IBM Cloud. This section explains how to use these commands, but you are not going to create any resources. It is recommended to use Terraform to deploy full solutions.



 Before you begin 

Install the command line (CLI) tools by [following these steps](https://cloud.ibm.com/docs/cli?topic=cli-install-ibmcloud-cli)





 Provision virtual server instances and install software 

The CLI has a [plugin for all VPC-related functionality](https://cloud.ibm.com/docs/cli?topic=cli-vpc-reference), including compute and network resources.



1. Before working with VPC resources, set the current resource group and region:
For a detailed step-by-step guide, see [AWS, Azure, GCP, and OCI workloads to IBM Cloud VPC](https://cloud.ibm.com/docs/cloud-infrastructure?topic=cloud-infrastructure-aws-azure-gcp-and-oci-workloads-to-ibm-cloud-vpc-vsi-migration-with-rackware-rmm).







 DIY automation 

There are several do-it-yourself (DIY) automation scripts made available to migrate workloads and data to IBM Cloud. The automation scripts are starter scripts that you can modify or adapt to your environment.

Since these scripts are open-sourced and without charge for use, there is no support or SLAs. For more information, see [Getting help and support for image and data migration](https://cloud.ibm.com/docs/cloud-infrastructure?topic=cloud-infrastructure-getting-help-support-image-data-migration).

There are three available sets of DIY automation scripts for you to use:



Table 5. Available DIY automation scripts

 Tool Description 

 Virtual server preparation and validation tool <br><br> * This tool ensures that the guest machine that you want to import to VPC as a custom image meets the [minimum requirements](https://cloud.ibm.com/docs/vpc?topic=vpc-about-imagescustom-image-reqs).<br> * The script is available in this [public GitHub repository](https://github.com/IBM-Cloud/vpc-migration-tools/tree/main/os-precheck-scripts).<br><br><br>
Do not use the IBM Cloud Dashboard and user interface to modify your VPC after it is created. The Terraform scripts create a complete solution and selectively modifying resources with the user interface might cause unexpected results.

If you need to remove the SAP NetWeaver 7.x and Db2 distributed installation, go to your project folder and run terraform destroy. The terraform destroy command does not remove the VPC in this scenario because the VPC was not created with the Terraform scripts.





 Related information 

For more information about Terraform on IBM Cloud, see [Terraform on IBM Cloud getting started tutorial](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-getting-started).

For more information about using Terraform for creating only a VPC for SAP, without the SAP architecture, see [Creating single-tier VPC for SAP on IBM Cloud® VPC with Terraform](https://cloud.ibm.com/docs/sap?topic=sap-create-terraform-single-tier-vpc-sap).

SAP One Support Notes that apply to this document:



* [SAP Note 84555 - Windows Server, Linux®, and UNIX: Certified hardware](https://launchpad.support.sap.com//notes/84855)
* [SAP Note 2927211 - SAP Applications on IBM Cloud Virtual Private Cloud (VPC) Infrastructure environment](https://launchpad.support.sap.com//notes/2927211)
* [SAP Note 2923773 - Linux® on IBM Cloud (IaaS): Adaption of your SAP License](https://launchpad.support.sap.com//notes/2923773)
* [SAP Note 2414097 - SAP Applications on IBM Cloud Classic Infrastructure environment](https://launchpad.support.sap.com//notes/2414097)
* [SAP Note 2369910 - SAP Software on Linux®: General information](https://launchpad.support.sap.com//notes/2369910)
<filepath_to_script>/register-host_mylocation_attach_hypershift.ign





2. Optional: If your hosts are RHEL hosts, you need to update the [required packages](https://cloud.ibm.com/docs/satellite?topic=satellite-host-reqs) on your hosts before you can run the script. If your hosts are running the latest Red Hat CoreOS images, you do not need to update the packages.
3. Attach your hosts to your location by running the attachment script.



* If your hosts are in another cloud provider, follow the provider-specific steps to run the script and attach your host.



* [Alibaba Cloud](https://cloud.ibm.com/docs/satellite?topic=satellite-alibaba)
* [Amazon Web Services (AWS)](https://cloud.ibm.com/docs/satellite?topic=satellite-aws)
* [Google Cloud Platform (GCP)](https://cloud.ibm.com/docs/satellite?topic=satellite-gcp)
* [Microsoft Azure](https://cloud.ibm.com/docs/satellite?topic=satellite-azure)
* [IBM Cloud](https://cloud.ibm.com/docs/satellite?topic=satellite-ibm)



* If your hosts are in an on-premises data center, see [Attaching on-premises RHCOS hosts](https://cloud.ibm.com/docs/satellite?topic=satellite-attach-hostsattach-rhcos-hosts) or [Attaching on-premises RHEL hosts](https://cloud.ibm.com/docs/satellite?topic=satellite-attach-hostsattach-rhel-hosts).





After you attach a host to your location, Satellite disables the ability to log in to the host via SSH for security purposes. You might see error messages if you try to SSH into a host that has been successfully attached to a location.
* The scripts download the client from the [MinIO website](https://dl.min.io/) if the client isn't installed.
* If you want the script to use your installed version, verify that you can run the client by issuing the command mc on the command line.









 all-backup-restore script 

The all-backup-restore.sh script backs up and restores the MongoDB, PostgreSQL, and Minio databases, and PVC.

Unless you only need to back up a single database, it is recommended that you use the all-backup-restore script, which deactivates and reactivates Knowledge Studio.

The script backs up or restores the data in the following order:



1. MongoDB
2. PostgreSQL
3. MinIO
4. PVC



all-backup-restore.sh [backup|restore] [RELEASE_NAME] [BACKUP_DIR] [-n NAMESPACE]

Use either the backup or restore command.



* backup

Backs up each database to a subdirectory of the BACKUP_DIR directory.
* restore

Restores the data from each database in the BACKUP_DIR directory.





 Arguments and options 



* RELEASE_NAME

Required. The release name that was specified when the Knowledge Studio Helm chart was installed in your cluster.

You can find the release name as the prefix of the pod name, for example, {release_name}-ibm-watson-ks-yyy-xxx. For version 1.2.0, the value is always wks.
* BACKUP_DIR

Required. The base directory of each database where backups are stored to or restored from. Each database is stored in a subdirectory of the backup directory. A new folder with timestamp wks-backup-yyyymmdd_hhmmss will be created under [backupDir], for example: [backupDir]/wks-backup-yyyymmdd_hhmmss/mongodb