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.

Where multiple tags exist for the same image digest within a repository, the [ibmcloud cr image-rm](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_rm) command removes the underlying image and all its tags. If the same image exists in a different repository or namespace, the 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, see [Removing tags from images in your private repository](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_images_registry_images_untag) command.



 Deleting images from your private repository in the CLI 

You can delete unwanted images and all their tags from your private IBM Cloud repository by using the CLI.

Deleting an image that is being used by an existing deployment might cause scale-up, reschedule, or both, to fail.

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 delete an image by using the CLI, complete the following steps:



1. Log in to IBM Cloud by running the ibmcloud login command.
2.
If you want more control over the build of your image, then you can choose to [build the image](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-image) with Code Engine before you create (or update) your job and run the job.



For example, you might choose to let Code Engine handle the build of your local source while you evolve the development of your source for the job. Then, after the image is matured, you can update the job to reference the specific image that you want. You can repeat this process as needed.

When you run your updated job, the latest version of your referenced container image is used for the job run, unless a tag is specified for the image. If a tag is specified for the image, then the tagged image is used for the job run.



Looking for more code examples? Check out the [Samples for IBM Cloud Code Engine GitHub repo](https://github.com/IBM/CodeEngine).
Schedule lifecycle Opens the Schedule image lifecycle panel. You can make an immediate status change or schedule a statue change for a future date and time. You can schedule a single status change or schedule the complete lifecycle of the images. The image statuses are:<br><br><br><br> * available: The image can be used to create an instance.<br> * deprecated: The image is still available to use to provision and instance. Using the deprecated status can discourage use of the image before the status changes to obsolete.<br> * obsolete: The image is not available to use to provision an instancce.<br> * Schedule complete lifecycle: You can schedule both the deprecated and obsolete status changes at the same time.<br><br><br><br>You can move back and forth between the three statuses. Only the statuses you can change to are displayed. You can schedule status changes by by using calendar date and time or number of days. The obsolescence dates must always be after the deprecation date. 
 Delete Delete the custom image.<br><br>If you want to delete a custom image in a private catalog, see [Deleting a custom image in a private catalog](https://cloud.ibm.com/docs/vpc?topic=vpc-planning-custom-imagesdeleting-private-catalog-custom-image-vpc). 







 Listing custom images by using the CLI 

You can list all of the IBM Cloud VPC custom images in your region by using the command-line interface (CLI).

To list all custom images by using the CLI, use the ibmcloud is images command. Custom images are private to the account where they are created, so the --visibility option is private.

ibmcloud is images --visibility private

For more information, see [ibmcloud is images](https://cloud.ibm.com/docs/vpc?topic=vpc-infrastructure-cli-plugin-vpc-referenceimages) in the VPC CLI reference page.





 Listing all images by using the API
If you get an error when you're restoring an image that says that the tagged image exists, see [Why do I get an error when I'm restoring an image?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-image-restore) for assistance.

If you run the ibmcloud cr trash-list command, the digest and any other tags show in the output, but the tag is no longer displayed.









 Deleting a private repository and any associated images 

You can delete private repositories that are no longer required, and any associated images, by using the IBM Cloud console.

When you delete a repository, all images in that repository are deleted. This action can't be undone.

Before you begin, you must back up any images that you want to keep.

To delete a private repository by using the IBM Cloud console, complete the following steps:



1. Log in to the IBM Cloud console [https://cloud.ibm.com/login](https://cloud.ibm.com/login) with your IBMid.
2. If you have multiple IBM Cloud accounts, from the account menu, select the account and region that you want to use.
3. Click the Navigation menu icon, then click Container Registry.
4. Click Repositories. A list of your private repositories is displayed.
5. In the row that contains the private repository that you want to delete, select the checkbox.

Ensure that the correct repository is selected because this action can't be undone.
6. Click Delete Repository.
(https://cloud.ibm.com/docs-content/v1/content/ad5f41087138b4b1bb795e3b5b0661ac5a105cbd/codeengine/images/confirm.png) 
 Delete a project. ![Checkmark icon.](https://cloud.ibm.com/docs-content/v1/content/ad5f41087138b4b1bb795e3b5b0661ac5a105cbd/codeengine/images/confirm.png) ![Checkmark icon.](https://cloud.ibm.com/docs-content/v1/content/ad5f41087138b4b1bb795e3b5b0661ac5a105cbd/codeengine/images/confirm.png) 
 Update a project. ![Checkmark icon.](https://cloud.ibm.com/docs-content/v1/content/ad5f41087138b4b1bb795e3b5b0661ac5a105cbd/codeengine/images/confirm.png) ![Checkmark icon.](https://cloud.ibm.com/docs-content/v1/content/ad5f41087138b4b1bb795e3b5b0661ac5a105cbd/codeengine/images/confirm.png) 
 View Code Engine dashboard. ![Checkmark icon.](https://cloud.ibm.com/docs-content/v1/content/ad5f41087138b4b1bb795e3b5b0661ac5a105cbd/codeengine/images/confirm.png) ![Checkmark icon.]
* For image, the URI must contain the image digest (for example docker://us.icr.io/foo/bar:v1.2.3@sha256:0000000011111111222222223333333344444444555555556666666677777777)



When type is anything other than image or commit, the --type flag must be explicitly passed.

More details can be added to the asset by using the --details flag, which accepts key=value pairs.

More details about the origin of the asset can be provided by using the --origin flag, which accepts key=value pairs.

Some environment variables are automatically picked up to add details about the asset origin:



* Setting TOOLCHAIN_CRN is the same as specifying --origin toolchain_crn=$TOOLCHAIN_CRN
* Setting PIPELINE_ID is the same as specifying --origin pipeline_id=$PIPELINE_ID
* Setting PIPELINE_RUN_ID is the same as specifying --origin pipeline_run_id=$PIPELINE_RUN_ID



The --date flag can be used to override the asset creation date (defaults to the current time), it accepts any string that [Date.parse](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse) accepts.

Related assets can be added by using the --related flag (for multiple related assets, the flag can be specified multiple times). Assets can be specified with their internal ID, or by their URI.

By default, the id format (the --format flag) prints the internal ID of the created asset. With the json format, the whole asset is going to be printed, as a JSON object.

Running the command to add a Git commit:

$ cocoa locker asset add 'https://github.ibm.com/foo/bar.gitaaaaaaaabbbbbbbbccccccccddddddddeeeeeeee' --details tag=v1.2.3

Example output:
SOURCE_IMAGE must be in the format repository:tag or repository@digest and TARGET_IMAGE must be in the format repository:tag, for example, us.icr.io/namespace/image:latest.

To find the names of your images, run ibmcloud cr image-list. Combine the content of the Repository column (repository) and Tag column (tag) separated by a colon (:) to create the image name in the format repository:tag. To identify your image by digest, run the ibmcloud cr image-digests command. Combine the content of the Repository column (repository) and the Digest column (digest) separated by an at (@) symbol to create the image name in the format repository@digest. If the list images command times out, see [Why is it timing out when I list images?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-image-timeout) for assistance.

ibmcloud cr image-tag [SOURCE_IMAGE] [TARGET_IMAGE]
3. Verify that the new image was created by running the following command, and check that the image is shown in the list with the same image [digest](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_digest) as the source image.

ibmcloud cr image-list







 Building Docker images to use them with your namespace 

You can build a Docker image directly in IBM Cloud or create your own Docker image on your local computer and upload (push) it to your namespace in IBM Cloud Container Registry.

Before you begin, complete the following tasks.



* [Install the CLI](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespacecli_namespace_registry_cli_install) to work with images in your namespace.
* [Set up your own namespace in IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespaceregistry_namespace_setup).
* 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. From the Dashboard in [IBM Cloud console](https://cloud.ibm.com/), create an image template by clicking menu![Menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) > Classic Infrastructure > Devices > Device List.
2. Click the virtual server that you want to use.
3. From the Actions menu, select Create Image Template. Make sure to name it something you can easily recognize. For more information, see [Creating an image template](https://cloud.ibm.com/docs/image-templates?topic=image-templates-creating-an-image-template).







 Step 2 - Locate the image template and provision a virtual server instance 

From the image template that you created, provision a virtual server instance. This instance is a backup. You can customize this backup virtual server to meet the requirements of IBM Cloud VPC. Complete the following steps to create a new instance from the image template.



1. Locate the image template that you created on the Image Templates page by selecting Devices > Manage > Images.
2. Provision a backup virtual server instance from the image template by clicking the Actions icon ![Actions icon](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/icons/action-menu-icon.svg) for the image template and selecting Order Public virtual server instance.







 Step 3 - Customize the virtual server instance for IBM Cloud VPC
[Actions icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/actions-icon-vertical.svg) for the version you want to deprecate on the Software tab. If your software has only one published version, and you deprecate that version, the entire product is deprecated.





 Deprecating software from the IBM Cloud catalog by using the API 

You can programmatically deprecate your product by calling the [Partner Center Sell API](https://cloud.ibm.com/apidocs/partner-center-selldeprecate-product) as shown in the following sample request. Specify reason to provide details about why you want to deprecate your published product:

curl --request POST --url https://product-
lifecycle.api.cloud.ibm.com/openapi/v1/products/9fab83da-98cb-4f18-
a7ba-b6f0435c9673/deprecate --header 'Authorization: Bearer TOKEN' --data '{
"reason": "I need to permanently delete my product from the IBM Cloud catalog."
}'
* UI
* API







 Deprecating software from the IBM Cloud catalog 

If you need to permanently delete your product or version from the IBM Cloud® catalog, deprecate it first. Your product remains available for use during a 90-day deprecation period, and is removed after 90 days.

Deprecating your product or version will permanently delete it from the IBM Cloud catalog. If you want to temporarily remove your product from the catalog, suspend it instead.



 Deprecating software from the IBM Cloud catalog by using the console 

Complete the following steps to deprecate your product or version:



1. In the IBM Cloud console, click the Navigation Menu icon ![Navigation Menu icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/icon_hamburger.svg) > Partner Center > Sell > My products.
2. Click the Actions icon ![Actions icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/actions-icon-vertical.svg) for the product that you want to deprecate, and select Deprecate.
3. Optionally, you can include more details, like a link to a deprecation announcement.
4. Click Deprecate.



You can deprecate a specific version of your software by clicking the Actions icon ![Actions icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/actions-icon-vertical.svg) for the version you want to deprecate on the Software tab. If your software has only one published version, and you deprecate that version, the entire product is deprecated.





 Deprecating software from the IBM Cloud catalog by using the API
To make the image smaller, use a feature called multi-stage builds. Each stage in a Docker build has its own base image and can run commands in its stage. At the end, a final image is built that copies in artifacts from previous stages. To build a container image from source code, a common pattern is to have two stages:



1. The builder stage that uses a base image that contains all the necessary tools to compile the source code into the binary for the runtime.
2. The runtime stage that uses a base image with the runtime environment that is necessary to run the binary. The binary from the builder stage is copied into this stage.



For the Maven project, the result looks similar to the following example,

FROM maven:3-jdk-11-openj9 AS builder

WORKDIR /app
COPY . /app

RUN mvn package

FROM adoptopenjdk:11-jre-openj9

WORKDIR /app
COPY --from=builder /app/target/java-application-1.0-SNAPSHOT-fat.jar /app/java-application.jar

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app/java-application.jar"]

In this example, the builder stage uses the Maven base image to build the JAR file of the application. The runtime stage uses the smaller JRE base image. By using the COPY --from=STAGE_NAME command, the JAR file is copied from the builder stage into the runtime stage. The resulting image has a size of 242 MB, saving around 48%.

This pattern can also be used for other programming languages where a compilation needs to be performed.



* Node applications that require a build, for example an Angular or React build. Here, the builder and runtime base image might end up being the same (both node), but not all build time artifacts and sources need to be copied into the runtime image.
* Any programming language that compiles source code into a native executable that runs without a runtime environment, for example Go or Rust.
ecc68c2f-96a1-4862-bc86-14f47e5d9ed8 aa-1-bx-boot-1617035447000
Created 2021-05-20T09:43:16+08:00
Visibility private
File size(GB) -
Encryption none
Resource group f22cf48f-8836-4527-9131-1d7c73ba85e9







 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 the 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 and the source by using the --source-volume option to indicate that the source is an existing boot volume.

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.



* YYYY is the four digit year
* MM is the two digit month
* DD is the two digit day
* T separates the date and time information
* hh is the two digit hours
* mm is the two digit minutes
* +hh:mm or -hh:mm is the UTC time zone



Thus, the date of 30 September 2023 at 8:00 p.m. in the North American Central Standard Time Zone (CST) would be 2023-09-30T20:00:00-06:00

When scheduling the date and time, you can't use your current date and time. For example, if it is 8 a.m. on June 12, then the scheduled date and time must be after 8 a.m. on June 12. If you define both the deprecate-at and obsolete-at dates and times, the deprecate-at date must be after the obsolete-at date and time.
* --visibility: List images with given visibility. Valid visibility is: public or private.
* --owner-type: Filters images with given owner type. Default is all. One of: all, provider, user.
* --status: Filters the collection to images with the comma-separated list of status values. Available values: available, deleting, deprecated, failed, obsolete, pending, unusable.
* --resource-group-id: ID of the resource group. This ID is mutually exclusive with --resource-group-name.
* --resource-group-name: Name of the resource group. This name is mutually exclusive with --resource-group-id.
* --all-resource-groups: Query all resource groups.
* --output: Specify output format, only JSON is supported. One of: JSON.
* -q, --quiet: Suppress verbose output.



--------------------







 ibmcloud is image-create 

Create an image.

ibmcloud is image-create IMAGE_NAME ([--file IMAGE_FILE_LOCATION --os-name OPERATING_SYSTEM_NAME --encrypted-data-key ENCRYPTED_DATA_KEY --encryption-key ENCRYPTION_KEY]] | [--source-volume SOURCE_VOLUME --encryption-key-volume ENCRYPTION_KEY_VOLUME]) [--resource-group-id RESOURCE_GROUP_ID | --resource-group-name RESOURCE_GROUP_NAME] [--deprecate-at DEPRECATE_AT] [--obsolete-at OBSOLETE_AT] [--output JSON] [-q, --quiet]



 Command examples 



* ibmcloud is image-create my-ubuntu-16-amd64 --file cos://us-south/custom-image-vpc-bucket/customImage-0.qcow2 --os-name ubuntu-16-amd64
new_image_tag=$image
 if $image only have a single slash it is coming from dockerhub
number_of_slashes=$(echo $image | tr -cd '/' | wc -c)
if [ "$number_of_slashes" == "1" ]; then
new_image_tag="$target_cr/$image"
fi

 replace the sha id reference in the tag if any
new_image_tag="${new_image_tag@sha256}"
 replace gcr.io to the target cr domain
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"

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 example, if you use the [instance data source](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/data-sources/is_instance) to retrieve instance data, you see the following within the data source response.

"image": "r006-e0d3b6fb-5421-4421-9061-0ca9f79a4990"

If you try to retrieve information about this image by using its [data source](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/data-sources/is_image),

data "ibm_is_image" "example" {
identifier = "r006-e0d3b6fb-5421-4421-9061-0ca9f79a4990"
}

then this attempt fails with an error such as the following example:

Error: [ERROR] No image found with id r006-e0d3b6fb-5421-4421-9061-0ca9f79a4990

This error means that the image doesn't exist in your account. If the instance was provisioned by using a shared catalog image in another account, this output is the output that you always see even if the image still exists in the owning account.

Additionally, it is possible that the referenced image might have the same name as a custom image in your account. But these image names are for two different images in two different accounts. While the terraform uses both ID or Name to identify an image, only the ID uniquely identifies an image across IBM Cloud®. To avoid possible retrieval or use of the wrong image by name, specify the image ID instead. For more information, see [image data source](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/data-sources/is_image).





 Deleting a custom image in a private catalog 

A custom image can't be deleted, reused for a different version, or reused for a different product offering while that custom image is managed from a private catalog.
26 May 2022 

CLI version 1.33.0 released
: This version of the CLI updates the build create command so that the --image and --registry-secret options are no longer required. This update means that you can choose to let Code Engine take care of building the image for you from your source and storing the image in IBM Cloud Container Registry with automatic access, or you can choose to specify registry details with a registry access secret for your build output.



* See [CLI version history](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cli_versions).
* See [Building a container image](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-image).



Updated versions for buildpacks
: See [Choosing a build strategy](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-buildbuild-strategy).





 19 May 2022 

CLI version 1.32.0 released
: 

* See [CLI version history](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cli_versions).
* See [Supported environments for Code Engine CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-install-clicli-env).



Added more information about access authorities for image registries
: 

* See [Setting up authorities for image registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryauthorities-registry).







 12 May 2022 

CLI version 1.31.1 released
: See [CLI version history](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cli_versions).





 05 May 2022 

CLI version 1.31.0 released