vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For more information about IBM Cloud Container Registry namespaces, see [Registry namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_namespace). For more information about Kubernetes namespaces, see [Namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/).



1. In your cluster, create a Kubernetes namespace called test:

kubectl create namespace test
2. To deploy your deployment and service into this Kubernetes namespace, in the hello-world.yaml file change the metadata.namespace fields for both the deployment and the service from default to test. This snippet shows the metadata.namespace field in context:

metadata:
name: hello-world
namespace: test
3. Apply the configuration.



1. Apply the configuration with Portieris that is still enabled in your cluster by running the following command:

kubectl apply -f hello-world.yaml

Because Portieris is still enabled in your cluster, your deployment fails immediately, and you see the following message:

Error from server: error when creating "hello-world.yaml": admission webhook
"va.hooks.securityenforcement.admission.cloud.ibm.com" denied the request:
Deny "us.icr.io/<my_namespace>/hello-world:2", no valid ImagePullSecret defined for us.icr.io

This error is because Portieris determines that this deployment can't succeed because the test namespace is unable to pull images from your IBM Cloud Container Registry namespace. The default Kubernetes namespace in an IBM Cloud Kubernetes Service cluster comes preconfigured with [image pull secrets](https://cloud.ibm.com/docs/containers?topic=containers-registrycluster_registry_auth) to pull images from IBM Cloud Container Registry. However, these secrets aren't present in your new namespace.
2.
Define the namespace that you want your resources to be deployed to. This must be an existing namespace.
3. Specify the branch to deploy the resource to; for example, v1.
4. Provide the path to deploy the resource to; for example, deployments.
5. Select the cluster group to receive the resources that you are deploying.
6. Provide the displayed name of the Satellite configuration.
7. Click Continue.







 Step 7: Reviewing the summary 

Review the summary and confirm to create your toolchain.



* To change any parameters you provided earlier, click Back.
* To create the toolchain with the provided parameters, click Create toolchain.







 Step 8: Testing the toolchain 

When the toolchain is created, the toolchain Overview page is displayed. On this page, you can view the repositories, pipelines, and any IBM Cloud tools that are associated with this toolchain.

Under Repositories is your source repository as well as additional repositories for your Tekton catalog and pipeline tasks. If you are comfortable with using Tekton, you can go to these Tekton repositories to make changes to your toolchain.

Under Delivery pipelines, you can see the status of your pipeline runs. You can click the name of the pipeline to see details about your pipeline and set From this pipeline overview, you can set the triggers for your pipeline. Triggers define when the pipeline starts.

You can start the delivery pipeline in either of the following ways.



* Trigger the delivery pipeline manually by setting a manual trigger.
* Push a commit to the deployment source repo as defined by a Git repository trigger. To set a Git repository trigger, see [Deploying a new version of your app from a different branch](https://cloud.ibm.com/docs/satellite?topic=satellite-sat_toolchain_tutorialmodify_trigger).



To start a manual pipeline run, follow these steps.



1. On the Overview of your toolchain under Delivery pipelines, select the delivery pipeline to view its status.
2. Click Run pipeline.
Cloud Functions actions, triggers, and rules belong in a namespace, and sometimes a package.

Packages can contain actions and feeds. A package cannot contain another package, so package nesting is not allowed. Also, entities do not have to be contained in a package.

You can create new IAM-based namespaces by running ibmcloud fn namespace create. Cloud Foundry-based namespaces are made from a combination of an org and space name. For example, if you are targeted to the user@email.com org and the dev space, then you are targeting the Cloud Functions Cloud Foundry-based namespace called user@email.com_dev.

The /whisk.system namespace is reserved for entities that are distributed with the Cloud Functions system.

The [Serverless Framework](https://www.serverless.com/) is not supported for IAM-based namespaces.





 Fully qualified names in Cloud Functions 

The fully qualified name of an entity is /<namespace_id>/<package_name>/<entity_name>. Notice that / is used to delimit Cloud Foundry-based namespaces, packages, and entities. Also, when you work in the CLI, some commands with namespaces must be prefixed with a /.

For convenience, the namespace can be omitted if it is the user's default namespace. For example, consider a user whose default namespace is /myOrg. Following are examples of the fully qualified names of a number of entities and their aliases.



Table 4. Fully qualified names and their aliases

 Fully qualified name Alias Namespace Package Name 

 /whisk.system/cloudant/read /whisk.system cloudant read 
 /myOrg/video/transcode video/transcode /myOrg video transcode 
 /myOrg/filter filter /myOrg filter 



You can use this naming scheme when you use the Cloud Functions CLI, among other places.

More precisely, a name must match the following regular expression (expressed with Java meta character syntax): A([w]|[w][w@.-]+)z.







 Action semantics 

The following sections describe details about Cloud Functions actions.
If this is the case, click on Kubernetes dashboard and a new browser tab opens (Kubernetes dashboard).
2. In the top left, find the namespace selector and switch to All namespaces.
3. On the upper right, click on + to create a new resource. Paste the following content into the text form Create from input.

apiVersion: v1
kind: Namespace
metadata:
name: tptest
labels:
name: tptest
---
apiVersion: v1
kind: Service
metadata:
name: trustedprofile-test
namespace: tptest
spec:
ports:
- port: 8080
targetPort: 8080
protocol: TCP
type: ClusterIP
selector:
app: tptest
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: trustedprofile-test-deployment
namespace: tptest
spec:
selector:
matchLabels:
app: tptest
replicas: 1
template:
metadata:
labels:
app: tptest
spec:
containers:
- name: tptest-container
image: icr.io/solution-tutorials/tutorial-trusted-profile-enterprise-security:v1.0.2
imagePullPolicy: Always
ports:
- containerPort: 8080
volumeMounts:
- mountPath: /var/run/secrets/tokens
name: sa-token
serviceAccountName: default
volumes:
- name: sa-token
projected:
sources:
- serviceAccountToken:
path: sa-token
expirationSeconds: 3600
audience: iam
Show more

Then, click Upload to create the resources for the app. It includes a new Kubernetes namespace tptest, a deployment and a service with a pod.
: The name or ID for a namespace.

--paramKEYVALUE, -pKEYVALUE
: Parameter VALUES in the KEYVALUE format. This flag is optional.

--param-fileFILE, -PFILE
: A JSON file that contains parameter KEYS and VALUES. This flag is optional.

--preview
: Display the result of the command without running the command.

--project PATH
: The path to the serverless project. The default is . (current directory).

--strict
: Allow a user-defined runtime version.

--verbose, -v
: View verbose output.





 Example 

ibmcloud fn undeploy --manifest folder/manifest.yaml









 List command 

Use the list command to view packages, actions, triggers, and rules in the namespace.



 ibmcloud fn list 

View a grouped list of the packages, actions, triggers, and rules in the namespace.

ibmcloud fn list [--name-sort]



 Command options 

--name-sort, -n
: Sort each group of returned entities by name, otherwise each group is sorted by creation date.





 Example 

ibmcloud fn list









 Namespace commands 

Create, update, delete, and find information about your namespace.

To learn how to target your Cloud Functions namespace, see [Targeting namespaces](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-namespacestargeting-namespaces).

To see CLI help for the namespace command, run ibmcloud fn namespace.



 ibmcloud fn namespace create 

Create an IAM namespace.

ibmcloud fn namespace create NAMESPACE [--description DESCRIPTION]



 Command options 

NAMESPACE
: The name for a namespace. Do not include hyphens (-) in the name. This value is required.

--description DESCRIPTION, -n DESCRIPTION
: Write your own unique description to help you identify the namespace.
: Every cluster is set up with a set of default Kubernetes namespaces that include the deployments and services that are required for IBM Cloud Kubernetes Service to run properly and manage the cluster. For more information, see the [service architecture](https://cloud.ibm.com/docs/containers?topic=containers-service-arch).
: Cluster administrators automatically have access to these namespaces and can set up additional namespaces in the cluster.

For every namespace that you have in the cluster, make sure to set up proper [RBAC policies](https://cloud.ibm.com/docs/containers?topic=containers-usersrbac) to limit access to this namespace, control what gets deployed, and to set proper [resource quotas](https://kubernetes.io/docs/concepts/policy/resource-quotas/) and [limit ranges](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/).



 Should I set up a single-tenant or a multi-tenant cluster? 

In a single-tenant cluster, you create one cluster for every group of people that must run workloads in a cluster. Usually, this team is responsible to manage the cluster and to properly configure and secure it. Multi-tenant clusters use multiple namespaces to isolate tenants and their workloads.

Zoom

![Deciding between a single tenant or a multi-tenant cluster.](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/cs_single_multitenant.png)

Figure 1. Single tenant versus multi-tenant cluster

Deciding between single-tenant and multi-tenant clusters depends on the number of teams that must run workloads in a cluster, their service requirements, the size of the service, and the level of isolation that you want to achieve for your workloads.
: Exclude a specified number of the most recently created namespaces from the result. This flag is optional.





 Example 

ibmcloud fn namespace list







 ibmcloud fn namespace target 

Target an available IAM or Cloud Foundry namespace.

ibmcloud fn namespace target NAMESPACE



 Command options 

NAMESPACE
: The name or ID for a namespace. This value is required.





 Example 

ibmcloud fn namespace target HBCTeamProd







 ibmcloud fn namespace update 

Change the name or description of an IAM namespace.

ibmcloud fn namespace update NAMESPACE [NEW_NAMESPACE_NAME] [--description DESCRIPTION]



 Command options 

NAMESPACE
: The name for a namespace. Do not include hyphens (-) in the name. This value is required.

NAMESPACE_NAME
: The new name for a namespace. Do not include hyphens (-) in the name. This value is optional.

--description DESCRIPTION, -n DESCRIPTION
: Write your own unique description to help you identify the namespace. If your description is more than one word, include quotation marks (") around your description. This flag is optional.





 Example 

ibmcloud fn namespace update HBCTeamProd HBCTeamStaging









 Package commands 

Create, update, delete, bind, and find information about packages.

To see CLI help for the package command, run ibmcloud fn package.



 ibmcloud fn package bind 

Bind parameters to a package. All the actions within the package inherit those parameters unless otherwise specified.

ibmcloud fn package bind PACKAGE_NAME BOUND_PACKAGE_NAME [--annotation ANNOTATION_KEY ANNOTATION_VALUE] [--annotation-file FILE] [--param KEY VALUE] [--param-file FILE]



 Command options 

PACKAGE_NAME
: The name of the package. This value is required.

BOUND_PACKAGE_NAME
: The name of the package binding. This value is required.
From the location where the sample app is running, select namespace.

Zoom

![Kubernetes namespace](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/ds_kub_misc_namespace.png)

Figure 15. Kubernetes namespace
5. Delete the related deployments, services, and ingresses that are listed within the selected namespace.







 Looking for help? 

Get help from the IBM Cloud® Continuous Delivery development teams by joining us on [Slack](https://ic-devops-slack-invite.us-south.devops.cloud.ibm.com/).

For more support options, see [Getting help and support for Continuous Delivery](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-gettinghelp).
Replace <namespace> with the namespace that can access the VPN and <remote.subnet> with the remote.subnet that you specified in the Helm values.yaml configuration file. To specify multiple namespaces or remote subnets, see the [Calico documentation](https://docs.tigera.io/calico/latest/reference/resources/globalnetworkpolicy).

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: allow-vpn-from-namespace
spec:
selector: projectcalico.org/namespace == "<namespace>"
egress:
  - action: Allow
destination:
nets:
- <remote.subnet>
order: 900
types:
- Egress
4. Apply the policy.

calicoctl apply -f allow-vpn-from-namespace.yaml --config=filepath/calicoctl.cfg
5. Verify that the global network policies are created in your cluster.

calicoctl get GlobalNetworkPolicy -o wide --config=filepath/calicoctl.cfg







 Limiting strongSwan VPN traffic by worker node 

When you have multiple strongSwan VPN deployments in a multi-tenant cluster, you can limit VPN traffic for each deployment to specific worker nodes that are dedicated to each tenant.

When you deploy a strongSwan Helm chart, a strongSwan VPN deployment is created. The strongSwan VPN pods are deployed to any untainted worker nodes. Additionally, a Kubernetes daemon set is created. This daemon set automatically configures routes on all untainted worker nodes in the cluster to each of the remote subnets. The strongSwan VPN pod uses the routes on worker nodes to forward requests to the remote subnet in the on-premises network.

Routes are not configured on tainted nodes unless you specify the taint in the tolerations setting in the value.yaml file.
Managing namespaces 

With IBM Cloud® Functions, you can create Identity and Access (IAM) managed namespaces to group entities, such as actions or triggers, together. Then, you can create IAM access policies for the namespace. For an overview of IAM, see the [Cloud Functions IAM-enablement announcement blog](https://www.ibm.com/cloud/blog/ibm-cloud-functions-is-now-identity-and-access-management-enabled).



 What is a namespace? 

Namespaces contain Cloud Functions entities, such as actions and triggers, and belong to a resource group. You can let users access your entities by granting them access to the namespace.

The fully qualified name of an entity is /<namespace_ID>/<package_name>/<entity_name>.



 What happens when I create a namespace? 

Namespaces that are created within Cloud Functions are identified as an IAM service instance. When you create a namespace, you can specify the [resource group](https://cloud.ibm.com/docs/account?topic=account-rgs) in which to add the service instance.

When you create a namespace, the following components are created:



Table 1. Components of a namespace

 Component Description 

 Service ID You can use the service ID as a functional ID when you make outbound calls. All the actions that are created in this namespace can use this service ID for access to other resources. The functional user gets the Reader role by default. Reader access means it can read namespace entities and invoke actions. The Reader role is used by triggers to invoke actions. To control inbound traffic, you might want to grant access to other users such as assigning Reader role to invoke actions. 
 API key An API Key for the service ID that can be used to generate IAM tokens. You can use the tokens to authenticate the namespace with other IBM Cloud services. The API key is provided to actions as the environment variable __OW_IAM_NAMESPACE_API_KEY. 



You can view a list of your service IDs by running the following command.
Set the variable accordingly:

MYCONTAINERREGISTRY=<us.icr.io_like_value_returned_from_ibmcloud_cr_info>

Set the variable to a name you want to used as a new namespace:

MYNAMESPACE=<my_container_registry_namespace>
5. Create a namespace to store the container image. Feel free to skip this step and use an existing namespace.

ibmcloud cr namespace-add $MYNAMESPACE
6. Build a Docker image using the [Dockerfile](https://github.com/IBM-Cloud/cdn-with-cda-todolist/blob/master/Dockerfile) in Container Registry and use cdn-with-cda-todolist as the image name:

docker build -t $MYCONTAINERREGISTRY/$MYNAMESPACE/cdn-with-cda-todolist:latest .
7. Log in Container Registry:

ibmcloud cr login
8. Push the image to Container Registry:

docker push $MYCONTAINERREGISTRY/$MYNAMESPACE/cdn-with-cda-todolist:latest







 Run the application in the cluster 



1. Run the command below to target the cluster where to deploy the application.

ibmcloud ks cluster config --cluster $MYCLUSTER
2. Retrieve the cluster ingress subdomain and secret name:

ibmcloud ks cluster get --cluster $MYCLUSTER
3. Copy deployment.sample.yaml to deployment.yaml:

cp deployment.sample.yaml deployment.yaml
4. Edit deployment.yaml and replace the placeholders <image>, <ingress-subdomain> and <ingress-secret> with values matching your environment.
5. Deploy the application to the cluster:

kubectl apply -f deployment.yaml
6. Access the application at https://cdn-with-cda-todolist.<ingress-subdomain>
To create a namespace

kubectl create namespace <namespace_name>
2. List the existing image pull secrets in the default Kubernetes namespace for IBM Cloud Container Registry.

kubectl get secrets -n default | grep icr-io

Example output

all-icr-io          kubernetes.io/dockerconfigjson        1         16d
3. Copy the all-icr-io image pull secret from the default namespace to the namespace of your choice. The new image pull secrets are named <namespace_name>-icr-<region>-io.

kubectl get secret all-icr-io -n default -o yaml | sed 's/default/<new-namespace>/g' | kubectl create -n <new-namespace> -f -
4. Verify that the secrets are created successfully.

kubectl get secrets -n <namespace_name> | grep icr-io
5. To deploy containers, [add the image pull secret](https://cloud.ibm.com/docs/containers?topic=containers-registryuse_imagePullSecret) to each deployment or to the service account of the namespace so that any deployment in the namespace can pull images from the registry.







 Creating an image pull secret with different IAM API key credentials 

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 an image pull secret for your cluster.

For example, to access images in other IBM Cloud accounts, create an API key that stores the IBM Cloud Container Registry credentials of a user or service ID in that account. Then, in your cluster's account, save the API key credentials in an image pull secret for each cluster and cluster namespace.

The following steps create an API key that stores the credentials of an IBM Cloud IAM service ID.
* [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).
* [Make sure that you can run Docker commands without root permissions](https://docs.docker.com/engine/install/linux-postinstall/). If your Docker client is set up to require root permissions, you must run ibmcloud login, ibmcloud cr login, docker pull, and docker push commands with sudo.

If you change your permissions to run Docker commands without root privileges, you must run the ibmcloud login command again.



A Docker image is the basis for every container that you create. 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 configuration of the app, and its dependencies.

If you want to take advantage of IBM Cloud compute resources and internet connection or Docker is not installed on your workstation, build your image directly in IBM Cloud. If you need to access resources in your build that are on servers that are behind your firewall, build your image locally.

To build your own Docker image, complete the following steps:



1. Create a local directory where you want to store the build context. The build context contains your Dockerfile and related build artifacts, such as the app code. Navigate to this directory in a command-line window.
2. Create a Dockerfile.



1. Create a Dockerfile in your local directory.

touch Dockerfile
2. Use a text editor to open the Dockerfile.
Setting up Ingress 

Create an Ingress resource to configure your Ingress components, define rules for routing requests, and specify the path to your app services. A separate Ingress resource is required for each namespace that contains an app or service that you want to expose.



 Before you begin 

Follow these preparation steps before you begin.



1. Make sure that you have the correct permissions to set up Ingress. The following [IBM Cloud IAM roles](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms) are required:



* Administrator platform access role for the cluster
* Manager service access role in all namespaces



2. Determine whether you want to use the IBM-provided Ingress subdomain. If you do not want to use the provided subdomain, you must create and register your own [custom domain](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-setupingress-custom-domain).

A custom domain is required to expose apps over private ALBs.
3. If you are exposing apps over private ALBs, you must enable each private ALB in the CLI. To get the ALB ID, run ibmcloud ks ingress alb ls --cluster CLUSTER.

Classic clusters

For more information and command options, see the [CLI reference](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_alb_configure).

ibmcloud ks ingress alb enable classic --alb <alb_id> --cluster <cluster_name>

VPC clusters

For more information and command options, see the [CLI reference](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicli_alb_configure_vpc_gen2).

ibmcloud ks ingress alb enable vpc-gen2 --alb <alb_id> --cluster <cluster_name>
4.