vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Remove the VPE gateway that was created before 11 November 2022, see [Deleting an endpoint gateway](https://cloud.ibm.com/docs/vpc?topic=vpc-vpe-deleting-ui-cli-api&interface=ui).



* If you use a Container Registry VPE gateway that was created before 11 November 2022 and you use IAM restricted IP address lists, you must re-create your Container Registry VPE gateway and update your IAM restricted IP address lists before 15 December 2022. If you don't re-create your VPE gateway and update your IP address lists, the VPE gateway will not connect to Container Registry after that date.

To replace the VPE gateway and update your IAM restricted IP address lists, complete the following steps:



1. Update your IAM restricted IP address lists to access the [Cloud service endpoint source addresses](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-behind-the-curtaincse-source-addresses) of your VPC. You can find the CSEs by viewing the details of your VPC in either the IBM Cloud console or CLI.
2. Create a VPE gateway for Container Registry in the required VPC, see [Creating an endpoint gateway](https://cloud.ibm.com/docs/vpc?topic=vpc-ordering-endpoint-gateway&interface=ui). If you’re using the CLI, you might want to refer to the Container Registry VPE CRNs. For more information, see [Setting up a VPE for IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_vpe&interface=uiregistry_vpe_endpoint_setup).
3. Remove the VPE gateway that was created before 11 November 2022, see [Deleting an endpoint gateway](https://cloud.ibm.com/docs/vpc?topic=vpc-vpe-deleting-ui-cli-api&interface=ui).
To create an IBM Cloud IAM API key with the CLI, run the [iam api-key-create](https://cloud.ibm.com/docs/account?topic=cli-ibmcloud_commands_iamibmcloud_iam_api_key_create) command. For example, to create an API key called cliapikey with a description of "My CLI API key" and save it to a file called key_file, run the following command:

ibmcloud iam api-key-create cliapikey -d "My CLI API key" --file key_file

If you choose to not save your key to a file, you must record the API key that is displayed when you create it. You cannot retrieve it later.

Now that you created your API key, [save it as registry access](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryadd-registry-access-ce).







 Accessing images in a shared account 

To access images from IBM Cloud Container Registry in a shared account, you must be assigned the [proper authority](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryauthorities-registry).

If you are planning to deploy apps and run jobs from the shared account, Code Engine can pull or push images for you when you deploy your application or create your job.

If you want to pull images from the shared account to your own account, then you must be [authorized to access IBM Cloud Container Registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryauthorities-registry).





 Accessing images in a different account 

You can assign IBM Cloud IAM access policies to users or a service ID to restrict permissions to specific registry image namespaces or actions (such as push or pull). Then, create an API key and store these registry credentials in Code Engine.
Formatting and filtering the CLI output 

You can format and filter the IBM Cloud® Container Registry CLI output for supported IBM Cloud Container Registry commands.

By default, the CLI output is displayed in a human-readable format. However, this view might limit your ability to use the output, particularly if the command is run programmatically. For example, in the ibmcloud cr image-list CLI output, you might want to sort the Size field by numerical size, but the command returns a string description of the size. The container-registry CLI plug-in provides the format option that you can use to apply a Go template to the CLI output. The Go template is a feature of the [Go programming language](https://pkg.go.dev/text/template) that you can use to customize the CLI output.

You can alter the CLI output by applying the format option in two different ways:



* Format data in your CLI output. For example, change the Created field output from UNIX® time to standard time.
* Filter data in your CLI output. For example, filter by details of the image to display a specific subset of images by using the Go template if gt condition.



You can use the format option with the following IBM Cloud Container Registry commands. Click a command to view a list of available fields and their data types.



* [ibmcloud cr image-digests](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_cli_listregistry_cli_list_imagedigests) command
* [ibmcloud cr image-list](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_cli_listregistry_cli_list_imagelist) command
* [ibmcloud cr image-inspect](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_cli_listregistry_cli_list_imageinspect) command



The following code examples demonstrate how you might use the formatting and filtering options.
After you create the build, you must [run the build](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-imagebuild-run).



If you receive a command validation failure, check that your secret exists. If you refer to an registry secret (--registry-secret) for your image and the secret does not exist, see [Accessing container registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registry). For more information about builds, check the [troubleshooting tips](https://cloud.ibm.com/docs/codeengine?topic=codeengine-troubleshoot-build).









 Create a build configuration that pulls source from private repository 

If your source is located in a private repository, create a build configuration with settings that include information about where to pull source from a private repository. For the build output, you can choose to specify registry details along with a registry secret to access your built image in the registry. Or, 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. For this case, you do not need to specify a registry secret or the location of the image registry.

Creating a build configuration does not create an image, but creates the configuration to build an image. You must then run a build that references the build configuration to create an image. The build configuration is not validated or used to create an image until the build is run. The build configuration enables multiple subsequent builds of an image, such as when changes are applied to the source repository.



 Creating a build configuration from the console (private repo) 



1. Go to the [Code Engine dashboard](https://cloud.ibm.com/codeengine/overview).
2. Select the project where you added your container registry.
3. From the project page, click Image builds.
4. Click Create. The Specify build details side panel opens where you enter the details of your build.
5.
Now, all the public and private icr.io registry domains for all regions are stored in a single all-icr-io image pull secret that is automatically created in the default Kubernetes namespace of your cluster.

For workloads in other Kubernetes namespaces in the cluster to pull container images from a private registry, you can now copy only the all-icr-io image pull secret to that Kubernetes namespace. Then, specify the all-icr-io secret in your service account or deployment. You don't need to copy the image pull secret that matches the regional registry of your image anymore. Also, keep in mind that you don't need image pull secrets for public registries, which don't require authentication.

My cluster image pull secret uses a registry token. Does a token still work?
: From 19 August 2021, using IBM Cloud Container Registry tokens is discontinued and no longer works. For more information, see [IBM Cloud Container Registry Deprecates Registry Tokens for Authentication](https://www.ibm.com/cloud/blog/announcements/ibm-cloud-container-registry-deprecates-registry-tokens-for-authentication).

After I copy or create an image pull secret in another Kubernetes namespace, am I done?
: Not quite. Your containers must be authorized to pull images by using the secret that you created. You can add the image pull secret to the service account for the namespace, or refer to the secret in each deployment. For instructions, see [Using the image pull secret to deploy containers](https://cloud.ibm.com/docs/containers?topic=containers-registryuse_imagePullSecret).





 Private network connection to icr.io registries 

When you use the private network to pull images, your image pull traffic is not charged as [public bandwidth](https://cloud.ibm.com/docs/containers?topic=containers-costsbandwidth), because the traffic is on the private network. For more information, see the [IBM Cloud Container Registry private network documentation](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_private).
* After you [run your job](https://cloud.ibm.com/docs/codeengine?topic=codeengine-run-job), to view details of your job and job runs, see [access job details](https://cloud.ibm.com/docs/codeengine?topic=codeengine-access-job-details).
* Now that your job is created, consider making your jobs event-driven. By using event subscriptions, you can trigger your jobs by [periodic schedules](https://cloud.ibm.com/docs/codeengine?topic=codeengine-subscribe-croneventing-cron-job) or set your job to react to events like [file uploads](https://cloud.ibm.com/docs/codeengine?topic=codeengine-eventing-cosevent-producerobstorage_ev_job).
* You can [update your job](https://cloud.ibm.com/docs/codeengine?topic=codeengine-update-job) and its referenced code in any of the following ways, independent of how you created or previously updated your job.



* If you have a container image, per the [Open Container Initiative (OCI) standard](https://opencontainers.org/), then you need to provide only a reference to the image, which points to the location of your container registry when you create (or update) your job. You can create (or update) your job from images in a [public registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-create-job) or [private registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-create-job-private) and then access the referenced image from your job run.

If you created your job by using the job create command and you specified the --build-source option to build the container image from local or repository source, and you want to change your job to point to a different container image, you must first remove the association of the build from your job.
image: <region>.icr.io/<namespace_name>/<image_name>:<tag>
imagePullSecrets:
- name: <secret_name>

To access an IBM Cloud public image,

apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: <container_name>
image: icr.io/<image_name>:<tag>
imagePullSecrets:
- name: <secret_name>

container_name>
: The name of the container to deploy to your cluster. namespace_name>
: The registry namespace where the image is stored. To list available namespaces, run ibmcloud cr namespace-list. image_name>
: The name of the image to use. To list available images in an IBM Cloud account, run ibmcloud cr image-list. tag>
: The version of the image that you want to use. If no tag is specified, the image that is tagged latest is used by default. <secret_name>
: The name of the image pull secret that you created earlier.
3. Save your changes.
4. Create the deployment in your cluster.

kubectl apply -f mypod.yaml







 Pushing images to IBM Cloud Container Registry 

After the cluster administrator [sets up an image registry with IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-startedgetting-started), you can securely store and share Docker images with other users by adding images to your namespace.

For example, you might pull an image from any private or public registry source, and then tag it for later use in IBM Cloud Container Registry. Or, you might push a Docker image that you work with to your namespace so that other users can access the image. To get started, see [Adding images to your namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_images_).
oc autoscale dc/$MYPROJECT --min=1 --max=5 --cpu-percent=5
3. Rerun the [Monitoring](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-scalable-webapp-openshiftscalable-webapp-openshift-monitor_application) step to generate load on the application.
4. You can see new pods being provisioned by running oc get pods --watch command or by looking at the application in the web console.
5. Remove the auto scaler:

oc delete hpa/$MYPROJECT









 Step 5: (Optional) Build and push the container image to Container Registry 

In this section, you will learn how to use a remote private Container Registry to store the created container images.

IBM Cloud Container Registry provides a multi-tenant, highly available, scalable, and encrypted private image registry that is hosted and managed by IBM. You can use IBM Cloud Container Registry by setting up your own image namespace and pushing container images to your namespace.



1. To identify your Container Registry URL, run

ibmcloud cr region
2. Define an environment variable named MYREGISTRY pointing to the URL such as:

export MYREGISTRY=us.icr.io
3. Pick one of your existing registry namespaces or create a new one. To list existing namespaces, use:

ibmcloud cr namespaces

To create a new namespace:

ibmcloud cr namespace-add <REGISTRY_NAMESPACE>
4. Define an environment variable named MYNAMESPACE pointing to the registry namespace:

export MYNAMESPACE=<REGISTRY_NAMESPACE>
5. Define an environment variable name API_KEY pointing to an IBM Cloud IAM API key.

To create an API key, refer to this [link](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_user_apikey_create).
6.
Deploy an application that uses an image in Container Registry by using the Code Engine console.

Code Engine can automatically pull images from a Container Registry namespace in your account. To pull images from a different Container Registry account or from a private Docker Hub account, see [Deploying application workloads from images in a private registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-deploy-app-private).



1. Open the [Code Engine](https://cloud.ibm.com/codeengine/overview) console.
2. Select Start creating from Run a container image.
3. Select Application.
4. Enter a name for the application; for example, helloapp. Use a name for your application that is unique within the project.
5. Select a project from the list of available projects. You can also [create a new one](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-projectcreate-a-project). You must have a selected project to deploy an app.
6. Select Container image and click Configure image.
7. Select a container registry location, such as IBM Registry, Dallas.
8. Select Code Engine managed secret for Registry access secret. Because this example uses an image in a Container Registry namespace in your account, Code Engine can automatically create and manage the registry access secret for you.
9. Select an existing namespace and name of the image in the registry for the Code Engine app to reference. For example, select mynamespace and select the image hello_repo in that namespace.
10. Select a value for Tag; for example, latest.
11. Click Done.
12. Modify any runtime settings or environment variables for your app.
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. You must also reference the expected image in the IBM Cloud® Private’s private registry, for example: mycluster.icp:8500/icr.io/continuous-delivery/pipeline/pipeline-base-image:latest.
* Can I manage private workers by using Terraform or APIs?

You can use Terraform or APIs to add, update, or remove Delivery Pipeline private worker tool integrations in a toolchain. For more information about working with the Delivery Pipeline private worker tool integration, see [Working with tool integrations](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-integrations) and [Configuring Delivery Pipeline Private Worker](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-privateworker).

You cannot use Terraform or APIs to manage Delivery Pipeline private workers. Instead, use the console or the CLI to install, register, configure, and update private workers.
By completing this tutorial, you learn how to import the Red Hat OpenShift on IBM Cloud Operator bundle, configure the deployment, license, and other details, and validate that the Operator bundle can be installed on a cluster.

Container Registry Selling on IBM Cloud



* 45 minutes
* 2023-03-31



[Onboarding your Operator](https://cloud.ibm.com/docs/sell?topic=sell-operator-onboard)Onboarding your Operator

This tutorial walks you through how to onboard a sample Node-RED Operator to your private catalog in IBM Cloud®. You can onboard an Operator or Operator bundle by using a TGZ file. By completing this tutorial, you learn how to import the Operator, configure the deployment, license, and other details, and validate that the Operator can be installed on a Red Hat OpenShift cluster.

Container Registry Selling on IBM Cloud



* 45 minutes
* 2023-03-31



[Analyze logs and monitor application health ](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-application-log-analysis)Analyze logs and monitor application health

This tutorial shows how the IBM Log Analysis service can be used to configure and access logs of a Kubernetes application that is deployed on IBM Cloud. You will deploy a Python application to a cluster provisioned on IBM Cloud Kubernetes Service, configure a logging agent, generate different levels of application logs and access worker logs, pod logs or network logs. Then, you will search, filter and visualize those logs through Log Analysis Web UI.

Kubernetes service Log Analysis

+2

Container Registry,Monitoring



* 2 hours
* 2023-05-05



[Enhance cloud security by applying context-based restrictions](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-cbr-enhanced-security)Enhance cloud security by applying context-based restrictions

This tutorial walks you through the process of implementing context-based restrictions (CBRs) in your IBM Cloud account. CBRs help you to secure the cloud environment further and move towards a zero trust security model.
The internal registry is backed up to IBM Cloud Object Storage only for Red Hat OpenShift on IBM Cloud clusters that run version 4 on VPC infrastructure.

However, if the bucket fails to create when you create your cluster, you must manually create a bucket and set up your cluster to use the bucket. In the meantime, the internal registry uses an emptyDir Kubernetes volume that stores your container images on the secondary disk of your worker node. The emptyDir volumes are not considered persistent highly available storage, and if you delete the pods that use the image, the image is automatically deleted.

To manually create a bucket for your internal registry, see [Cluster create error about cloud object storage bucket](https://cloud.ibm.com/docs/openshift?topic=openshift-ts_cos_bucket_cluster_create).





 Storing images in the internal registry in Classic clusters 

By default, your Red Hat OpenShift cluster's internal registry uses an [IBM Cloud File Storage for Classic](https://cloud.ibm.com/docs/openshift?topic=openshift-file_storage) volume to store the registry images. You can review the default size of the storage volume, or update the volume size.



 Viewing volume details 

To view volume details including the storage class and size, you can describe the persistent volume claim.

oc describe pvc -n openshift-image-registry image-registry-storage





 Changing volume details 

If your registry needs additional gigabytes of storage for your images, you can resize the file storage volume. For more information, see [Changing the size and IOPS of your existing storage device](https://cloud.ibm.com/docs/openshift?topic=openshift-file_storagefile_change_storage_configuration). When you resize the volume in your IBM Cloud infrastructure account, the attached PVC description is not updated. Instead, you can log in to the openshift-image-registry pod that uses the registry-backing PVC to verify that the volume is resized.







 Storing images in the worker node empty directory
For a list of updated Container Registry VPE CRNs, see [Setting up a VPE for IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_vpe&interface=uiregistry_vpe_endpoint_setup).

If you are using a Container Registry VPE gateway that was created before 11 November 2022 and also maintain IAM restricted IP address lists, you must change your restricted IP address list to contain your VPC Cloud Service Endpoint source addresses.





 What actions you must take 



* If you use a Container Registry VPE gateway that was created before 11 November 2022, you must re-create your Container Registry VPE gateway before 15 December 2022. If you don't re-create your VPE gateway, the VPE gateway will not connect to Container Registry after that date.

To replace the VPE gateway, complete the following steps:



1. Create a VPE gateway for Container Registry in the required VPC, see [Creating an endpoint gateway](https://cloud.ibm.com/docs/vpc?topic=vpc-ordering-endpoint-gateway&interface=ui). If you’re using the CLI, you might want to refer to the Container Registry VPE CRNs. For more information, see [Setting up a VPE for IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_vpe&interface=uiregistry_vpe_endpoint_setup).
2. Remove the VPE gateway that was created before 11 November 2022, see [Deleting an endpoint gateway](https://cloud.ibm.com/docs/vpc?topic=vpc-vpe-deleting-ui-cli-api&interface=ui).



* If you use a Container Registry VPE gateway that was created before 11 November 2022 and you use IAM restricted IP address lists, you must re-create your Container Registry VPE gateway and update your IAM restricted IP address lists before 15 December 2022.