vania-janet/multiturn-rag-retrieval-data huggingface dataset:
If you want to restore a deleted image, you can list the contents of the trash by running the [ibmcloud cr trash-list](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_trash_list) command and restore a selected image by running the [ibmcloud cr image-restore](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_restore) command.

To reduce the number of images in each repository within your namespace by using the CLI, complete the following steps:



1. Log in to IBM Cloud by running the ibmcloud login command.
2. Choose the registry in which you want to clean up your images by running the following command and selecting the appropriate region:

ibmcloud cr region-set
3. To retain the most recent images and delete the others, run one the following commands:



* If you want to clean up both tagged and untagged images, run the following command:

ibmcloud cr retention-run --images <image_count> <namespace>

Where <image_count> is the number of images that you want to retain for each repository within your namespace, <namespace>.
* If you want to clean up tagged images only and retain all untagged images, run the following command:

ibmcloud cr retention-run --retain-untagged --images <image_count> <namespace>

Where <image_count> is the number of images that you want to retain for each repository within your namespace, <namespace>.



If an image that you're expecting to see doesn't show in the list that is produced, see [Why doesn't the retention command show all the images?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-image-list-retention) for assistance.
4. Verify that the images were deleted by running the following command, and check that the images do not show in the list.

ibmcloud cr image-list
Why do I get an error when I'm restoring an image? 

You want to restore an image from the IBM Cloud® Container Registry trash, but you get a 409 error: The tagged image already exists. You can restore this image by using the digest.

  What’s happening 

You receive the following error message when you run the [ibmcloud cr image-restore](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_restore) command: The tagged image already exists. You can restore this image by using the digest.

  Why it’s happening 

An image with the same name exists in your live repository. You can't overwrite a live image with an image that is in the trash.

  How to fix it 

Remove the

tagfrom the existing image in your live repository by running the [ibmcloud cr image-untag](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_untag) command. You can then restore the required image from the trash by running the [ibmcloud cr image-restore](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_restore) command with the option <repo>@<digest>, which restores the digest and its tags to the live repository. For more information, see [Restoring images by digest](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_images_registry_images_restore_digest).
Working with versioned base images 

When you develop applications for IBM Cloud, you can use versioned base images to run pipeline jobs to make sure that you are using the current tools, libraries, and runtimes. Versioned base images help you to make sure that the bits that make up the application, and the environment that you deploy the application to, are consistent. You can control when the tools, libraries, or runtimes for your application change and update them when it makes sense during the development cycle.

The existing CLI plug-in repository infrastructure for downloading and updating the CLI binary files and plug-ins is deprecated. As of 1 October, 2021, you must upgrade pipelines that use the provided pipeline base image for version 2.14 or earlier (Ubuntu) or version 3.2 or earlier (UBI) to use one of the current versioned base images. The current image for Ubuntu is version 2.15. The current image for UBI is version 3.3.

If you do not upgrade the base image that is used by your pipelines, you might receive the following error:

Unable to fetch plug-ins from repository 'IBM Cloud':
invalid character '<' looking for beginning of value

On 16 March 2020, the IBM Cloud® Kubernetes Service released a new version 1.0 of the IBM Cloud CLI plug-in. Because this version is not 100% compatible with earlier versions, you must upgrade your scripts after you start to use this version. For more information about this new version of the IBM Cloud CLI plug-in, see [Big changes are coming to the IBM Cloud Kubernetes Service CLI plugin to change your experience for the better](https://www.ibm.com/cloud/blog/announcements/boost-your-productivity-with-a-new-cli-experience-for-the-ibm-cloud-kubernetes-service). To maintain compatibility with the current IBM Cloud Kubernetes Service runtimes after the new version 1.0 is available, Continuous Delivery will update the current base image for the Delivery Pipeline to include this version.
To find the names of your images in the trash, run the ibmcloud cr trash-list command.

You can identify images by using either the tag or the digest. The image to restore can be referenced by digest <dns>/<namespace>/<repo>@<digest>, which restores the digest and all its tags in the same repository, or by tag <dns>/<namespace>/<repo>:<tag>. Where <dns> is the domain name, <namespace> is the namespace, <repo> is the repository, <digest> is the digest, and <tag> is the tag.

Images are stored in the trash for 30 days.





 Example 

To restore the image us.icr.io/birds/bluebird:1, run the following command.

ibmcloud cr image-restore us.icr.io/birds/bluebird:1

For more information about how to use the ibmcloud cr image-restore command, see [Restoring images](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_images_registry_images_restore).







 ibmcloud cr image-rm 

Delete one or more specified images from Container Registry. You can reference the image that you want to delete either by [digest](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_digest) or by [tag](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_tag).

Where multiple tags exist for the same image digest within a repository, the ibmcloud cr image-rm command removes the underlying image and all its tags. If the same image exists in a different repository or namespace, that copy of the image is not removed. If you want to remove a tag from an image and leave the underlying image and any other tags in place, use the [ibmcloud cr image-untag](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_untag) command.
r134-f83ce520-00b5-40c5-9938-a5c82a273f91 ibm-debian-11-3-minimal-amd64-4 available amd64 debian-11-amd64 11.x Bullseye/Stable 1

For a full list of command options, see [ibmcloud is images](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-referenceimages-list).

Deprecated images do not include the most current support.
* To list all available images shared from a private catalog, run the following commands:

If you select a catalog image that belongs to a different account, you have extra considerations and limitations to review. See [Using cross-account image references in a private catalog in the CLI](https://cloud.ibm.com/docs/vpc?topic=vpc-planning-custom-images&interface=uiprivate-catalog-image-reference-vpc-cli)



* To list all available private catalog image offerings, run the following command.

ibmcloud is catalog-image-offerings

This command returns the identifier of each image offering and the identifier of the private catalog where the image is. Save the offering_id and catalog_id in variables, which are used later to provision an instance.

offering_id=6bf79f7b-de48-4ce8-8cae-866b376f2889
catalog_id=71306253-8444-4cae-a45d-64d35e5393ec
* To get the offering_crn for the offering and the offering_version_crn for each version in the offering, run the following command.

ibmcloud is catalog-image-offering $catalog_id $offering_id



When you provision an instance, you can either provision the instance from the private catalog-managed image in the latest version in a catalog product offering by using the offering_crn value or from the specific version in the catalog product offering by using the offering_version_crn value.
To import a custom image by using the CLI, use the ibmcloud is image-create command. Specify the name of the custom image to be created by using the IMAGE_NAME variable. You must also specify the source; for example, specify the --file option with the image file location. Specify the --os-name option with the name of the operating system for the image.

ibmcloud is image-create IMAGE_NAME [--file IMAGE_FILE_LOCATION] [--os-name OPERATING_SYSTEM_NAME]

The following example creates a custom image with the name of my-ubuntu-16-amd64. The image source location is cos://us-south/custom-image-vpc-bucket/customImage-0.qcow2. The operating system is ubuntu-16-amd64.

ibmcloud is image-create my-ubuntu-16-amd64 --file cos://us-south/custom-image-vpc-bucket/customImage-0.qcow2 --os-name ubuntu-16-amd64

For more information, see [ibmcloud is image-create](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-referenceimage-create) in the VPC CLI reference page.



 Schedule custom image lifecycle status changes by using the CLI 

When you import a custom image by using the command-line interface (CLI), you can also schedule the lifecycle status changes of an IBM Cloud VPC custom image at the same time by using options of the ibmcloud is image-create command.

Specify the name of the custom image to be created by using the IMAGE_NAME variable. You must also specify the source; for example, specify the --file option with the image file location. Specify the --os-name option with the name of the operating system for the image.

To schedule the deprecate-at or obsolete-at properties, specify a date in the ISO 8601 (YYYY-MM-DDThh:mm:ss+hh:mm) date and time format.
While this image contains many useful utilities, the more utilities that are in a base image, then the larger its size is. Additionally, by including more utilities, you increase the chance that you might encounter a security vulnerability, requiring you to rebuild your image. To avoid both of these issues, use a smaller base image. For example,



* [Alpine](https://hub.docker.com/_/alpine) is an official Docker image with small size. For programming environments like Java or Node.js, you often find tags that are based on Alpine.
* [Distroless images from Google Container Tools](https://github.com/GoogleContainerTools/distroless) contain no operating system tools at all but the necessary runtime environment for different languages like Java and Node.js.



Compare these base images by building a container image that runs a Node.js program in a program.js file. For Ubuntu, the Dockerfile looks similar the following example,

FROM ubuntu

RUN 
apt update && 
apt upgrade -y && 
apt install -y nodejs && 
apt clean && 
rm -rf /var/lib/apt/lists/*

COPY program.js /app/program.js

WORKDIR /app

ENTRYPOINT ["node", "program.js"]

For Alpine, the image is taken directly from Node.js,

FROM node:16-alpine

COPY program.js /app/program.js

WORKDIR /app

ENTRYPOINT ["node", "program.js"]

For distroless, use the following example,

FROM gcr.io/distroless/nodejs:16

COPY program.js /app/program.js

WORKDIR /app

CMD ["program.js"]

While the Ubuntu-based image is 147 MB, the image that is based on Alpine is 90 MB and the image that is based on distroless is 94 MB.





 Do not include sources and build tools to reduce image size
* [ibmcloud cr image-list (ibmcloud cr images)](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_list)



* [Prerequisites](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_list_prereq)
* [Command options](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_list_option)
* [Example](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_list_example)



* [ibmcloud cr image-prune-untagged](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregcliic_cr_image_prune_untagged)



* [Prerequisites](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregcliic_cr_image_prune_untagged_prereq)
* [Command options](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregcliic_cr_image_prune_untagged_option)
* [Example](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregcliic_cr_image_prune_untagged_example)



* [ibmcloud cr image-restore](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_restore)



* [Prerequisites](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_restore_prereq)
* [Command options](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_restore_option)
The following commands have been deprecated from this patch and are no longer available: * policy route pbr <name> rule <rule-number> application name <name> * policy route pbr <name> rule <rule-number> application type <type> * policy qos name <policy-name> shaper class <class-id> match <match-name> application name <name> * policy qos name <policy-name> shaper class <class-id> match <match-name> application type <type> * security application firewall name <name> rule <rule-number> name <app-name>

Running any of the above commands will result with the error message “This feature is disabled.”







 1801w 



 Issues Resolved 



Issues resolved for 1801w

 Issue Number Priority Summary 

 VRVDR-45672 Critical The RSA private key at /opt/vyatta/etc/config/ipsec.d/rsakeys/localhost.key has wrong permissions 
 VRVDR-45591 Critical Interface IP MTU change not taking effect for Intel x710 NICs 
 VRVDR-45466 Minor IPv6 address not abbreviated when config is loaded via PXE boot causing config-sync issues 
 VRVDR-45414 Minor Vyatta-cpu-shield fails to start and throws OSError:[Errno 22] Invalid argument for various cores on a two socket system 







 Security Vulnerabilities Resolved 



Security vulnerabilities resolved for 1801w

 Issue Number CVSS score Advisory Summary 

 VRVDR-45253 7.5 DSA-4375-1 CVE-2019-3813: Debian DSA 4375-1: spice - security update 
 VRVDR-44922 7.5 DSA-4355-1 CVE-2018-0732, CVE-2018-0734, CVE-2018-0737, CVE-2018-5407: Debian DSA-4355-1 : openssl1.0 - security update 
 VRVDR-43936 7.5 DSA-4309-1 CVE-2018-17540: Debian DSA-4309-1 : strongswan - security update 









 1801v
If you delete an image in error, you can restore the image by using the [ibmcloud cr trash-list](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_trash_list) and [ibmcloud cr image-restore](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_restore) commands.

To set a policy and immediately move your deleted images to the trash, complete the following steps:



1. Log in to IBM Cloud by running the ibmcloud login command.
2. Choose the registry in which you want to clean up your images by running the following command and selecting the appropriate region:

ibmcloud cr region-set
3. To set a policy that retains the most recent images and deletes the others, run one of the following commands:



* If you want to clean up both tagged and untagged images, run the following command:

ibmcloud cr retention-policy-set --images <image_count> <namespace>

Where <image_count> is the number of images that you want to retain for each repository within your namespace, <namespace>.

A list of images to delete is displayed.
* If you want to clean up tagged images only and retain all untagged images, run the following command:

ibmcloud cr retention-policy-set --retain-untagged --images <image_count> <namespace>

Where <image_count> is the number of images that you want to retain for each repository within your namespace, <namespace>.

A list of images to delete is displayed.



4. Review the list of images. To run the policy and delete the images, confirm that you want to set the policy.

If you don't want to delete those images, choose No. The policy is not set and the images are not deleted.
5. Verify that the images were deleted by running the following command, and check that the images show in the list.

ibmcloud cr trash-list
6.
Note that you can use this command to update your ALB image to a different version, but you can't use this command to change your ALB from one type of image to another. After you force a one-time update, automatic updates remain disabled, but can be re-enabled with the ibmcloud ks ingress alb autoupdate enable command.

ibmcloud ks ingress alb update --cluster CLUSTER [--alb ALB1_ID --alb ALB2_ID ...] [--version IMAGE_VERSION] [--output json] [-q]

Minimum required permissions
: Editor platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster where you want to update the ALBs.

--alb CLUSTER
: Optional: The ID of the individual ALB to update. To list ALB IDs, run ibmcloud ks ingress alb ls -c <cluster>. To update multiple ALBs, use multiple options, such as --alb ALB1_ID --alb ALB2_ID. If you omit this option, all ALBs in the cluster are updated.

--version IMAGE_VERSION
: Optional: The version of the image that you want to update ALBs to.

--output json
: Optional: Prints the command output in JSON format.

-q
: Optional: Do not show the message of the day or update reminders.



* To update all ALB pods in the cluster:

ibmcloud ks ingress alb update -c mycluster --version 1.1.2_2507_iks
* To update the ALB pods for one or more specific ALBs:

ibmcloud ks ingress alb update -c mycluster --version 1.1.2_2507_iks --alb public-crdf253b6025d64944ab99ed63bb4567b6-alb1







 ibmcloud ks ingress alb versions 

Virtual Private Cloud

Classic infrastructure
You can detect and delete old images from all the repositories in a namespace by running a one-off command, ibmcloud cr retention-run, or by setting a scheduled policy by running the ibmcloud cr retention-policy-set command. For more information, see [Cleaning up your namespaces](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_retention).





 Deleting private repositories 

You can delete private repositories that are no longer required, and any associated images, by using the IBM Cloud console. For more information, see [Deleting a private repository and any associated images](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_images_registry_repo_remove).







 Restoring deleted data 

You can restore images from the trash by [digest](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_digest) or by [tag](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_tag).

You can restore an image from the trash by running the ibmcloud cr image-restore command. To find out which images are in the trash, run the ibmcloud cr trash-list command. Images are stored in the trash for 30 days. For more information, see [Restoring images](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_images_registry_images_restore).
Click the virtual server that you want to use to create an image template.

Check the Passwords tab of the Device Details page. Make sure that any passwords that are listed on the Device Details page match the actual operating system passwords and any other software add-on passwords. If passwords don't match, virtual servers that are created from this image template fail.
3. From the Actions menu, select Create Image Template.
4. Enter the new name for the image in the Image Name field.
5. Enter any necessary notes for the image in the Note field.
6. Select the Agree checkbox when all information is entered.
7. Click Create Template to create the image template.



Your server is offline until the imaging process completes. The image template processing time varies based on the resources that are available on the physical host and how much data is captured in the image template.





 Next steps 

After the image template is created, you can create more virtual servers by using the template. The new virtual servers have the same configurations that are included in the image template.
new_image_tag="${new_image_tag/gcr.io/$target_cr}"
docker tag $image $new_image_tag
docker push $new_image_tag
 replace the image reference in the installation.yaml file
sed -i "s$image$new_image_tagg" $install_filename
done

echo ""
echo "Provisioning of docker images to $target_cr done."
echo "Update of the install file $install_filename done"
echo "Change the scope of the images to global before"
echo "running 'kubectl apply --filename $install_filename'
echo "to install the delivery pipeline private worker"
Show more

This script contains the following requirements:



* The ibmcom and tekton-releases namespaces currently exist on the target IBM Cloud® Private.
* The Docker client is connected to the IBM Cloud® Private’s private container registry. For more information about authentication for the Docker CLI, see [Configuring authentication for the Docker CLI](https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.2.0/manage_images/configuring_docker_cli.html).



After you provision the container images on the IBM Cloud® Private’s private registry, update the image's scope to global to make sure that the images can be accessed from any namespaces. For more information about updating the scope of an image, see [Changing image scope](https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.2.0/manage_images/change_scope.html).

You can provide pipeline users with access to the base images (icr.io/continuous-delivery/pipeline/pipeline-base-image) that are used to run pipeline jobs, which are supplied by the global IBM Cloud Container Registry. To use these images, you must configure your pipeline jobs by using the Custom Dockerimage.
--pull-latest or --pl Optional Pull the latest changes from your GitHub repository into workspace. If this flag is set --file flag is ignored. 
 --output or -o Optional Returns the command-line output in JSON format. Currently only JSON file format is supported. 
 --json or -j Deprecated Prints the output in the JSON format. 





 Update file template in JSON format 

You can create the JSON as shared in the example.json file for workspace update and pass the file path along with the file name in --file flag. The description of all the parameters of example.json is described in the table.

You need to replace the <...> placeholders with the actual values. For example, "<workspace_name>" as "testworkspace".

example.json:

{
"name": "<workspace_name>",
"type": "<terraform_version>",
"description": "<workspace_description>",
"tags": [],
"resource_group": "<resource_group>",
"workspace_status": {
"frozen": "<true_or_false>"
},
"template_repo": {
"url": "<source_repo_url>"
},
"template_data": [
{
"folder": ".",
"type": "<terraform_version>",
"env_values":
{
"VAR1":"<val1>"
},
{
"VAR2":"<val2>"
}
],
"variablestore":
{
"name": "<variable_name1>",
"value": "<variable_value1>",
"type": "<variable_type1>",
"secure": true,
"use_default": true },
{