vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* Shifts all existing ibmcloud oc alb commands into the [ibmcloud oc ingress alb](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clialb-commands) subcategory.
* Changes the names of the following options in the relevant ibmcloud oc 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 oc alb cert set of commands.
* Deprecates the ibmcloud oc alb configure command.
* Removes the deprecated ibmcloud oc alb rollback command,







 Version 1.0.143 

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



* Adds the [ibmcloud oc quota ls](https://cloud.ibm.com/docs/openshift?topic=openshift-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 oc 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 oc 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 oc worker replace command.
* Standardizes the help text for options that have a list of supported values.
* Updates the help text in various languages.
* API for image import - [Create a new image from available images you have stored in IBM COS](https://cloud.ibm.com/apidocs/power-cloudpcloud-v1-cloudinstances-cosimages-post).- CLI enhancements include changes to the existing [ibmcloud pi image-import](https://cloud.ibm.com/docs/power-iaas-cli-plugin?topic=power-iaas-cli-plugin-power-iaas-cli-referenceibmcloud-pi-image-import) command.
* New [ibmcloud pi jobs](https://cloud.ibm.com/docs/power-iaas-cli-plugin?topic=power-iaas-cli-plugin-power-iaas-cli-referenceibmcloud-pi-jobs) command.



The new Power Systems Virtual Server VM capture, image export, and image import features are restricted to one operation at a time per Power Systems Virtual Server workspace. If one of these operations is submitted successfully, then another new operation (VM Capture, Image Export, and Image Import) cannot be submitted until the previous operation is complete.

You can use the IBM® Power Systems™ Virtual Server legacy REST APIs for VM Capture, Image Export, and Image Import until 1 October 2022. You must plan to transition to the new IBM® Power Systems™ Virtual Server REST APIs or CLI commands within the sunset period.



 Using the Power Systems Virtual Server CLI to import a boot image 

Complete the following steps to import a boot image by using the Power Systems Virtual Server CLI. For more information, see the [IBM Power Systems Virtual Servers CLI Reference](https://cloud.ibm.com/docs/power-iaas-cli-plugin?topic=power-iaas-cli-plugin-power-iaas-cli-referenceibmcloud-pi-image-import).



1.
This creates a git directory (including the snapshot of the application's Git repository that is used for the build), and a data directory, which includes a file build.json (that contains the build status) and the build.log.





 Saving the state of your Secure Build Server instance 

As an optional step (which you can skip), you can download a state image from your Secure Build Server instance. To build the image in another, new Secure Build Server instance (for example, after the original instance is deleted or corrupted), you need the state image to recover the signing key and additional internal states of the Secure Build Server instance. See [here](https://github.com/ibm-hyper-protect/secure-build-cli) for information about how you can restore the state image and how you can save a state image to Cloud Object Storage. In this tutorial, you download the state image only, so it is available in the current working directory for possible later use.





 9. Retrieve the state image. 

To download the state image, run the following command:

./build.py get-state-image --env sbs-config.json

This command creates an encrypted file in your current directory and prints the file name in the output, for example:

INFO:__main__:state:name: us.icr.io.secureimages.secure-bitcoin-wallet.s390x-v1-ad52e76.2021-02-10_15-37-37.178350







 Step 4: Step 4: Deploy your application by using Hyper Protect Virtual Servers BYOI and run the application in a secure environment 

Now it's time to deploy and run your newly built application. To do so, you download the encrypted registration file that was created during the build and use the Hyper Protect Virtual Servers BYOI feature to provision a Hyper Protect Virtual Servers instance for your application.



 1. Retrieve the encrypted registration file 

First, download the encrypted registration file for your application container image:
For more information, see [Securing IBM Cloud accounts](https://www.ibm.com/cloud/blog/announcements/securing-ibm-cloud-accounts).





 05 October 2021 

Suspending and deprecating private products
: As a private catalog owner, you can now suspend or deprecate software that's in your private catalogs. When you suspend a version of software, it's immediately removed from your private catalog. When you deprecate software, it remains available to users with access to the private catalog for 90 days. After 90 days, it's permanently removed.

For more information, see [Deprecating a private product](https://cloud.ibm.com/docs/account?topic=account-deprecate-product) and [Suspending a version of a private product](https://cloud.ibm.com/docs/account?topic=account-suspend-product).

Suspending and deprecating third-party software
: As a third-party provider, you can now suspend and deprecate published software from the IBM Cloud catalog to meet the needs of your product's lifecycle. When you suspend a product or version, it is immediately removed from the catalog. When you deprecate a product or version, it remains available for use in the catalog for 90 days. After 90 days, it's permanently removed.

For more information, see [Deprecating software from the IBM Cloud catalog](https://cloud.ibm.com/docs/sell?topic=sell-deprecate-product) and [Suspending your product from the IBM Cloud catalog](https://cloud.ibm.com/docs/sell?topic=sell-suspend-product).

Filtering the IBM Cloud catalog by specific providers
: The latest enhancements to IBM Cloud catalog include support for filtering products by provider name. If you're looking for a specific provider's products or curious about how many products that a provider offers, you can use the Provider filter to narrow down your search. To explore the filter updates, see the [catalog](https://cloud.ibm.com/catalog).







 September 2021 



 27 September 2021 

Securing your resources with context-based restrictions
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. 
 Custom Docker image Builds by using your custom docker image with fine-grained control over the versions of node, Java™, or other tools. Docker image name: The name of the image that this job builds and uploads to the IBM Cloud Container Registry.<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>Build archive directory: Specifies the directory that contains the job's output to be archived 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. 
 Gradle Builds by using Gradle. 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.
If a tag is specified for the image, then the tagged image is used for the job run.





 Considerations for HTTP handling 

When you are working with jobs (or apps), it is helpful to be aware of basic HTTP handling in Code Engine. See [Considerations for HTTP handling](https://cloud.ibm.com/docs/codeengine?topic=codeengine-application-workloadsconsiderationshttphandlingapp)





 Options for creating and running a job 

Learn about the options that you can specify when you create or run your job. Note that options can vary between the console and the CLI.



 Memory and CPU for jobs 

When you deploy your job, you can specify the amount of memory, and CPU that your job can consume. These amounts can vary, depending on if your job is compute-intensive, memory-intensive, or balanced.

By default, your job is assigned 4 G of memory and 1 vCPU. For more information about selecting memory and CPU, see [Supported memory and CPU combinations](https://cloud.ibm.com/docs/codeengine?topic=codeengine-mem-cpu-combo).





 Creating and running a job with commands and arguments 

You can define commands and arguments for your job to use at run time when you create or run your job.

You can add commands and arguments to your job by using the CLI or the console.

To add commands and arguments through the console, use the Command and Arguments fields.

To add commands and arguments by using the CLI, add the --cmd and --args options to your [job create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-job-create) or your [jobrun submit](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-jobrun-submit) command.

For more information about defining commands and arguments, see [Defining commands and arguments for your Code Engine workloads](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cmd-args).





 Creating and running a job with environment variables
This value is ignored if the --no-wait option is specified. The default value is 600.





 Example 

ibmcloud ce application update --name myapp --image icr.io/codeengine/hello





 Example output 

Updating application 'myapp' to latest revision.
[...]
Run 'ibmcloud ce application get -n myapp' to check the application status.
OK

https://myapp.4svg40kna19.us-south.codeengine.appdomain.cloud









 Build commands 

A build, or image build, is a mechanism that you can use to create a container image from your source code. Code Engine supports building from a Dockerfile and Cloud Native Buildpacks. Use build commands to create, display details, update, and delete build configurations. After you create a build configuration, one or more [buildrun commands](https://cloud.ibm.com/docs/cli?topic=cli-clicli-buildrun) can be submitted based on the build configuration.

You must be within the context of a [project](https://cloud.ibm.com/docs/cli?topic=cli-clicli-project) before you use build commands.

For more information about working with builds, see [Building a container image](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-image).

You can use either build or bd in your build commands. To see CLI help for the build commands, run ibmcloud ce build -h.



 ibmcloud ce build create 

Create a build.
Custom images that are published to a private catalog must be in available status and their statuses are maintained in the private catalog. If you try to change or schedule a change to their status in IBM Cloud VPC, the attempt fails. If a custom image is removed from a private catalog, that image retains its original private catalog status until the status is changed in IBM Cloud VPC.



Table 2. Catalog image lifecycle status and the corresponding VPC status

 Private catalog image status Corresponding VPC image status 

 published/verified available 
 deprecated deprecated 
 archived obsolete 







 Bare metal server custom images 

Bare metal servers have some limitations that you need to be aware of.



* Encrypted images aren't supported



To create a custom image for bare metal servers, the custom image must support the following information:



* UEFI boot



* UEFI boot requires a dedicated EFI partition that contains EFI firstware. Traditional BIOS boot is not supported.



* Pensando iconic network device drivers
* Intel chip set device drivers



* These device drivers are usually part of the default kernel build options. Windows requires extra device drivers, but you can install these drivers later.





For more information, see [Custom Linux kernel build options for bare metal servers](https://cloud.ibm.com/docs/vpc?topic=vpc-configuration-requirements-for-custom-linux-kernelscustom-linux-kernel-linuxone-options).

For more information about bare metal server images, see [Bare metal server images](https://cloud.ibm.com/docs/vpc?topic=vpc-bare-metal-image).





 z/OS Wazi aaS custom images 

You can use IBM Wazi Image Builder to create your own custom z/OS-based IBM Wazi as a Service (Wazi aaS) image and import the custom image into IBM Cloud® Virtual Private Cloud.

IBM Wazi Image Builder is a separately orderable product from [IBM Passport Advantage](https://www.ibm.com/software/passportadvantage/). Extra requirements are needed to use Wazi Image Builder.
Moving data from your on-premise environment to Power Systems Virtual Servers 

Depending on your network bandwidth and data size constraints, the process of moving the data volume group is as simple as creating an Open Virtualization Appliance (OVA) file or an mksysb image (root volume group), and creating a set of savevg images for volume group data. By using an OVA file or an mksysb image, you can build or provision a VM and then migrate the data volume groups of the virtual machine (VM) by using the restvg command.

You can use the following methods to back up your on-premise data and move the data to IBM Power Systems Virtual Server.



 Migrating volume group data by using the savevg command 

A volume group is a collection of physical volumes of various sizes and types. When a physical volume is assigned to a volume group, the physical blocks of storage media are organized into physical partitions. You can specify the size of the physical partition when you create the volume group. You can use built-in AIX savevg and restvg commands to back up and restore non-root volume groups. The savevg and restvg commands simplify the creation of new volume groups and file systems on the new VM.

The savevg command finds and backs up all files that belong to a specified volume group. The volume group must be varied-on, and the file systems must be mounted. The savevg command uses the data file that the mkvgdata command creates.

Use the following command to find and back up all files in a specific volume group.

 savevg –f <destination path> -i <non root vg files to be backed up>

For example:

 savevg –f /home/admin01/datavg_bkup –i datavg





 Backing up multiple volume groups by using the mkvgdata and restvg commands 

Small systems might require only one data volume group to contain all the physical volumes. For a non-root user you might want to create separate volume groups, for security reasons, because each volume group can have its own security permissions. If a volume group stops working, other volume groups remain active.
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. 
 Container registry Builds docker images and uploads them to the IBM Cloud Container Registry. 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>Container Registry namespace: The namespace where you want to store your built image.<br><br>Docker image name: The name of the image that this job builds and uploads to the IBM Cloud Container Registry.<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. 
 Custom Docker image Builds by using your custom docker image with fine-grained control over the versions of node, Java™, or other tools.
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. 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. 
 Gradle (Artifactory, Nexus, or SonarQube) Builds and deploys by using Gradle with a Nexus or Artifactory repository. Gradle also integrates with SonarQube. Pipeline image version: Runs in a container by using a built-in docker image, which provides various built-in commands.
Typically, this builder type is useful only when the stage's input is from an SCM repository. 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. 
 Ant Uses Apache Ant files to manage the build job. 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>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. 
 Container registry Builds docker images and uploads them to the IBM Cloud Container Registry. Pipeline image version: Runs in a container by using a built-in docker image that provides various built-in commands.
3. Customize the backup virtual server instance to make sure that you meet the requirements for deploying in IBM Cloud VPC.
4. Create an image template of your modified virtual server instance.
5. Export the image template to IBM Cloud Object Storage.
6. Import the custom image to the IBM Cloud VPC infrastructure.
7. Use the custom image to create a virtual server instance in IBM Cloud VPC.



For more information about using shell scripts to migrate an instance, see [Automate the migration of a workload based on Virtual Servers from Classic Infrastructure to VPC](https://www.ibm.com/cloud/blog/automate-the-migration-of-a-workload-based-on-virtual-servers) and [vpc-tutorials](https://github.com/IBM-Cloud/vpc-tutorials/tree/master/vpc-migrate-from-classic).



 Step 1 - Identify the virtual server instance to migrate and create an image template 

You can create an image template from a virtual server in the classic infrastructure that you want to migrate to the IBM Cloud VPC infrastructure. The image template captures an image of the existing virtual server. Make sure that you understand the following information about image templates.



* Only image templates with a single primary boot volume (or disk) and associated file can be imported to IBM Cloud VPC infrastructure.
* The image template includes the operating system on the primary boot disk and the items that you installed, such as PHP or Python. The image template can be between 10 GB and 250 GB of data. Images under 10 GB are rounded up to 10 GB.
* When you use the imported custom image in IBM Cloud VPC to create a virtual server, you can select a new profile, assign an SSH key, specify user data, and configure network interfaces.



Secondary disks and their associated files for an image template are not supported when an image template is imported as a custom image to IBM Cloud VPC.

Complete the following steps to create an image template for the virtual server instance that you want to migrate.



1.