vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* Changes the names of the following options in the relevant ibmcloud ks ingress alb commands: --alb-id to --alb, --secret-name to --name, and --user-ip to --ip.



Deprecated commands: The following commands are deprecated in favor of the new commands.



* Deprecates the ibmcloud ks alb cert set of commands.
* Deprecates the ibmcloud ks alb configure command.
* Removes the deprecated ibmcloud ks alb rollback command,







 Version 1.0.143 

Version 1.0.143 of the CLI was released on 6 August 2020.



* Adds the [ibmcloud ks quota ls](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_quota_ls) command to list all quota and limits for cluster-related resources in your IBM Cloud account.
* Deprecates the --json option. To print a command output in JSON format, use the --output json option instead.
* Deprecates the -s option. To not show the message of the day or update reminders in command output, use the -q option instead.
* Updates ibmcloud ks cluster ls command so that if you include the --ouput json option but don't include the --provider option, only classic clusters are returned.
* Corrects the example master update command that is displayed in the output of the ibmcloud ks cluster get command when a master update is available.
* Adds information about the effects of worker node replacement in the warning message for the ibmcloud ks worker replace command.
* Standardizes the help text for options that have a list of supported values.
* Updates the help text in various languages.







 Version 1.0.118 

Version 1.0.118 of the CLI was released on 7 July 2020.



* Deprecates the ibmcloud ks cluster user-subnet add, ibmcloud ks cluster user-subnet rm, and ibmcloud ks va commands.
Or, you can directly go to the [Manage cases page](https://cloud.ibm.com/unifiedsupport/cases) and click Create new case.
2. On the Create a case page displayed, select the offering Hyper Protect Crypto Services, and then specify the following values:



Table 2. Describes the fields that are required to activate new crypto units

 Field name Action 

 Subject Enter Activate new crypto units. 
 Description Enter your [service instance ID](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-retrieve-instance-ID), the region that your service instance resides in, the number of new crypto units, and the case number of the support ticket that is previously raised in [step 1](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-add-remove-crypto-unitsstep1-support-ticket-change-number). 
 Selected resources Select your Hyper Protect Crypto Services service instance. 



3. Check the Email me updates about this issue box, and click Continue to review > Create case.

After the activation is completed successfully, you will get an email notification. You can also check the state in the Support Center by clicking the Help icon ![Help icon](https://cloud.ibm.com/docs-content/v1/content/217f108cc44e2ce15fb692d4b57b4c628464e908/icons/help.svg) > Support center from the IBM Cloud console menu bar.









 Removing crypto units from an existing service instance 

To remove crypto units from an existing service instance, you need to [raise a support ticket](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-add-remove-crypto-unitsstep1-support-ticket-change-number).

On the Create a case page, enter Remove crypto units as the subject, and include the number of crypto units that you want to remove in the case description.

You need to keep at least two crypto units in a service instance for high availability.
For more information about End of Service for Text to Speech, which is part of the Watson API Kit, see [Software support discontinuance: IBM Watson API Kit for IBM Cloud Pak for Data 1.2.x](https://www.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897<=tternum=ENUS922-038).





 27 April 2022 (Version 4.0.8) 

Version 4.0.8 is now available
: Text to Speech for IBM Cloud Pak for Data version 4.0.8 is now available. This version supports IBM Cloud Pak for Data version 4.x and Red Hat OpenShift versions 4.6 and 4.8. For more information about installing and managing the service, see [Installing Watson Text to Speech](https://www.ibm.com/docs/en/cloud-paks/cp-data/4.0?topic=speech-installing-watson-text).

New environment variables used in IBM Cloud Pak for Data documentation
: Most commands in the Text to Speech for IBM Cloud Pak for Data documentation have been updated to use a common set of environment variables. The documentation provides a script to automatically export the environment variables before you run installation, upgrade, and administration commands. After you source the script, you can copy most commands from the documentation and run them without making any changes.

The environment variables that the script defines include the following:



* ${PROJECT_CPD_INSTANCE} identifies the project where you plan to install IBM Cloud Pak for Data and the Speech services.
* ${PROJECT_CPD_OPS} identifies the project for the IBM Cloud Pak for Data platform operator.
* ${PROJECT_CPFS_OPS} identifies the project for the IBM Cloud Pak for Data foundational services.



For more information about using the environment variables, see [Best practice: Setting up install variables](https://www.ibm.com/docs/en/cloud-paks/cp-data/4.0?topic=installing-best-practice-setting-up-install-variables).

The ttsVoiceMarginalCPU property is no longer documented
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. 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 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. 
 Shell script Runs a UNIX shell script, such as Bash. 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.
chaincode-execution-0a8fb504-78e2-4d50-a614-e95fb7e7c8f4 1/1 Running 0 14s chaincode-id=javacc-1.1,peer-id=org1peer1
NAME READY STATUS RESTARTS AGE LABELS
chaincode-execution-f3cc736f-94ef-454d-8da3-362a50c653d9 1/1 Running 0 4m chaincode-id=nodecc-1.1,peer-id=org1peer1

Your smart contract name and version is visible next to the chaincode-id.

To delete a single pod, issue this command, substituting the <POD_NAME> for the name of your pod, for example the smart contract pod chaincode-execution-0a8fb504-78e2-4d50-a614-e95fb7e7c8f4, as well as your <NAMESPACE>:

kubectl delete pod <POD_NAME> -n <NAMESPACE>

You can also use kubectl commands to delete all of the nodes in your cluster by issuing commands to delete each type of node. First, set the namespace where the nodes you want to delete are located:

kubectl config set-context --current --namespace=<NAMESPACE>

Then run the following commands to delete all of your blockchain nodes:

kubectl delete ibpca --all
kubectl delete ibppeer --all
kubectl delete ibporderer --all

You may also choose to only delete all of a single type of node within a namespace, for example, by only issuing kubectl delete ibppeer --all.

Note that if you delete your entire namespace, your smart contract pods will also be deleted. Your smart contract pods will also be deleted, along with your nodes, if you delete your service instance using the Kubernetes dashboard in IBM Cloud.
Enter the software version in the format of major version, minor version, and revision, for example, 1.0.0.
6. Click Add product.







 Step 3: Review the version details 

From the Configure version tab, you can review your version details. After you review your version details, click Next.





 Step 4: Configure the deployment values 

After you review the version details, you're ready to configure the deployment values.



1. If you need to specify the Terraform runtime version that you want Schematics to use, click the Override the default Terraform runtime version checkbox and enter a version.
2. From the Configure the deployment details section, click Add deployment values.
3. Select the Parameter checkbox to select all options, and click Add.
4. To customize which parameters are required for users to specify during the installation and which ones are hidden from users, select a parameter and click Edit. Click the checkboxes to configure the values and click Save.







 Step 5: Edit output value descriptions 

You can improve the descriptions for your Terraform template's output values to help users better understand the purpose of the parameters. The description of any output value that you include in your template can be updated.

To add output values, you need to include them in a new imported version of your Terraform template.

Complete the following steps to edit the product's output value descriptions:



1. Click Configure version > Next.
2. From the Output value descriptions section, provide a new description for the parameter that you want to update.
3. Click Next.







 Step 6: Define IAM access 

After you configure your deployment values, you can add the service access and platform access roles that are required to install your product.

Use the following steps to define your product's access:



1. Click Configure version > Next > Next.
2. Click Add.
3. Select the service and the required service and platform access.



* The service access role allows access for using the service and performing service API calls.
ssh_key_name The name of the public SSH key to use when creating the virtual server instance. True False 
 subnet_id The ID of the subnet within the VPC that the virtual server instance uses. True False 
 vsi_instance_name The name of the virtual server instance. True False 
 vsi_profile The profile of compute CPU and memory resources to use when creating the virtual server instance. False False 
 vsi_security_group The name of the security group that is created. True False 







 Step 5: Edit output value descriptions 

You can improve the descriptions for your Terraform template's output values to help users better understand the purpose of the parameters. The description of any output value that you include in your template can be updated.

To add output values, you need to include them in a new imported version of your Terraform template.

Complete the following steps to edit the product's output value descriptions:



1. Click Configure version > Next.
2. From the Output value descriptions section, provide a new description for the parameter that you want to update.
3. Click Next.







 Step 6: Define IAM access 

After you configure your deployment values, you can add the service access and platform access roles that are required to install your product.

Use the following steps to define your product's access:



1. Click Configure version > Next > Next.
2. Click Add.
3. Select the service and the required service and platform access.



* The service access role allows access for using the service and performing service API calls.
* The platform access role enables actions to be performed on platform resources, such as creating an instance, connecting instances to apps, and assigning user access.



4. Click Save.



The following table lists the string comparison operators that you can use to build access policies with /v2/policies syntax. For more information about each version, see [Comparing /v1/policies and /v2/policies syntax](https://cloud.ibm.com/docs/account?topic=account-known-issuescompare-syntax).



Table 3.
[Menu icon](https://cloud.ibm.com/docs-content/v1/content/78bb71851d95d7580503eb9ba10cf3ae31490ade/apiconnect/images/icon_cloud_menu.png) and select API Management.
3. In the navigation list, expand API Connect and click Services.
4. On the Services page, display the provider organizations for your company's API Connect Reserved service by expanding the row that displays the service name. Your administrator can tell you which provider organization you belong to.

Provider organizations belong to Reserved instances, so you need to expand your Reserved instance to see the list of associated provider organizations. Each provider organization is labelled as "Provider Organization" in the "Plan" column. If your company has multiple Reserved instances and you don't know which one to use, just expand each one until you see your provider organization.
5. Click the name of a provider organization to start the API Connect API Manager.

Your administrator can tell you which provider organization you belong to if it's not clear to you. When you click the provider organization to start API Manager, you are automatically logged in.

If you belong to multiple provider organizations and want to log in with a different one, log out of API Manager. Then, return to the API Connect Services page and log in with another provider organization.

Whenever you want to work in API Manager, return to the Services page and select your provider organization.



When you see the API Connect Home page, you're ready to proceed.





 Step 2. Create an API 

See how easy it is to create an API by importing a YAML definition.

Complete the tutorial [Importing an API](https://www.ibm.com/support/knowledgecenter/SSMNED_v10/com.ibm.apic.apionprem.doc/tutorial_apionprem_import_api.html) in the extended API Connect V10 Reserved documentation.





 Next steps
* Showing configuration information
* Navigating through the configuration hierarchy



When you log on to the system, the system is in operational mode. You must switch to configuration mode for the commands.

You can tell which mode that you are in based on the prompt. You are in operational mode if the prompt is #, and configuration mode if the prompt is $.

Follow these steps to configure the private VLAN by using the CLI. Remember the values needed to configure the VLAN are:



* VLAN name of the VLAN to be routed through Brocade 5400 vRouter device (2254)
* Gateway and mask (CIDR format) of the VLAN to be routed (10.52.69.201/29)
* Private bond name of the Brocade 5400 vRouter Device (bond0)





1. SSH into your Brocade 5400 vRouter (public or private IP address) by using vyatta as the Username. Supply the password when prompted.

You should create a new user within Brocade 5400 vRouter and disable the default initial user vyatta.
2. Configure the vif:



* Type configure at the command prompt to enter configuration mode.
* Type set interfaces bonding bond0 vif 2254 address 10.52.69.201/29 at the command prompt to set the vif.
* Type commit at the command prompt to commit the settings.
* Type save to save the settings.
* Type exit to switch back to operation mode.



3. Type show interfaces to check the settings that you committed.
4. Route any remaining VLANs through the Brocade 5400 vRouter device.
In your sessions, you'll also now have access to more command-line tools with the addition of the Operator SDK for Kubernetes, the Mercurial source content management tool, and the Bazaar version control system, as well as updates to existing tools.

For a complete list of changes, see the [Cloud Shell release notes](https://cloud.ibm.com/docs/cloud-shell?topic=cloud-shell-release-notes-image).





 10 August 2020 

Customizing scoped dashboards
: Create and manage customized dashboards that can be used to offer an organized and relevant workspace. You can share the dashboards with different users in your account or as a way to group resources for specific projects or teams. When you create a new dashboard, you can start from scratch with a blank template or choose one of the other available templates. For more information, see [Working with scoped dashboards](https://cloud.ibm.com/docs/account?topic=account-custom-dashboard).





 04 August 2020 

Audit logs for private catalogs
: View recorded changes to your private catalogs with the new audit logs feature. Audit logs are recorded when you create, delete, or update your private catalog. Visit your Audit logs page in the IBM Cloud console by going to Manage > Catalogs, and selecting Audit logs. For more information, see [Viewing changes to your private catalogs](https://cloud.ibm.com/docs/account?topic=account-catalog-audit-logs).







 July 2020 



 07 July 2020 

Notification distribution list
: You can now create a list of up to 10 email addresses that receive account-wide notifications in the IBM Cloud console by going to Account > Notification distribution list. Users that are added to the distribution list are notified about any event that's affecting the account. For more information, see [Adding users to a distribution list](https://cloud.ibm.com/docs/account?topic=account-email-prefsadding-users-to-a-distribution-list)

CLI support for catalog filtering in IBM Cloud enterprises
: You can now use the following commands to set and manage filters in accounts within an enterprise hierarchy:
With the Security and Compliance Center, you can embed checkpoints into your everyday workflows hat not only help to monitor for security and compliance but enforce configuration standardization across our accounts. By ensuring you have automation in place that monitors for risk, you can identify security vulnerabilities quickly and work to mitigate the impact that they have to your business.

For more information, see [Getting started with Security and Compliance Center](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-getting-started).





 20 August 2020 

IBM Cloud CLI Version 1.2.0 is now available
: The 1.2.0 release of the IBM Cloud CLI includes:



* New commands under sl loadbal namespace to support the IBM Cloud® Load Balancer service.
* Output CSV support for billing commands.
* Validation of service instance ID input in policy commands under iam namespace.
* Additional deployment capabilities with the ibmcloud dev command, including manual deployment to Knative and deployment to Red Hat® OpenShift® on IBM Cloud® containers.
* Deprecation of the cfee namespace.



For more information about the IBM Cloud CLI, see [Getting started with the IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-getting-started).





 12 August 2020 

Increased usage quota and other updates to IBM Cloud Shell
: With this update to IBM Cloud Shell, the weekly usage quota was increased from 30 hours a week to 50 hours a week so that you can use Cloud Shell even more. Also, Cloud Shell was changed to have separate workspaces for each user and account, whereas previously each user's workspace was shared across all of their accounts. In your sessions, you'll also now have access to more command-line tools with the addition of the Operator SDK for Kubernetes, the Mercurial source content management tool, and the Bazaar version control system, as well as updates to existing tools.

For a complete list of changes, see the [Cloud Shell release notes](https://cloud.ibm.com/docs/cloud-shell?topic=cloud-shell-release-notes-image).





 10 August 2020
Reverting to an earlier version 

If your ALB pods were recently updated, but a custom configuration for your ALBs is affected by the latest image version build, you can use the [ibmcloud ks ingress alb update](https://cloud.ibm.com/docs/containers?topic=containers-ingress-alb-manageupdate-alb) command with the --version option to roll back ALB pods to an earlier, supported version. The image version that you change your ALB to must be a supported image version that is listed in the output of ibmcloud ks ingress alb versions.

Note that if you revert to an earlier version, you must [disable automatic ALB updates](https://cloud.ibm.com/docs/containers?topic=containers-ingress-alb-manageautoupdate) and then keep them disabled for as long as you want to run the earlier version. Automatic updates always apply the latest version and overwrite any manual updates you apply. If you want to use an earlier version, you cannot enable automatic updates.







 Scaling ALBs 

Each ALB can handle around 20,000 connections per second. If you need to process additional connections, you can create more ALBs in a zone or increase the number of ALB pod replicas.



 Creating more ALBs in a zone 

Each ALB in a zone is deployed as two pods on different worker nodes. To scale up your ALB processing capabilities and handle more connections, you can create additional ALBs in a zone. The IP address of the new ALB is automatically added to your Ingress subdomain.

When you create a multizone cluster, a default public ALB is created in each zone where you have worker nodes. If you later remove one of these original three zones and add workers in a different zone, a default public ALB is not created in that new zone. You can manually create an ALB to process connections in that new zone.



1. In each zone where you have worker nodes, create an ALB.

The following command applies to classic clusters.
For example: https://n2734d0-soorg10524.ibpv2-cluster.us-south.containers.appdomain.cloud:7054. The namespace is the first part of the URL beginning with the letter n and followed by a random string of six alphanumeric characters. So in the example, the value of the namespace is n2734d0.

Find the smart contract pod

Next, use kubectl commands to get a list of all of the chaincode pods running in your cluster:

kubectl get po -n <NAMESPACE> | grep chaincode-execution | cut -d" " -f1 | xargs -I {} kubectl get po {} -n <NAMESPACE> --show-labels

Replacing <NAMESPACE> with the name of your cluster namespace.

You should see results similar to:

NAME READY STATUS RESTARTS AGE LABELS
chaincode-execution-0a8fb504-78e2-4d50-a614-e95fb7e7c8f4 1/1 Running 0 14s chaincode-id=myjavacc-1.1,peer-id=org1peer1
NAME READY STATUS RESTARTS AGE LABELS
chaincode-execution-f3cc736f-94ef-454d-8da3-362a50c653d9 1/1 Running 0 4m chaincode-id=mynodecc-1.1,peer-id=org1peer1

Find your smart contract pod by examining the associated chaincode-id that contains the smart contract name and version.

Then in IBM Log Analysis, to view the logs for the myjavacc version 1.1 smart contract, you can enter the pod name in the search bar as follows:

pod:<SMART_CONTACT_POD>

For example:

pod:chaincode-execution-0a8fb504-78e2-4d50-a614-e95fb7e7c8f4









 Summary 

Congratulations. In this tutorial you learned how easy it is to use IBM Log Analysis to view the logs for your blockchain nodes and smart contracts.