vania-janet/multiturn-rag-retrieval-data huggingface dataset:
https://ibm-cloud-cli.s3.private.us.cloud-object-storage.appdomain.cloud/<release_tag>/IBM_Cloud_CLI_<release_tag>.pkg





 Windows™ 64-bit 

https://ibm-cloud-cli.s3.private.us.cloud-object-storage.appdomain.cloud/<release_tag>/IBM_Cloud_CLI_<release_tag>_amd64.exe





 Windows™ 32-bit 

https://ibm-cloud-cli.s3.private.us.cloud-object-storage.appdomain.cloud/<release_tag>/IBM_Cloud_CLI_<release_tag>_386.exe





 Linux™ 64-bit 

https://ibm-cloud-cli.s3.private.us.cloud-object-storage.appdomain.cloud/<release_tag>/IBM_Cloud_CLI_<release_tag>_amd64.tar.gz





 Linux™ 32-bit 

https://ibm-cloud-cli.s3.private.us.cloud-object-storage.appdomain.cloud/<release_tag>/IBM_Cloud_CLI_<release_tag>_386.tar.gz





 PowerLinux™ 64-bit 

https://ibm-cloud-cli.s3.private.us.cloud-object-storage.appdomain.cloud/<release_tag>/IBM_Cloud_CLI_<release_tag>_ppc64le.tar.gz





 System/390 Linux™ 64-bit 

https://ibm-cloud-cli.s3.private.us.cloud-object-storage.appdomain.cloud/<release_tag>/IBM_Cloud_CLI_<release_tag>_s390x.tar.gz







 Installing to a custom directory 

When you use installers or a shell script to install the IBM Cloud CLI, it is installed in your system directories. If you want to specify a different directory, use the following steps.
[Checkbox icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/checkbox-icon.svg) Upload a readme file Provide a readme file that describes how users can install your software and get customer support. Your GitHub or GitLab repository 
 ![Checkbox icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/checkbox-icon.svg) Onboard your software Import a version, configure the deployment details, set any license requirements, and validate that the version can be successfully installed on the infrastructure that you require. IBM Cloud console 



For more information, see the following links:



* [Setting up your source code repository](https://cloud.ibm.com/docs/sell?topic=sell-source-repo-setup)
* [Onboarding your software](https://cloud.ibm.com/docs/sell?topic=sell-sw-validate)







 Publish your product 

The following tasks are completed by any member of your team.



Table 4. Tasks for publishing software

 Task Description Environment 

 ![Checkbox icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/checkbox-icon.svg) Verify that all tasks are completed Confirm that you completed the getting started tasks, defined your software details, and onboarded your software. IBM Cloud console 
 !
Some topics that are covered, consider that the reader has basic deployment skills to install and configure vSphere and vCenter.



* [Build a Single Site VMware® Environment](https://cloud.ibm.com/docs/virtualization?topic=virtualization-advanced-single-site-vmware-reference-architecture) You, as the vSphere administrator, are walked through the steps of building your environment, including the use of either Endurance or Performance Block Storage or QuantaStor.
* [vSphere Migration](https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.update_manager.doc/GUID-F7191592-048B-40C7-A610-CFEE6A790AB0.html) Scenarios are presented to help you migrate workloads into VMware® after your vSphere implementation is deployed in an IBM Cloud data center.
* [Use NSX®](https://developer.ibm.com/recipes/tutorials/?s=nsx) You can use VMware® NSX to provide software-defining networking (SDN) constructs to VMware® IBM Cloud deployments.
* [VMware® backup](https://www.vmware.com/pdf/vi3_30_20_vm_backup.pdf) describes alternative approaches to backing up, recovering, and archiving VMware-based workloads that are running in a VMware deployment.
* [VMware® disaster recovery guide](https://docs.vmware.com/en/Site-Recovery-Manager/index.html) Documentation for VMware® Site Recovery Manager.
* [Vormetric Encryption of VMware®](http://go.thalesesecurity.com/rs/480-LWA-970/images/VMware-Encryption-and-KMIP-Integration-with-Vormetric-Data-Security-Manager-Integration-guide.pdf) Vormetric protects VMware® workloads by encrypting VM data.
[AMI Installation Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_vrouter_ami_installation_5600.pdf) This guide describes how to install AT&T Vyatta vRouter Amazon Machine Image (AMI) within the Amazon Web Services (AWS) cloud. 
 [Deployment Options Configuration Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_vrouter_deployment_options_configuration_5600.pdf) This guide describes deployment options for the AT&T Vyatta vRouter. 
 [Hard Disks and Persistent Devices Installation Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_vrouter_hard_disks_and_persistent_devices_installation_5600.pdf) This guide describes how to install and upgrade software on a persistent device, such as hard disk, flash drive, or USB stick on AT&T products that run on the AT&T Vyatta Network Operating System. 
 [Hyper-V Installation Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_vrouter_hyper-v_installation_5600.pdf) This guide describes how to install and upgrade the AT&T Vyatta vRouter running on Hyper-V systems. 
 [Linux KVM Installation Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_vrouter_linux_kvm_installation_5600.pdf) This guide describes how to install and upgrade the AT&T Vyatta vRouter running on Linux KVM environment.
This user data yaml will create a full partition on the first
 virtio_blk device after the boot device, initialize ext4 on it and
 mount it on a folder matching the label.

disk_setup:
  /dev/vdb:
    table_type: 'mbr'
    layout:
    - 100
    overwrite: false

fs_setup:
  - label: /mnt/inststg1
    filesystem: 'ext4'
    device: /dev/vdb1
    overwrite: false

runcmd:
  - [ mkdir, /mnt/inststg1 ]

mounts:
  - ["/dev/vdb1", "/mnt/inststg1"]

mount_default_fields: [ None, None, "auto", "defaults,nofail", "0", "2" ]
Show more

This script configures /dev/vdb, the first instance storage device with virtio_blk interface type available on the virtual instance. This script can be pasted into the User Data field or imported by using the Import user data link on the UI.

This script was tested with a stock image of Ubuntu 20.04 LTS Focal Fossa. While the script might be appropriate for other Linux stock and custom images, it is possible that adjustments to the script might be required.

The cloud-config script is not appropriate for Windows virtual servers. If your instance does not contain instance storage, do not use this script. It might configure an unintended device.

Here are some details about items that are found in the cloud-config script:



* disk_setup: creates a single default partition spanning the entire disk with a master boot record. The “overwrite: false” causes this operation to be skipped if the device is already partitioned.
* fs_setup: creates an ext4 file system on the first partition of the vdb block device and gives it the label “inststg1”. You can adjust the file system type and label to suit your needs.
For example:

% terraform init

Initializing the backend...

Initializing provider plugins...
- Finding latest version of hashicorp/random...
- Finding latest version of vmware/vcd...
- Installing hashicorp/random v3.4.3...
- Installed hashicorp/random v3.4.3 (signed by HashiCorp)
- Installing vmware/vcd v3.8.2...
- Installed vmware/vcd v3.8.2 (signed by a HashiCorp partner, key ID 8BF53DB49CDB70B0)

Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://www.terraform.io/docs/cli/plugins/signing.html

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
Show more
2. Next, you can run terraform plan to see what will be deployed.

% terraform plan
data.vcd_resource_list.list_of_vdcs: Reading...
data.vcd_resource_list.list_of_vdc_edges: Reading...
data.vcd_resource_list.list_of_catalog_items: Reading...
After the RPM is installed, the man page and the executable (create_ova) are available in the normal paths. Note that a link is made to /usr/bin/create_ova), so there is no need to set the user path. If you decide to perform an uninstall, any links, files, or directories that are tracked by the RPM for this package are removed. The following example contains a list of sample commands and output:

You can upload the ova.gz file into your Cloud Object storage account. Once you upload it, go to the Power Systems Virtual Server user interface and import the OVA image from your Cloud Object Storage account.

ssh (isotopes-vios2)

IBM Virtual I/O Server

login: padmin
padmin's Password:
Last login: Sun May 10 17:41:00 CDT 2020 on /dev/pts/0

$ lsmap -vadapter vhost18
SVSA Physloc Client Partition ID
--------------- -------------------------------------------- ------------------
vhost18 U8233.E8B.100121P-V8-C21 0x0000000f

VTD isotopes13_dsk1
Status Available
LUN 0x8100000000000000
Backing device isotopes13_lv1
Physloc
Mirrored N/A

$ oem_setup_env
 create_ova -o /datafs -d risotopes13_lv1 -t sles -e -f /use rhel for RHEL
Initializing resources ...

Checking for resource group ROOTVG...
Checking for resource group PIPEVIEWER...already installed.
Checking /datafs space requirement...done
Installing the Terraform CLI and the IBM Cloud Provider plug-in 

Install the Terraform CLI and invoke the IBM Cloud Provider plug-in for Terraform to start automating infrastructure deployments and cloud resource management with Terraform.



 Installing the Terraform CLI 

Use these steps to install the Terraform CLI.

The IBM Cloud Provider plug-in for Terraform currently supports the Terraform stable version 1.x.x. Make sure to select a supported Terraform version.



1. Create a terraform folder on your local machine, and navigate to your terraform folder.

mkdir terraform && cd terraform
2. Download the [Terraform version](https://releases.hashicorp.com/terraform) that you want.
3. Extract the Terraform zip file and copy the files to your terraform directory.
4. Set the environment PATH variable to your Terraform files.

export PATH=$PATH:$HOME/terraform
5. Verify that the installation is successful by using a terraform command.

terraform

Example output:

Usage: terraform [-version] [-help] <command> [args]

The available commands for execution are listed below.
The most common, useful commands are shown first, followed by
less common or more advanced commands. If you're just getting
started with Terraform, stick with the common commands. For the
other commands, please read the help and docs before usage.

Common commands:
apply Builds or changes infrastructure
console Interactive console for Terraform interpolations
destroy Destroy Terraform-managed infrastructure
env Workspace management
fmt Rewrites config files to canonical format
get Download and install modules for the configuration
graph Create a visual graph of Terraform resources
import Import existing infrastructure into Terraform
init Initialize a Terraform working directory
login Obtain and save credentials for a remote host
logout Remove locally-stored credentials for a remote host
output Read an output from a state file
plan Generate and show an execution plan
providers Prints a tree of the providers used in the configuration
Provisioning 

This page describes the provisioning process when a client orders the TRIRIGA Application Suite Managed Services option.

Important:

Customers must purchase (or own) App Points for TAS prior to (or in conjunction with) ordering the IBM Managed Service. The managed service provides IBM Cloud based hosting, product installation, operation, maintenance and support for TAS.

The provisioning process is invoked when a client has placed an order using TAS-MS part numbers.

There are three (3) part numbers:

D05UTZX- Capacity

D05USZX - Data

D05URZX - VPC (Virtual Processor Core)

Each client is provisioned in an environment that is separate and distinct from other clients. The provisioning is done to meet the specific customer requirements for a specific order. This means there is no pre-provisioning done and client environment provisioning begins when an order is placed.

The provisioning process has several steps, most of them automated, but some that require a manual update(s) to complete. The timeframe to complete a new provisioning will depend on several factors including:



* The size of the order
* The order complexity
* Availability of bare metal servers
* The number of orders in the queue ahead of the order



In general, allow for at least 10 business days for provisioning to be completed.



 Deployment on Shared Cluster 

TAS MS is deployed in a Shared Cluster and is subject to the TAS MS offering software upgrade policy that is set by IBM. IBM will determine and communicate when upgrades will occur, and no deferrals or exceptions will be allowed.

In the Shared Cluster deployment, IBM Red Hat OpenShift on IBM Cloud and IBM Cloud Pak for Data will be shared across multiple Production Instance(s) and Non-Production Instance(s) and Clients.

The provisioning itself can be broken down into a number of steps:



1. Order validation
2. Information gathering
3. Initial provisioning of TAS base environment
4. Provisioning of the individual TAS products the clients has requested
5. Internal IBM verification of the provisioned environments
6.
* [Next Steps](https://cloud.ibm.com/docs/satellite?topic=satellite-odf-tutorialodf-tutorial-next-steps)







 Attaching bare metal hosts to a location 

[Attaching bare metal hosts to a location](https://cloud.ibm.com/docs/satellite?topic=satellite-assign-bare-metalassign-bare-metal)



* [Prerequisites](https://cloud.ibm.com/docs/satellite?topic=satellite-assign-bare-metalassign-bare-metal-prereq)
* [Bare Metal Server requirements](https://cloud.ibm.com/docs/satellite?topic=satellite-assign-bare-metalsetup-bare-metal)
* [Booting up your Bare Metal Server](https://cloud.ibm.com/docs/satellite?topic=satellite-assign-bare-metalboot-bare-metal)
* [Setting up public networking](https://cloud.ibm.com/docs/satellite?topic=satellite-assign-bare-metalpublic-network-bare-metal)
* [Configuring your ignition file](https://cloud.ibm.com/docs/satellite?topic=satellite-assign-bare-metalconfig-ignition)
* [Attaching your bare metal host to the location](https://cloud.ibm.com/docs/satellite?topic=satellite-assign-bare-metalload-ignition-file-bare-metal)
* [Assigning a Bare Metal Server host to your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/satellite?topic=satellite-assign-bare-metalassign-bare-metal-to-cluster)







 Setting up virtualization on a Satellite location 

[Setting up virtualization on a Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-virtualization-locationvirtualization-location)
INDICATEPROGRESS="False"

; Specifies that Setup should install into WOW64. This command line argument is not supported on an IA64 or a 32-bit system.

X86="False"

; Specify a default or named instance. MSSQLSERVER is the default instance for non-Express editions and SQLExpress for Express editions. This parameter is required when installing the SQL Server Database Engine (SQL), or Analysis Services (AS).

INSTANCENAME="MSSQLSERVER"

; Specify the root installation directory for shared components. This directory remains unchanged after shared components are already installed.

INSTALLSHAREDDIR="C:Program FilesMicrosoft SQL Server"

; Specify the root installation directory for the WOW64 shared components. This directory remains unchanged after WOW64 shared components are already installed.

INSTALLSHAREDWOWDIR="C:Program Files (x86)Microsoft SQL Server"

; Specify the Instance ID for the SQL Server features you have specified. SQL Server directory structure, registry structure, and service names will incorporate the instance ID of the SQL Server instance.

INSTANCEID="MSSQLSERVER"

; Account for SQL Server CEIP service: DomainUser or system account.

SQLTELSVCACCT="NT ServiceSQLTELEMETRY"

; Startup type for the SQL Server CEIP service.

SQLTELSVCSTARTUPTYPE="Automatic"

; Specify the installation directory.

INSTANCEDIR="C:Program FilesMicrosoft SQL Server"

; Agent account name

AGTSVCACCOUNT="sqlserversqlsvc"

; Auto-start service after installation.

AGTSVCSTARTUPTYPE="Automatic"

; CM brick TCP communication port

COMMFABRICPORT="0"

; How matrix will use private networks

COMMFABRICNETWORKLEVEL="0"

; How inter brick communication will be protected

COMMFABRICENCRYPTION="0"

; TCP port used by the CM brick

MATRIXCMBRICKCOMMPORT="0"

; Startup type for the SQL Server service.
The IBM Cloud Pak® for Data automated installation makes the following changes to ensure that services can be installed successfully:



* Sets kernel parameters. For more information, see [Kernel parameter settings](https://www.ibm.com/docs/SSQNUZ_4.6.x/cpd/install/prep-cluster-node-kernel.html).
* Enables noroot squash on worker nodes for Network File System (NFS). For more information, see [Storage considerations](https://www.ibm.com/docs/SSQNUZ_4.6.x/cpd/plan/storage_considerations.html).







 Step 7. Launch your instance of IBM Cloud Pak for Data 



1. After you click Install, the Schematics > Workspaces page opens. You can watch the progress of the installation in the log.
2. When the installation completes, click Offering dashboard to access your IBM Cloud Pak for Data deployment.
3. Log in to the web client as admin using the default password (password). Change your password.
4. On the toolbar, click the Services icon and verify that your services are enabled or available.







 Next steps 



* To add users to your IBM Cloud Pak for Data deployment, see [Managing users](https://www.ibm.com/docs/SSQNUZ_4.6.x/cpd/admin/users.html).
* To install more services to a deployed cluster, repeat the steps to install from IBM Cloud Catalog and set the required service value to true in the Deployment values section.
* To install other supported services, such as DataStage, MongoDB, Db2, Db2 Big SQL, Cognos Analytics, Decision Optimization, Db2 Data Gate, Execution Engine for Hadoop, Open Pages or SPSS Modeler, which cannot be automatically installed when you install IBM Cloud Pak for Data on IBM Cloud, see [Services and integrations](https://www.ibm.com/docs/SSQNUZ_4.6.x/svc-nav/head/svc.html).
Here are some details about items that are found in the cloud-config script:



* disk_setup: creates a single default partition spanning the entire disk with a master boot record. The “overwrite: false” causes this operation to be skipped if the device is already partitioned.
* fs_setup: creates an ext4 file system on the first partition of the vdb block device and gives it the label “inststg1”. You can adjust the file system type and label to suit your needs. The “overwrite: false” setting prevents formatting the partition if it is already formatted with a file system.
* runcmd: creates a directory to use as a mount-point off ‘/’ in the hierarchical parent file system.
* mounts: performs the mount of the file system device onto /inststg1. You can rename the directory path here and under runcmd.
* mount_default_fields: creates a permanent mount directive in the /etc/fstab file. If you issue a reboot command, the virtual server comes back up with the instance storage file system still mounted.



The CLI and API also supports the User Data field.

This cloud-config script example automatically configures an instance storage /dev/vdb block device. If you only reboot your virtual server, this configuration continues to work since the configuration and data persists. However, if you start a virtual server that was previously stopped, then the virtual server has a fresh set of instance storage disks when it boots up. This situation would require the cloud-init steps to be manually run again. By default, the cloud-config script is only run on first boot. You can also edit the cloud-init section of the cloud.config file so that the cloud-init steps are automatically run on each boot. For the steps, see the [Edit the cloud_cloud_init_modules section of the cloud.config file to run on each boot](https://cloud.ibm.com/docs/vpc?topic=vpc-user-dataedit-cloud-init-run-cloud-config-each-boot) section.
To remain unchanged... Proceed to the next step. 



6. Determine whether to apply one or more SSH keys to the device.
7. Select the applicable checkboxes for the options that you want to apply to the device during or after the OS reload.

Options vary based on device. Not all options are available for every device.

Postinstallation script Adds an existing or new postinstallation script.

SSH key Adds an SSH key to the device upon the reload action.

Reset IPMI password This option is available only for physical devices.

Apply system board BIOS upgrades This option is available only for physical devices.

Apply firmware updates for all hard disks This option is available only for physical devices.

Add to spare pool after OS reload This option is available only on physical devices and requires internal approval before it's available on an account.

Erase all hard disks This option is available only on physical devices and requires special user permissions set by the account administrator.

OS reload with disk preservation This option configures your current primary disk as a secondary disk (retaining all data), and creates a new primary disk. The OS is installed on the new primary disk. Retains all data on the current primary disk during the OS reload process. Retains all data on the current primary disk during the OS reload process. Disk preservation converts the primary drive to a portable storage device. This option is available only on virtual devices and incurs charges based on the billing patterns (hourly or monthly) of the device. Charges might be canceled by canceling the portable storage device anytime after it was created.
8. Click Reload with configuration to proceed to review. Click Cancel to cancel the changes to the device and exit the screen.
9. Verify that all details in the New configuration section are correct.
10. Click Confirm OS reload to confirm and initiate the OS reload. Click Cancel to cancel the action.







 What's next? 

After you initiate the OS reload process, the device is taken offline and the OS reload process begins. The time period in which an OS reload takes place varies based on the current and new configuration of the device.