vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* [Step 2: Review namespace permissions](https://cloud.ibm.com/docs/containers?topic=containers-pod-security-admission-migrationpsa-migration-namespace-perm)
* [Step 3: Simplify and standardize PSPs](https://cloud.ibm.com/docs/containers?topic=containers-pod-security-admission-migrationpsa-migration-simplify)
* [Step 4: Update the namespaces in your cluster](https://cloud.ibm.com/docs/containers?topic=containers-pod-security-admission-migrationpsa-migration-update-namespace)
* [Step 5: Review the namespace creation process](https://cloud.ibm.com/docs/containers?topic=containers-pod-security-admission-migrationpsa-migration-namespace-creation)
* [Step 6: Optional. Disable the PSP feature in the cluster](https://cloud.ibm.com/docs/containers?topic=containers-pod-security-admission-migrationpsa-migration-disable-psp)
* [Step 7: Optional. Upgrade your cluster](https://cloud.ibm.com/docs/containers?topic=containers-pod-security-admission-migrationpsa-migration-cluster-upgrade)



* [References](https://cloud.ibm.com/docs/containers?topic=containers-pod-security-admission-migrationpsa-migration-references)







 Securing the cluster network 



 Controlling traffic in Classic clusters 

[Using Calico network policies to control traffic on Classic clusters](https://cloud.ibm.com/docs/containers?topic=containers-policy_tutorialpolicy_tutorial)



* [Objectives](https://cloud.ibm.com/docs/containers?topic=containers-policy_tutorialpolicies_objectives)
* [Audience](https://cloud.ibm.com/docs/containers?topic=containers-policy_tutorialpolicies_audience)
For more information, see [Setting up access to classic infrastructure](https://cloud.ibm.com/docs/vpc?topic=vpc-setting-up-access-to-classic-infrastructure).





 Next steps 

To get started using the API and CLI, [set up your environment](https://cloud.ibm.com/docs/vpc?topic=vpc-set-up-environment). To learn how to create VPC resources, see these tutorials:



* [Using the IBM Cloud console to create VPC resources](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-using-the-ibm-cloud-console)
* [Creating VPC resources with CLI and API](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-vpc-resources-with-cli-and-api&interface=cli)



For a list of features not yet supported in VPC, see [Limitations](https://cloud.ibm.com/docs/vpc?topic=vpc-limitations).
[Enable spaces](https://www.ibm.com/support/knowledgecenter/SSMNED_v10cloud/com.ibm.apic.apionprem.doc/tapic_syndication_spaces_enable.html)
2. [Create a space](https://www.ibm.com/support/knowledgecenter/SSMNED_v10cloud/com.ibm.apic.apionprem.doc/tapic_syndication_spaces_manage.html)
3. [Add users to the space](https://www.ibm.com/support/knowledgecenter/SSMNED_v10cloud/com.ibm.apic.apionprem.doc/tapic_syndication_spaces_members_manage.html)











 Configuring OAuth providers for APIs 

Secure access to your organization's APIs by configuring an OAuth provider. When a customer's application calls your API, the app must obtain a token from the OAuth provider and pass it to API Connect to prove that it has authorization to use the API. For information on working with OAuth, see the following topics in the extended V10 Reserved documentation:



* [OAuth concepts](https://www.ibm.com/support/knowledgecenter/SSMNED_v10cloud/com.ibm.apic.apionprem.doc/con_apionprem_authentication.html)
* [Creating a native OAuth provider](https://www.ibm.com/support/knowledgecenter/SSMNED_v10cloud/com.ibm.apic.apionprem.doc/oauth_native_apim.html)
* [Creating a third-party OAuth provider](https://www.ibm.com/support/knowledgecenter/SSMNED_v10cloud/com.ibm.apic.apionprem.doc/oauth_thirdparty_apim.html)







 Managing product lifecycles 

A product is a set of APIs and the plans that specify usage rules such as rate limits.
The scope can be the account, [namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_namespace), [repository](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_repository), [digest](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_digest), or [tag](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_tag).

You can identify the images in the scope by using either the tag or the digest. You can reference the image by digest <dns>/<namespace>/<repo>@<digest>, which affects the digest and all its tags in the same repository, or by tag <dns>/<namespace>/<repo>:<tag>. Where <dns> is the domain name, <namespace> is the namespace, <repo> is the repository, <digest> is the digest, and <tag> is the tag. To list all images, including [untagged](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_untagged) images, run the [ibmcloud cr image-digests](https://cloud.ibm.com/docs/cli?topic=cli-containerregclibx_cr_image_digests) command.

ibmcloud cr exemption-add --scope SCOPE --issue-type ISSUE_TYPE --issue-id ISSUE_ID



 Prerequisites 

To find out about the required permissions, see [Access roles for configuring Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-iamaccess_roles_configure).





 Command options 

--scope SCOPE
: To set your account as the scope, use "" as the value.
Why can't I find my image or my namespace? 

Your image or your namespace is missing in IBM Cloud® Container Registry.

  What’s happening 

When you try to find your image or your namespace, you can't find it.

  Why it’s happening 

The following alternatives are possible causes:



*  You are looking in the wrong region. Namespaces are region specific and you might be targeting the wrong region.
*  The image or namespace was deleted.



  How to fix it 

You can fix this problem in the following ways:



*  Check that you're using the correct region. To change the region, see [Regions](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewregistry_regions).
*  Check your instance of IBM Cloud Activity Tracker to see whether the image or namespace was deleted. For more information, see [Auditing events for Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-at_events).
Access Schematics > Workspaces > [Workspace](https://cloud.ibm.com/schematics/workspaces).
3. Search your workspace in specific location.
4. Click Workspaces > [workspace](https://cloud.ibm.com/schematics/workspaces).
5. Click Apply plan to provision the configured resources.





 Verifying workspace apply 



1. Click your workspace that is listed in the [IBM Cloud console](https://cloud.ibm.com/schematics/workspaces) to view the results of the workspace apply job.









 Perform a workspace apply using the CLI 



1. Create a JSON file on your system to pass the parameters to Schematics to run the workspace apply. For more information about configuration options, see [ibmcloud schematics workspace new](https://cloud.ibm.com/docs/schematics?topic=schematics-schematics-cli-referenceschematics-workspace-new) command.

Example

{
"name": "testwspace31jan",
"type": [
"terraform_v1.0"
],
"description": "terraform workspace",
"location": "us-east",
"tags": [
"department:HR",
"application:compensation",
"environment:production"
],
"template_repo": {
"url": "https://github.com/Anil-CM/newrepo"
},
"workspace_status": {
"frozen": true
},
"template_data": [{
"folder": ".",
"type": "terraform_v1.0",
"variablestore": {
"name": "sample_var",
"secure": true,
"value": "THIS IS IBM CLOUD TERRAFORM CLI DEMO",
* Enter a name for the workspace or use the default.
* The Resource Group to use to create resources. Use the Default or create a Resource Group.
* Select a Location to create your Schematics workspace. The workspace location does not have to match the resource location.



3. Enter the required deployment values, review the default input variables, and provide values that match your solution. These parameters are specific to your deployment. For more detailed information, see the [Readme file](https://cloud.ibm.com/catalog/content/sapsingletierdb2-20099bf4-f33a-4ce6-a48b-6d8cb1ac7a27-global/readme/terraform/terraform/e4ec2c13-cf6d-435a-8513-55d6232d5283-global).



 Parameter Description 

 BASTION_FLOATING_IP Input the floating IP of the Bastion Server you created before you started this deployment. For more information, see [Automate SAP bastion server - SAP media storage](https://cloud.ibm.com/docs/sap?topic=sap-sap-bastion-server) 
 HOSTNAME VSI hostname 
 REGION Cloud Region where resources are deployed 
 RESOURCE_GROUP EXISTING Resource Group for VSIs and Volumes 
 SECURITY_GROUP EXISTING Security group name 
 SSH_KEYS SSH Keys ID list to access the VSI 
 SUBNET EXISTING Subnet name 
 VPC EXISTING VPC name 
 ZONE Cloud Zone where resources are deployed 
 ibmcloud_api_key IBM Cloud API key or use a secret that is stored in Secrets Manager 
 private_ssh_key Input id_rsa private key content or use a secret that is stored in Secrets Manager 
 sap_main_password SAP main password or use a secret that is stored in Secrets Manager 



4. Review and update the optional parameters. The Ansible scripts expect the SAP kits to be in the default locations listed.
The following scenario demonstrates how to manage traffic between app microservices across multiple namespaces.

Services that are owned by different sub teams need to communicate, but the services are deployed in different namespaces within the same cluster. The Accounts team deploys front end, back end, and database services for the app Srv1 in the accounts namespace. The Finance team deploys front end, back end, and database services for the app Srv2 in the finance namespace. Both teams label each service with the app: Srv1 or app: Srv2 label and the tier: frontend, tier: backend, or tier: db label. They also label the namespaces with the usage: accounts or usage: finance label.

Zoom

![Use a network policy to manage cross-namepspace traffic.](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/cs_network_policy_multi_ns.png)

Figure 2. Use a network policy to manage cross-namespace traffic

The Finance team's Srv2 needs to call information from the Accounts team's Srv1 back end. So the Accounts team creates a Kubernetes network policy that uses labels to allow all traffic from the finance namespace to the Srv1 back end in the accounts namespace. The team also specifies the port 3111 to isolate access through that port only.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
Namespace: accounts
name: accounts-allow
spec:
podSelector:
matchLabels:
app: Srv1
Tier: backend
ingress:
- from:
- NamespaceSelector:
matchLabels:
usage: finance
ports:
port: 3111
Show more

The spec.podSelector.matchLabels section lists the labels for the Srv1 back-end service so that the policy applies only to those pods.
ibmcloud resource service-instance-create ghstatsAppID appid graduated-tier $REGION
5. Add a new namespace ghstats to the IBM Cloud® Container Registry. You are going to use it for referencing container images. There is one global registry as well as regional registries. Use the global registry.

ibmcloud cr region-set global
NAMESPACE=ghstatsYourInitials
ibmcloud cr namespace-add $NAMESPACE







 Step 2: Code Engine preparation (shell) 

With the services provisioned and the general setup done, next is to create the Code Engine project, create a container image for the app and to deploy it.



1. Create a Code Engine project named ghstats. The command automatically sets it as the current Code Engine context.

ibmcloud ce project create --name ghstats
2. Create a Code Engine build configuration, i.e., set up the project to build the container image for you. It takes the code from the [GitHub repository for this tutorial](https://github.com/IBM-Cloud/github-traffic-stats) and stores the image in the registry in the previously created namespace using the registered user information.

ibmcloud ce build create --name ghstats-build --source https://github.com/IBM-Cloud/github-traffic-stats --context-dir /backend --commit master --image private.icr.io/$NAMESPACE/codeengine-ghstats
3. Notice the build create command had the side effect of creating a registry access secret that will allow the project to write and read the IBM Cloud® Container Registry.

ibmcloud ce registry list
4. Next, run the actual build process.

ibmcloud ce buildrun submit --build ghstats-build

The output indicates more commands to run to follow the status logs of the build as it progresses. Something like:

ibmcloud ce buildrun logs -f -n ghstats-build-run-123456-123456789
For more information, see [troubleshooting section](https://cloud.ibm.com/docs/schematics?topic=schematics-wks-create-api&interface=cli).







 Perform the workspace deploy with Terraform 



1. Follow the steps in [Setting up Terraform for Schematics](https://cloud.ibm.com/docs/schematics?topic=schematics-terraform-setup) to create your workspace with Terraform.
2. See [Managing IBM Cloud resources with Schematics](https://cloud.ibm.com/docs/schematics?topic=schematics-manage-lifecycle) to create, update, or delete IBM Cloud resources with Terraform.







 Next steps 

To manage your workspace refer to, [deploying workspace](https://cloud.ibm.com/docs/schematics?topic=schematics-sch-deploy-wks), [destroying workspace](https://cloud.ibm.com/docs/schematics?topic=schematics-sch-destroy-wks&interface=ui), and [deleting workspace](https://cloud.ibm.com/docs/schematics?topic=schematics-sch-delete-wks&interface=ui).
* UI
* CLI
* API







 Creating a workspace 

With IBM Cloud® Schematics workspaces, you can manage the Terraform-based templates to create and manage IBM Cloud resources. A workspace allows you to view and update configuration properties, view the list of resources that are provisioned through the workspace, and clean up resources if and when needed.



 Creating a workspace using the UI 



1. Go the [Schematics, IBM Cloud's deployment manager](https://cloud.ibm.com/schematics/overview).
2. In the navigation menu, select Workspaces, and then select Create workspace.
3. In the Specify template section:



* Provide your GitHub, GitLab, or Bitbucket repository URL where your Terraform files reside. The Red Hat OpenShift repository is provided by IBM Cloud in this [public GitHub repository](https://github.com/IBM-Cloud/hpc-cluster-openshift).
* If you are using a private GitHub repository, provide your personal GitHub access token.
* Select the version of the Terraform engine that's used in the Schematics workspace, then click Next.



4. In the Workspace details section:



* Specify the name for your Schematics workspace.
* Define any tags that you want to associate with the resources that are provisioned through the offering. The tags can later be used to query the resources in the IBM Cloud console.
* Select a resoure group.
* Select a location. The location determines where the workspace actions are run.
* Provide a description (optional) of the Schematics workspace.
* Click Next, and then click Create. The Schematics workspace is created with the name that you specified.



5. Go to Schematics Workspace Settings, and in the Variable section, click "burger icons" to update the following parameters:



* Update the ssh_key_name with your IBM Cloud SSH key name, such as "openshift-ssh-key", that is created in a specific region in IBM Cloud.
For compute service, select Kubernetes from the list.
3. Select Specific resources to establish trust with one or more existing compute resource instances.
4. Click Add another resource.
5. Select the cluster that you created for this tutorial.
6. Enter the values for the namespace and service account fields.

The Kubernetes namespace and service account names that you enter do not have to exist already. Any future namespaces or service accounts with these names can establish trust. To list existing namespaces, log in to your cluster and run kubectl get ns. To list existing service accounts, log in to your cluster and run kubectl get sa -n <namespace>. You can also enter default for both.
7. Click Continue.







 Step 3: Assign access to other IBM Cloud services 

Now, you can create an access policy to give your compute resource instance access to other IBM Cloud services you need for your team's chatbot project.



1. Select Access policy.
2. Select Watson Assistant from the list of services. Make sure you have access on the service you want to give access to in this profile.Click Next.
3. Scope the access to Specific resources based on selected attributes.
4. Select Service Instance and input the service instance name to give permission to a specific instance. Click Next.
5. Select Writer and Manager roles to define the scope of access, and click Review.
6. Click Add to add your policy configuration to your policy summary.
7. Click Assign.







 Next steps 

To learn more about establishing trust with a Kubernetes cluster, see [Using Trusted Profiles in your Kubernetes and OpenShift Clusters](https://www.ibm.com/cloud/blog/using-trusted-profiles-in-your-kubernetes-and-openshift-clusters).
Kubernetes resources include services, deployments, and pods. For more information, see [Service architecture](https://cloud.ibm.com/docs/containers?topic=containers-service-arch).

Namespace
: Kubernetes namespaces are a way to divide your cluster resources into separate areas that you can deploy apps and restrict access to, such as if you want to share the cluster with multiple teams. For example, system resources that are configured for you are kept in separate namespaces like kube-system or ibm-system. If you don't designate a namespace when you create a Kubernetes resource, the resource is automatically created in the default namespace. For more information, see the [Kubernetes documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/).

Service
: A service is a Kubernetes resource that groups a set of pods and provides network connectivity to these pods without exposing the actual private IP address of each pod. You can use a service to make your app available within your cluster or to the public internet. For more information, see the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/service/).

Deployment
: A deployment is a Kubernetes resource where you might specify information about other resources or capabilities that are required to run your app, such as services, persistent storage, or annotations. You document a deployment in a configuration YAML file, and then apply it to the cluster. The Kubernetes master configures the resources and deploys containers into pods on the worker nodes with available capacity.
: Define update strategies for your app, including the number of pods that you want to add during a rolling update and the number of pods that can be unavailable at a time. When you perform a rolling update, the deployment checks whether the update is working and stops the rollout when failures are detected.
: A deployment is just one type of workload controller that you can use to manage pods.
label = "label"
kind_format = "operator"
version = "version"
cluster_id = "cluster_id"
cluster_region = "cluster_region"
cluster_namespaces = [ "cluster_namespaces", "cluster_namespaces" ]
cluster_all_namespaces = false
}

You can specify an update timeout for the ibm_cm_offering_instance resource. For more information, see the timeout reference details on the [Terraform Catalog Management](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/cm_offering_instancetimeouts) page.
2. After you finish building your configuration file, initialize the Terraform CLI. For more information, see [Initializing Working Directories](https://www.terraform.io/cli/init).

terraform init
3. Provision the resources from the main.tf file. For more information, see [Provisioning Infrastructure with Terraform](https://www.terraform.io/cli/run).



1. Run terraform plan to generate a Terraform execution plan to preview the proposed actions.

terraform plan
2. Run terraform apply to create the resources that are defined in the plan.

terraform apply









 Deleting your software instance by using Terraform 

You can delete your software instance by using Terraform.



1. You can delete the software instance by removing the following code block from your Terraform file. You must have created the cm_offering_instance using the Terraform file.

resource "ibm_cm_offering_instance" "cm_offering_instance" {
catalog_id = "catalog_id"
label = "label"
kind_format = "operator"
version = "version"
cluster_id = "cluster_id"
cluster_region = "cluster_region"
cluster_namespaces = [ "cluster_namespaces", "cluster_namespaces"]
cluster_all_namespaces = false
}
Setting up and configuring your Developer Portal 

Duration: 30 mins
Skill level: Beginner



 Objective 

This tutorial will help you quickly get started with configuring your API Connect Developer Portal using API Connect V5.





 Prerequisites 

Before you begin, you will need to [import your API spec and proxy an existing REST service](https://cloud.ibm.com/docs/apiconnect/tutorials?topic=apiconnect-tut_rest_landing).

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





 Create your developer portal 

In this section, you will create a developer portal for a catalog.

Catalogs are an IBM term for different environments. For example, you would create different catalogs for your testing, staging, and production enviornments. You should have a catalog called Sandbox. Feel free to use this catalog to create your developer portal, or create a new catalog and name it whatever you want.



1. In your IBM Cloud dashboard, select your API Connect service to launch the API Connect dashboard. ![API Connect Service](https://cloud.ibm.com/docs-content/v1/content/78bb71851d95d7580503eb9ba10cf3ae31490ade/apiconnect/tutorials/images/11-Dashboard.png)
2. In the API Connect dashboard, select the catalog for which you want to create a developer portal. For example, Sandbox. ![Catalog](https://cloud.ibm.com/docs-content/v1/content/78bb71851d95d7580503eb9ba10cf3ae31490ade/apiconnect/tutorials/images/12-APIC-Dashboard.png)
3. In the catalog, select the Settings tab.
!
If the workspace creation is successful, the Apply Plan action is started to trigger the deployment of the respective IBM Cloud VPC resources in your IBM Cloud account that are linked with the api_key.
8. You can also review the status of your deployment process by identifying the workspace name in the View the existing installations section. When you click a record in View the existing installations section, you are taken to the Schematics workspace view.







 Next steps 

After you've successfully created a workspace, you can begin [Generating a plan](https://cloud.ibm.com/docs/hpc-spectrum-symphony?topic=hpc-spectrum-symphony-generate-plan&interface=uigenerate-plan-ui) to validate all of the configuration properties.





 Before you begin 

Before you get started, make sure that you've completed the prerequisites found in [Setting up the IBM Cloud Schematics CLI](https://cloud.ibm.com/docs/hpc-spectrum-symphony?topic=hpc-spectrum-symphony-setting-up-cli&interface=cli).





 Creating a workspace using the CLI 

The first step when using Schematics is to create a workspace with the specific configuration parameters defined in the corresponding Terraform source code.

Use the following CLI command to create a workspace with your config.json file. Make sure that the config.json file exists in the directory where you run the command.

ibmcloud schematics workspace new -f hpc_workspace_config.json --github-token GITHUB_TOKEN

The --github-token parameter is optional and only needed if you are using a private GitHub repository. If you are using the [IBM Cloud public GitHub repository](https://github.com/IBM-Cloud/hpc-cluster-symphony), you do not need to provide it.



 Listing available workspaces 

You can list the workspaces in your account by using the following command:

ibmcloud schematics workspace list

Example response with workspace details:

Name           ID       Description           Status         Frozen