Removing a local image is done with the rmi command, which stands for remove image. The tag command would just create or update a tag for an existing image, not delete it. OpenShift’s oc rmi isn’t the standard way to remove a local image, and docker rmi would apply only if you’re using Docker instead of Podman. Using podman rmi devops/mysql:snapshot removes the specified image from the local image store (assuming no containers are using it, or you use a force option). So the command shown is the correct way to remove a local image.

ExternalName services route to an external DNS name instead of a cluster IP. You create one by specifying the service type as externalname and providing the external host with the --external-name flag. The command that fits this pattern is oc create service externalname --external-name . It uses the correct resource type and the correct flag to point to the external host. The other options fail because they either use a different service type (like clusterip), or use incorrect capitalization for the resource type or the flag, or supply a less appropriate external name.

OpenShift uses the new-app flow to generate resources from an image source, and the flag that forces the result to be a DeploymentConfig ensures that the created object runs as a DeploymentConfig rather than a Deployment. By pointing to a shared image stream with the image spec shared/myis and explicitly requesting a DeploymentConfig, the command builds a DeploymentConfig whose pod template uses the image from that shared image stream. This combination is the direct, unambiguous way to create a DeploymentConfig from a shared image stream in one step.

Cross-project image sharing in OpenShift relies on RBAC to grant pull rights. To let workloads in the consuming project pull a private image from the image stream in the source project, you grant the system:image-puller role to the consuming project’s service accounts for the source image stream’s namespace. This permission is what enables the actual pull of the image across projects, and it must be in place before any pod can start using the image. Creating a secret for a regtoken isn’t needed for internal OpenShift image streams, switching projects isn’t required to grant the access, and importing the image into the target project would duplicate the image rather than enable ongoing cross-project access. So, granting pull access to the consuming project’s service accounts is the correct first step.