vania-janet/multiturn-rag-retrieval-data huggingface dataset:
If a tag is not specified in the image name, the command fails.





 Example 

Remove the tag 1 from the image us.icr.io/birds/bluebird:1.

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







 ibmcloud cr info 

Displays the name and the account of the registry that you are logged in to.

ibmcloud cr info



 Prerequisites 

None







 ibmcloud cr login 

Log the local Docker or Podman client in to IBM Cloud Container Registry.

This command is required if you want to run the push or pull commands for the registry. If you want to run other ibmcloud cr commands, you're not required to log in to Container Registry.

ibmcloud cr login [--client CLIENT]

Container Registry supports other clients as well as Docker and Podman. To log in by using other clients, see [Accessing your namespaces interactively](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_interactive).

If you have a problem when you try to log in, see [Why can't I log in to Container Registry?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-login) for assistance. If you're using a Mac and you have a problem when you try to log in, see [Why is Docker login on my Mac failing?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-docker-mac) for assistance.

Logging in to Container Registry by using the ibmcloud cr login command is subject to IAM login session limits. If your login expires, see [Why does the Container Registry login keep expiring?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-login-expire) for assistance.



 Prerequisites 

None





 Command options 

CLIENT
: (Optional) Select the client that you want to log in.
[Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
2. Switch to the default project to pull your image into the image stream. The default project is already set up with credentials to access the icr.io registries.

oc project default
3. List the available images in your IBM Cloud Container Registry. Note the Repository and Tag of the image that you want to pull into the internal registry of your Red Hat OpenShift cluster.

ibmcloud cr images
4. Tag the image to pull it from your IBM Cloud Container Registry namespace into the internal registry as an image stream. For more information, see the [Red Hat OpenShift documentation](https://docs.openshift.com/container-platform/4.11/openshift_images/image-streams-manage.html) or run oc tag --help.

oc tag <region>.icr.io/<namespace>/<image>:<tag> default/<image>:<tag> --reference-policy=local [--scheduled]



* <region>.icr.io/<namespace>/<image>:<tag>: Use the Repository and Tag information that you previously retrieved to fill out the IBM Cloud Container Registry region, namespace, image, and tag name of the image that you want to pull.
* default/<image>:<tag>: Enter the information for the internal image stream that you create from the IBM Cloud Container Registry tagged image. You create this image stream in the default project, which is also the project where the image stream is created if you don't specify a project. The values for <image>:<tag> typically match the values that you previously retrieved.
* --reference-policy=local: Set this value to local so that a copy of the image from IBM Cloud Container Registry is imported into the local cache of the internal registry and made available to the cluster's projects as an image stream.
Deploying app workloads from images in a private registry 

Deploy your app with Code Engine that uses an image in a private registry such as private Docker Hub. You can create an app from the console or with the CLI.

Before you begin



* To pull images from a private registry, you must first create a private registry. For example, to create a private Docker Hub registry, see [Docker Hub documentation](https://docs.docker.com/docker-hub/repos/).
* After you create a private registry, [push an image to it](https://docs.docker.com/docker-hub/repos/pushing-a-docker-container-image-to-docker-hub).
* You can also set up an access token. By using an access token, you can more easily grant and revoke access to your Docker Hub account without requiring a password change. For more information about access tokens and Docker Hub, see [Managing access tokens](https://docs.docker.com/docker-hub/access-tokens/).





 Deploying an app that references an image in a private registry with the console 

Deploy an application that uses an image in a private registry with the Code Engine console.

Before you can work with a Code Engine application that references an image in a private registry, you must first add access to the registry, pull the image, and then deploy it.



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.
Build fails when the build did not register correctly and a secret does not exist 

 What’s happening 

After you create and run a build, your build does not complete successfully and you receive a message that the build is not registered correctly and a secret does not exist.

 Why it’s happening 

If you receive a message that the build is not registered correctly and a secret does not exist, then the BUILD_NAME build was not correctly defined.

Example error message

The Build is not registered correctly, build: <BUILD_NAME>, registered status: False, reason: SpecSourceSecretNotFound|SpecOutputSecretRefNotFound|MultipleSecretRefNotFound

The BUILD_NAME build references a secret that does not exist. If the reason is SpecOutputSecretRefNotFound, then a registry secret does not exist. If it is SpecSourceSecretNotFound, then a secret to access the Git repository is missing. The reason is MultipleSecretRefNotFound if both secrets do not exist. Correct the build to reference existing secrets.

 How to fix it 

Try using the following information to resolve your problem.

Whether you are running your build in the console or in the CLI, use the CLI for troubleshooting problems with your build.



1. Run the ibmcloud ce buildrun get --name BUILDRUN_NAME command to display the details of your build run.
2. Review the Reason in the command output.



Take the following steps to help you resolve the problem with your build.



1. Check your secrets. In a build, secrets are used for the following purposes:



* To authenticate at the container registry. A registry secret stores credentials to access a container registry. To list all secrets in your project, including existing registry secrets, run the [ibmcloud ce secret list](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-list) command.
Why does the oc debug command fail with a container is unable to start error? 

 What’s happening 

When you run the oc debug command on a private cluster, you see an error message similar to the following.

oc debug node/<node-name>
Starting pod/1024104-debug ...
To use host binaries, run chroot /host

warning: Container container-00 is unable to start due to an error: Back-off pulling image "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:7dd7a3a1be7009629c709e6c88a1551d471aba9bf3deb873bc5f4d814675edfe"

 Why it’s happening 

The oc debug command starts a debug pod on the node that you specify. The debug pod uses a public container image from the quay.io container registry. On private clusters without access to the public Internet, your cluster can't pull the debug container image from the public registry.

 How to fix it 

To resolve this issue, pull an ocp-release image from quay.io and push it to your private image registry. Then, when you run the oc debug command, specify the private container image that you want to use.



1. Pull an image from [quay.io](https://quay.io/repository/openshift-release-dev/ocp-release?tab=tags) that matches your cluster version and architecture. For example, if you have a 4.7.19 cluster, pull the quay.io/openshift-release-dev/ocp-release:4.7.19-x86_64 image. Note that you must have a Red Hat account and permissions to pull images.

docker pull quay.io/openshift-release-dev/ocp-release:4.7.19-x86_64
2.
4. Select defaultProject, <image>ImageStreams, and <tag>Tag of the image stream that you previously created.
5. Review the rest of the application details, and click Create.









 Deploying containers from an IBM Cloud Container Registry image to the default Red Hat OpenShift project 

You can deploy containers to your cluster from an IBM-provided public image or a private image that is stored in your IBM Cloud Container Registry namespace. For more information about how your cluster accesses registry images, see [Understanding how your cluster is authorized to pull images from IBM Cloud Container Registry](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycluster_registry_auth).

Before you begin:



1. [Set up a namespace in IBM Cloud Container Registry and push images to this namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-startedgs_registry_namespace_add).
2. [Create a Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-clusters).
3. [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).



To deploy a container into the default project of your cluster:



1. Create a deployment configuration file that is named <deployment>.yaml.
2. Define the deployment and the image to use from your project in IBM Cloud Container Registry.

apiVersion: apps/v1
kind: Deployment
metadata:
name: <deployment>
spec:
replicas: <number_of_replicas>
selector:
matchLabels:
app: <app_name>
template:
metadata:
labels:
app: <app_name>
spec:
containers:
- name: <app_name>
image: <region>.icr.io/<project>/<image>:<tag>
Show more

<deployment>
With Stork, you can co-locate pods with their data, provides seamless migration of pods in case of storage errors and makes it easier to create and restore snapshots of Portworx volumes.

spec.containers.image
: The name of the image that you want to use. To list available images in your IBM Cloud Container Registry account, run ibmcloud cr image-list.

spec.containers.name
: The name of the container that you want to deploy to your cluster.

spec.containers.securityContext.fsGroup
: Optional: To access your storage with a non-root user, specify the [security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) for your pod and define the set of users that you want to grant access in the fsGroup section on your deployment YAML. For more information, see [Accessing Portworx volumes with a non-root user](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/create-pvcs/access-via-non-root-users/).

spec.containers.volumeMounts.mountPath
: The absolute path of the directory to where the volume is mounted inside the container. If you want to share a volume between different apps, you can specify [volume sub paths](https://kubernetes.io/docs/concepts/storage/volumes/using-subpath) for each of your apps.

spec.containers.volumeMounts.name
: The name of the volume to mount to your pod.

volumes.name
: The name of the volume to mount to your pod. Typically this name is the same as volumeMounts/name.

volumes.persistentVolumeClaim.claimName
: The name of the PVC that binds the PV that you want to use.
2. Create your deployment.

oc apply -f deployment.yaml
3. Verify that the PV is successfully mounted to your app.

oc describe deployment <deployment_name>
With Stork, you can co-locate pods with their data, provides seamless migration of pods in case of storage errors and makes it easier to create and restore snapshots of Portworx volumes.

spec.containers.image
: The name of the image that you want to use. To list available images in your IBM Cloud Container Registry account, run ibmcloud cr image-list.

spec.containers.name
: The name of the container that you want to deploy to your cluster.

spec.containers.securityContext.fsGroup
: Optional: To access your storage with a non-root user, specify the [security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) for your pod and define the set of users that you want to grant access in the fsGroup section on your deployment YAML. For more information, see [Accessing Portworx volumes with a non-root user](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/create-pvcs/access-via-non-root-users/).

spec.containers.volumeMounts.mountPath
: The absolute path of the directory to where the volume is mounted inside the container. If you want to share a volume between different apps, you can specify [volume sub paths](https://kubernetes.io/docs/concepts/storage/volumes/using-subpath) for each of your apps.

spec.containers.volumeMounts.name
: The name of the volume to mount to your pod.

volumes.name
: The name of the volume to mount to your pod. Typically this name is the same as volumeMounts/name.

volumes.persistentVolumeClaim.claimName
: The name of the PVC that binds the PV that you want to use.
2. Create your deployment.

kubectl apply -f deployment.yaml
3. Verify that the PV is successfully mounted to your app.

kubectl describe deployment <deployment_name>
The generated file is used to build a container image, push the image to the private container registry and deploy a new app using the private container image.



1. On a terminal, run the below command to clone the GitHub repository to your machine:

git clone https://github.com/IBM-Cloud/openshift-node-app
2. Change to the application directory,

cd openshift-node-app







 Update the BuildConfig and Push the builder image to Container Registry 

In this step, you will update the sections of openshift.template.yaml file to generate a new yaml file pointing to Container Registry namespace and push the generated container image to Container Registry.



1. Run the below bash script to update the placeholders in the openshift.template.yaml file and to generate openshift_private_registry.yaml file.

./generate_yaml.sh use_private_registry
2. Run the export command from the output to set the existing MYPROJECT environment variable with the new application name. Run echo $MYPROJECT to see the new application name.
3. Optionally, check the generated openshift_private_registry.yaml file to see if all the placeholders are updated with the respective environment variables. The below are 3 important places to do a quick check. You can skip to the next section.
4. Optional Locate the ImageStream object with the name attribute set to your project ($MYPROJECT) and check whether the placeholders $MYREGISTRY,$MYNAMESPACE, and $MYPROJECT under dockerImageRepository definition of spec are updated

-
apiVersion: image.openshift.io/v1
kind: ImageStream
metadata:
annotations:
openshift.io/generated-by: OpenShiftNewApp
creationTimestamp: null
labels:
app: $MYPROJECT
app.kubernetes.io/component: $MYPROJECT
app.kubernetes.io/instance: $MYPROJECT
name: $MYPROJECT
spec:
Building containers from images 

A Docker image is the basis for every container that you create with IBM Cloud® Kubernetes Service.

An image is created from a Dockerfile, which is a file that contains instructions to build the image. A Dockerfile might reference build artifacts in its instructions that are stored separately, such as an app, the app's configuration, and its dependencies.



 Deploying containers from an IBM Cloud Container Registry image to the default Kubernetes namespace 

You can deploy containers to your cluster from an IBM-provided public image or a private image that is stored in your IBM Cloud Container Registry namespace. For more information about how your cluster accesses registry images, see [Understanding how your cluster is authorized to pull images from IBM Cloud Container Registry](https://cloud.ibm.com/docs/containers?topic=containers-registrycluster_registry_auth).

Before you begin:



1. [Set up a namespace in IBM Cloud Container Registry and push images to this namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-startedgs_registry_namespace_add).
2. [Create a Kubernetes cluster](https://cloud.ibm.com/docs/containers?topic=containers-clusters).
3. [Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)



To deploy a container into the default namespace of your cluster:



1. Create a deployment configuration file that is named <deployment>.yaml.
2. Define the deployment and the image to use from your namespace in IBM Cloud Container Registry.

apiVersion: apps/v1
kind: Deployment
metadata:
name: <deployment>
spec:
replicas: <number_of_replicas>
selector:
matchLabels:
app: <app_name>
template:
metadata:
labels:
app: <app_name>
Run 'ibmcloud ce buildrun logs -f -n helloworld-buildrun-private2' to follow the logs of the build run.
OK

Name: helloworld-buildrun-private2
ID: abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f
Project Name: myproject
Project ID: 01234567-abcd-abcd-abcd-abcdabcd1111
Age: 2d10h
Created: 2022-06-08T06:11:05-05:00
Build Type: git

Summary: Succeeded
Status: Succeeded
Reason: All Steps have completed executing
Source:
Commit Branch: main
Commit SHA: 946dd18f6e5a5474336786bc28d7dda93aec49c1
Commit Author: COMMIT_AUTHOR
Image Digest: sha256:39c4a87bc43102c2ee88562072c57c135b8dcc5cc4a1104e1d782fe3acc5d5b6

Image: us.icr.io/mynamespace/codeengine-helloworld
Registry Secret: myregistry
Build Strategy: buildpacks-v3-medium
Timeout: 10m0s
Source: git@github.com:myprivaterepo/builds.git
Context Directory: /hello
Repo Secret: myrepossh









 Running a single build that pulls source from a local directory 

If your source is on your local workstation, and you want to use a single command to build and output a container image, then use the buildrun submit command to create the container image without creating a reusable build configuration.

For the build output, you can choose automatic access and 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.
* [Storing images in the internal registries](https://cloud.ibm.com/docs/openshift?topic=openshift-registryopenshift_internal_registry)



* [Backing up your internal image registry to IBM Cloud Object Storage](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycos_image_registry)
* [Storing images in the internal registry in Classic clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-registrystorage_internal_registry)
* [Storing images in the worker node empty directory](https://cloud.ibm.com/docs/openshift?topic=openshift-registryemptydir_internal_registry)



* [Removing the internal image registry](https://cloud.ibm.com/docs/openshift?topic=openshift-registryremove-image-registry)
* [Setting up a secure external route for the internal registry](https://cloud.ibm.com/docs/openshift?topic=openshift-registryroute_internal_registry)
* [Importing images from IBM Cloud Container Registry into the internal registry image stream](https://cloud.ibm.com/docs/openshift?topic=openshift-registryimagestream_registry)
* [Setting up builds in the internal registry to push images to IBM Cloud Container Registry](https://cloud.ibm.com/docs/openshift?topic=openshift-registrybuilds_registry)
* [Using IBM Cloud Container Registry](https://cloud.ibm.com/docs/openshift?topic=openshift-registryopenshift_iccr)
* [Understanding how to authorize your cluster to pull images from a private registry](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycluster_registry_auth)
Refer to the Terraform documentation for [provider naming and namespaces](https://developer.hashicorp.com/terraform/language/providers/requirementsnames-and-addresses). This is an optional variable. If not specified it is defaulted to all providers in all namespaces "/".



Schematics auto generates the following Terraform CLI configuration file parameters which tell Terraform during job execution to use an alternate registry for some or all of the providers you intend to use.

provider_installation {
network_mirror {
url = "${TF_NETWORK_MIRROR_URL}"
include = ["${TF_NETWORK_MIRROR_PROVIDER_NAME}"]
}
direct {
exclude = ["TF_NETWORK_MIRROR_PROVIDER_NAME"]
}
}





 How do I set the credentials to access a private provider registry 

When interacting with private registries, Terraform must be configured with the access tokens for the target registry. With Agents these are defined at a workspace level using the TF_TOKEN_ environment variable. See the Terraform [Environment Variable Credentials](https://developer.hashicorp.com/terraform/cli/config/config-fileenvironment-variable-credentials) documentation for more detail on configuring this variable.





 Using Artifactory as a provider registry 

[Artifactory](https://jfrog.com/artifactory/) provides a number of different options for sourcing of Terraform providers and fully supports the [Terraform provider registry protocol](https://developer.hashicorp.com/terraform/internals/provider-registry-protocol). It supports, remote, local and virtual repositories which aggregate the first two types with a defined search order.

Local repositories are physical, user managed local repositories acting as a Terraform private registry where you can host custom developed providers and manually upload and save public providers to eliminate the need for public network access. Or limit the public providers made available to Terraform users.
Why does my app fail when a non-root user owns the NFS file storage mount path? 

Classic infrastructure

 What’s happening 

After you [add NFS storage](https://cloud.ibm.com/docs/containers?topic=containers-file_storagefile_app_volume_mount) to your deployment, the deployment of your container fails. When you retrieve the logs for your container, you might see errors such as the following. The pod fails and is stuck in a reload cycle.

write-permission

don't have required permission

can't create directory '/bitnami/mariadb/data': Permission denied

 Why it’s happening 

By default, non-root users don't have write permission on the volume mount path for NFS-backed storage. Some common app images, such as Jenkins and Nexus3, specify a non-root user that owns the mount path in the Dockerfile.

When you create a container from this Dockerfile, the creation of the container fails due to insufficient permissions of the non-root user on the mount path. To grant write permission, you can modify the Dockerfile to temporarily add the non-root user to the root user group before it changes the mount path permissions, or use an init container.

If you use a Helm chart to deploy the image, edit the Helm deployment to use an init container.

 How to fix it 

When you include an [init container](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) in your deployment, you can give a non-root user that is specified in your Dockerfile write permissions for the volume mount path inside the container.

The init container starts before your app container starts. The init container creates the volume mount path inside the container, changes the mount path to be owned by the correct (non-root) user, and closes. Then, your app container starts with the non-root user that must write to the mount path. Because the path is already owned by the non-root user, writing to the mount path is successful.