vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Fri Jul 16 07:49:39 EDT 2021
Fri Jul 16 07:49:39 EDT 2021
9. Exit the pod.

exit







 Removing Azure file storage from your apps 

If you no longer need your Azure File configuration, you can remove your apps, PVCs, PVs, and assignment from your clusters.



1. List your PVCs and note the name of the PVC that you want to remove.

oc get pvc
2. Remove any pods that mount the PVC.



1. List all the pods that currently mount the PVC that you want to delete. If no pods are returned, you do not have any pods that currently use your PVC.

oc get pods --all-namespaces -o=jsonpath='{range .items[]}{"n"}{.metadata.name}{":t"}{range .spec.volumes[]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"

Example output

app sat-azure-file-platinum
2. Remove the pod that uses the PVC. If the pod is part of a deployment or statefulset, remove the deployment or statefulset.

oc delete pod <pod_name>

oc delete deployment <deployment_name>

oc delete statefulset <statefulset_name>
3. Verify that the pod, deployment, or statefulset is removed.

oc get pods

oc get deployments

oc get statefulset



3. Delete the PVC. Because the Azure File storage classes have a Delete reclaim policy, the PV and the disks in your Azure account are automatically deleted when you delete the PVC.

oc delete pvc <pvc_name>
4. Verify that your PV is automatically removed.

oc get pv







 Removing the Azure File storage configuration from your cluster
"checks": "travis/ci", "detect-secrets"]
}
},
{
"type": "check-run",
"name": "open-source-license-scan",
"params": {
"name": "ossc/ci"
}
}
]

Running the command:

cocoa check pull-request-status







 cocoa change-request commands 

The cocoa change-request commands support the following change management providers:



* ServiceNow V1
* ServiceNow V3



You can specify the provider by using the --provider option with the following values: servicenow (default), or servicenow-v3.

Each provider requires different environment variable configuration:



* servicenow:



* SERVICENOW_TOKEN - ServiceNow V1 API Token
* SERVICENOW_URL - ServiceNow V1 API URL



* servicenow-v3:



* IAM_ACCESS_TOKEN - IBMCloud IAM OAuth Token
* SERVICENOW_URL - ServiceNow V3 API URL







 cocoa change-request get 

Queries a Change Request from the ServiceNow API and saves it to a file or prints it to the console.

Required Environment Variables for ServiceNow v1 or v2:

SERVICENOW_TOKEN= ServiceNow API Token
SERVICENOW_URL= ServiceNow API URL

Required Environment Variables for ServiceNow v3:

IAM_ACCESS_TOKEN= Access token obtained from the IAM service corresponding to pnp-ibmcloud-api-key.
SERVICENOW_URL= ServiceNow API URL

Options:

--change-request-id='CHGXXXXXX' (Required) The Change Request ID to query from ServiceNow.
--output='filename.json' (Optional) If provided, the Change Request data will be written to this file.
--provider='servicenow' (Optional) Change Management service provider (choices: 'servicenow', 'servicenow-v3', default: 'servicenow')

Running the command:
Pod security admission 

Pod security admission implements the Kubernetes pod security standards that restrict the behavior of pods, providing warning messages and kube-apiserver audit events for pods that violate the pod security profile policy configured for the relevant namespace.

IBM Cloud Kubernetes Service version 1.25 and later includes support for Kubernetes pod security admission. For more information, see [Pod Security Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/) and [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) in the Kubernetes documentation.

Pod Security Admission is always enabled for IBM Cloud Kubernetes Service version 1.25 and later. Earlier versions of Kubernetes use [pod security policies](https://cloud.ibm.com/docs/containers?topic=containers-psp).



 Understanding security profiles 

The Kubernetes pod security standards define the following three profiles.

Privileged
: The default pod security configuration globally enforces the privileged Kubernetes pod security profile, which is unrestricted and allows for known privilege escalations, and generates warnings and audit events based on the policies set by the restricted profile.

Baseline
: The baseline profile is a restrictive profile that prevents known privilege escalations. Allows the default (minimally specified) Pod configuration.

Restricted
: The restricted profile is heavily restricted and follows the current pod hardening best practices.

For more information about pod security profiles, see [Profile details](https://kubernetes.io/docs/concepts/security/pod-security-standards/) in the Kubernetes documentation.

Pod Security Admission contains three modes that define what action the control plane takes if a potential violation is detected.

enforce
: Policy violations cause the pod to be rejected.

audit
: Policy violations trigger the addition of an audit annotation to the event recorded in the audit log, but are otherwise allowed.

warn
: Policy violations trigger a user-facing warning, but are otherwise allowed.
* one-pipeline-status Set to 1 if there is a stage failure in the pipeline run.



Check these variables before calling cocoa inventory add in this stage.



 Example 

 Check the status of pipeline and then release the artifacts to inventory

ONE_PIPELINE_STATUS=$(get_env one-pipeline-status 0)
if [ -n "$(get_env skip-inventory-update-on-failure "")" ]; then
if [ $ONE_PIPELINE_STATUS -eq 1 ]; then
echo "Skipping release stage as some of the pipeline stages are not successful."
exit 1
fi
fi


 list_artifacts returns the list of the reference names of saved artifacts

list_artifacts | while IFS= read -r artifact ; do

 Add a new value to the inventory repository. cocoa inventory add creates a new file with the name option,
 if does not exist otherwise overwrites it.

cocoa inventory add --name="${artifact}" --artifact="$(load_artifact $artifact name)" --repository-url="$(load_repo app-repo url)" --commit-sha="$(load_repo app-repo commit)" --build-number="${BUILD_NUMBER}" --pipeline-run-id="${PIPELINE_RUN_ID}" --version="$(get_env version)" --app-artifacts="{ "signature": "$(load_artifact $artifact signature)", "provenance": "$(load_artifact $artifact name)" }"
done
Show more

To use the CLI, you must install it in your scripts, or use a base image that has the CLI pre-installed.







 Related information 



* Documentation on stages for user-defined scripts
* API documentation for pipelinectl
* Example test script
* Example build scripts
* Example release script
* The default built-in image signing script
* The default built-in VA scan checker script
This makes it important that pods use the ibm-privileged-psp, which is not a mutating PSP, before you upgrade. Because both Pod Security Admission and the ibm-privileged-psp are validating, pods work the same under either one.

For example, if a pod is currently running under ibm-restricted-psp, it might set the fsGroup and supplementalGroups to 1 in the pod securityContext section, based on the MustRunAs range in the PSP. In other words, the ibm-restricted-psp can change the pod securityContext. Such changes are visible as a difference between the securityContext of the running pod and the securityContext in the pod template of the deployment or similar resource that creates the pod. The ibm-privileged-psp is not mutating, so a pod running under it might run with different groups and might not be able to access data stored in an existing PVC.



1. Get the details of all pods and check their PSPs.

kubectl get pods -A -o jsonpath="{.items[].metadata.annotations.kubernetes.io/psp}" | tr " " "n" | sort -u
2. Review the command output for any PSPs that are not ibm-privileged-psp. If your pods are using a different PSP, you must update your application to use the ibm-privileged-psp before upgrading your cluster. If no other PSPs are listed, you can continue with the upgrade.



Upgrading to 1.25 is not recommended if the output lists a PSP other than the ibm-privileged-psp PSP.





 Step 2: Verify the privileged-psp-user cluster role binding uses the default configuration 

Complete the following steps to verify that the privileged-psp-user cluster role binding uses the default configuration. This ensures that all service accounts and users are authorized to use the ibm-restricted-psp through the privileged-psp-user cluster role binding.

Your upgrade to 1.25 fails if the cluster role binding does not have the default role and subjects exactly as shown in the following example.



1. Get the details privileged-psp-user cluster role binding.
You can add labels to the certain critical namespaces, such as kube-system, so the webhook is not called for these cases. This setup is called an "opt out" style configuration. Or, you can configure the namespaceSelector option so the webhook is called only for namespaces that have a specific label. This setup is called an "opt in" configuration. Depending on the purpose of the webhook, it might be important that the webhook be called for all namespaces. Review the namespaceSelector configuration options in the [Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/matching-requests-namespaceselector) and adjust your webhook configuration.
* Make sure that the worker nodes in your cluster are [the correct size for running your webhook applications](https://cloud.ibm.com/docs/containers?topic=containers-strategysizing). For example, if your pods request more CPU or memory than the worker node can provide, the pods are not scheduled.







 What other types of apps use admission controllers? 

Many cluster add-ons, plug-ins, and other third-party extensions use admission controllers. Some common ones include:



* [Portieris](https://cloud.ibm.com/docs/openshift?topic=openshift-imagesportieris-image-sec)
* [Istio](https://cloud.ibm.com/docs/containers?topic=containers-istio-about)





 Setting up admission controller webhooks 

In Kubernetes cluster versions 1.21 and later, Konnectivity replaced the OpenVPN solution. If you have cluster version 1.21 and later, and your webhook uses the ClusterIP, you must update your webhook to use a Kubernetes service instead.

You can configure a webhook by referencing the webhook app as a Kubernetes service, or by referencing the webhook app as an IP address or publicly registered DNS name.
Pod security admission 

Pod security admission implements the Kubernetes pod security standards that restrict the behavior of pods, providing warning messages and kube-apiserver audit events for pods that violate the pod security profile policy configured for the relevant namespace.

Red Hat OpenShift on IBM Cloud version 4.11 and later includes support for Kubernetes pod security admission. For more information, see [Pod Security Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/) and [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) in the Kubernetes documentation.

Pod Security Admission is always enabled for Red Hat OpenShift on IBM Cloud version 4.11 and later. Earlier versions of Kubernetes use [pod security policies](https://cloud.ibm.com/docs/containers?topic=containers-psp).



 Understanding security profiles 

The Kubernetes pod security standards define the following three profiles.

Privileged
: The default pod security configuration globally enforces the privileged Kubernetes pod security profile, which is unrestricted and allows for known privilege escalations, and generates warnings and audit events based on the policies set by the restricted profile.

Baseline
: The baseline profile is a restrictive profile that prevents known privilege escalations. Allows the default (minimally specified) Pod configuration.

Restricted
: The restricted profile is heavily restricted and follows the current pod hardening best practices.

For more information about pod security profiles, see [Profile details](https://kubernetes.io/docs/concepts/security/pod-security-standards/) in the Kubernetes documentation.

Pod Security Admission contains three modes that define what action the control plane takes if a potential violation is detected.

enforce
: Policy violations cause the pod to be rejected.

audit
: Policy violations trigger the addition of an audit annotation to the event recorded in the audit log, but are otherwise allowed.

warn
: Policy violations trigger a user-facing warning, but are otherwise allowed.
claim-file-bronze Bound pvc-457a2b96-fafc-11e7-8ff9-b6c8f770356c 4Gi RWX ibmc-file-bronze-retain 105d
claim-file-silve Bound pvc-1efef0ba-0c48-11e8-968a-f6612bb731fb 24Gi RWX ibmc-file-silver 83d
2. Review the ReclaimPolicy and billingType for the storage class.

kubectl describe storageclass <storageclass_name>

If the reclaim policy says Delete, your PV and the physical storage are removed when you remove the PVC. Note that VPC Block Storage is not removed automatically, even if you used a Delete storage class to provision the storage. If the reclaim policy says Retain, or if you provisioned your storage without a storage class, then your PV and physical storage are not removed when you remove the PVC. You must remove the PVC, PV, and the physical storage separately.

If your storage is charged monthly, you still get charged for the entire month, even if you remove the storage before the end of the billing cycle.
3. Remove any pods that mount the PVC. List the pods that mount the PVC. If no pod is returned in your CLI output, you don't have a pod that uses the PVC.

kubectl get pods --all-namespaces -o=jsonpath='{range .items[]}{"n"}{.metadata.name}{":t"}{range .spec.volumes[]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"

Example output

blockdepl-12345-prz7b: claim1-block-bronze
4. Remove the pod that uses the PVC. If the pod is part of a deployment, remove the deployment.

kubectl delete pod <pod_name>
5. Verify that the pod is removed.

kubectl get pods
* If the pilot version and the data plane version match, no further updates are required.
* If the pilot version and the data plane version don't match, restart your deployments for the data plane pods that run the old version. The pod name and namespace are listed in each entry as data plane version: version.ProxyInfo{ID:"<pod_name>.<namespace>", IstioVersion:"1.8.4"}.



kubectl rollout restart deployment <deployment> -n <namespace>









 Uninstalling Istio 

If you're finished working with Istio, you can clean up the Istio resources in your cluster by uninstalling the Istio add-ons.



 Step 1: Managing resources before uninstallation 

Review the following optional steps for saving or deleting custom Istio resources before you uninstall Istio.



1. Any resources that you created or modified in the istio-system namespace and all Kubernetes resources that were automatically generated by custom resource definitions (CRDs) are removed. If you want to keep these resources, save them before you uninstall the Istio add-on.



1. Save any resources, such as configuration files for any services or apps, that you created or modified in the istio-system namespace.

kubectl get pod <pod_name> -o yaml -n istio-system
2. Get the CRDs in istio-system.

kubectl get crd -n istio-system
3. Save the Kubernetes resources that were automatically generated by these CRDs to a YAML file on your local machine.



2. The managed-istio-custom ConfigMap is not removed during uninstallation. If you later re-enable the Istio add-on, any [customized settings that you made to the ConfigMap](https://cloud.ibm.com/docs/containers?topic=containers-istiocustomize) are applied during installation. If you don't want to re-use your custom settings in a later installation of Istio, you must delete the ConfigMap.
Before you begin, [review the packages that are included with the PHP runtime](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-runtimesopenwhisk_ref_php) to see whether a dependency of your app is already included with the runtime. If your dependency is not included, you must package it with your app.

To package your app, run the following command.

zip -r <archive_name>.zip <file_1>.php <file_2>.php

For example, package the following code examples.



1. Create the code examples.

index.php

<?php
include 'helper.php';
function main(array $args) : array
{
$name = $args["name"] ?? "stranger";
$help = help($name);
return ["help" => $help];
}
?>

helper.php

<?php
function help($name) {
return "Hello " . $name . " the answer to life the universe and everything is 42";
}
?>
2. Compress the code examples.

zip -r helloPHP.zip index.php helper.php
3. Create the action.

ibmcloud fn action create packagePHP helloPHP.zip --kind=php:7.4







 Packaging Composer modules 

You can package extra Composer modules into your action

Before you begin, [review the packages that are included with the php runtime](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-runtimesopenwhisk_ref_php) to see whether a dependency of your app is already included with the runtime. If your dependency is not included, you must package it with your app. The following steps assume that you are running the commands on a Linux-based distribution on a processor with AMD64-based architecture.



1.
"instanceGUID": "<instance_guid>",
"apikey": "<instance_apikey>",
"region": "<region>",
"deviceId": "<YOUR_DEVICE_ID>",
"safariDestinationId": "<safari_destination_id>",
"websitePushIdSafari": "<Safari Web Push Id Identifier>"
}

enPush.initialize(initParams, callback)
Show more



* region: Region of the Event Notifications instance. for example, us-south,eu-gb, au-syd, and eu-de.
* deviceId: Optional deviceId for device registration.



* To register for notifications, se the register() or registerWithUserId() API to register the device with IBM Cloud Event Notifications service. Choose either of the following options:



* Register without UserId:

enPush.register(function(response) {
alert(response.response)
})
* Register with UserId. For userId based notification, the register method accepts one more parameter - userId.



bmsPush.registerWithUserId("UserId",function(response) {
alert(response.response)
})

UserId is the user identifier value with which you want to register devices in the push service instance.
* The subscribe API subscribes the device for a tag. After the device is subscribed to a particular tag, the device can receive notifications that are sent for that tag. Add the following code snippet to your web application to subscribe to a list of tags.

enPush.subscribe(tagName, function(response) {
alert(response.response)
})
* When the setup is complete, run your application and register for push notifications.







 Step 8: Send notifications to the Safari Web device
readOnly: false

Show more
4. Create the pod in your cluster.

oc apply -f mypvc.yaml
5. Verify that the pod is deployed. Note that it might take a few minutes for your app to get into a Running state.

oc get pods

NAME READY STATUS RESTARTS AGE
my-pvc 1/1 Running 0 2m58s
6. Verify that the app can write to your block storage volume by logging in to your pod.

oc exec -it web-server /bin/bash
7. View the contents of the outfile file to confirm that your app can write data to your persistent storage.

cat outfile

Example output

Fri Jul 16 07:49:39 EDT 2021
Fri Jul 16 07:49:39 EDT 2021
Fri Jul 16 07:49:39 EDT 2021
8. Exit the pod.

exit







 Removing VMWare storage from your apps 

If you no longer need your VMware configuration, you can remove your apps, PVCs, PVs, and assignment from your clusters.



1. List your PVCs and note the name of the PVC that you want to remove.

oc get pvc
2. Remove any pods that mount the PVC.



1. List all the pods that currently mount the PVC that you want to delete. If no pods are returned, you do not have any pods that currently use your PVC.

oc get pods --all-namespaces -o=jsonpath='{range .items[]}{"n"}{.metadata.name}{":t"}{range .spec.volumes[]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"

Example output

NAME READY STATUS RESTARTS AGE
web-server 1/1 Running 0 55s
2. Remove the pod that uses the PVC. If the pod is part of a deployment or statefulset, remove the deployment or statefulset.
$ cocoa change-request create --assigned-to=<your-ibm-email> --system=<servicenow-configuration-item> --impact=<impact description> --outage-duration='0 00:00:00' --priority=<the-priority> --environment=<involved-environment> --purpose=<purpose-explanation> --description=<description-of-the-change> --backout-plan=<description-of-a-backout-plan> --planned-start='2020-05-13 13:00:12' --planned-end='2020-05-13 13:10:12' --deployment-ready=<yes/no> --type=<change-type>





 cocoa change-request change-state-to-implement 

Changes the state of a Change Request to implement through the ServiceNow API.

Options:

--provider (Optional) Change Management service provider (choices: 'servicenow', 'servicenow-v3', default: 'servicenow')

Required Environment Variables regardless of the provider:

CHANGE_REQUEST_ID= ID of the Change Request

Required Environment Variables, if you are using ServiceNow v1 or v2 provider:

SERVICENOW_TOKEN= ServiceNow API Token
SERVICENOW_URL= ServiceNow API URL

Required Environment Variables, if you are using ServiceNow v3 provider:

IAM_ACCESS_TOKEN= Access token obtained from the IAM service corresponding to pnp-ibmcloud-api-key.
SERVICENOW_URL= ServiceNow API URL

Running the command:

cocoa change-request change-state-to-implement





 cocoa change-request close 

Closes a Change Request through the ServiceNow API. You can attach 'close notes' by using the --close-notes option and specify the 'close category' using the --close-category option.

Options:

--close-category Choices: "successful" (default), "successful_issues", "unsuccessful", "cancelled"
--close-notes String, defaults to "Deployment done."
$ cocoa inventory add --environment=environment --artifact=foo-helm-chart/foo/chart.yaml --repository-url=http://validURL.com --commit-sha=786800e8e48938664fe2397ca14ab8dabd48f34656ef5cfda4143b4519cb714f --build-number=33 --pipeline-run-id=123123valid --version=v4 --name=chart





 cocoa inventory get 

Gets an entry from the inventory repository. The target can be a specific version or an environment. Either use --version or --environment, and use only one of them. If the --property option is missing, the whole content of the inventory entry is printed.

Required Environment Variables, if you are using GitHub:

GHE_TOKEN= Github Enterprise API Token (Optional if you are using --git-token-path)

Options for Git:

--git-token-path (Optional) Github Token's path
--git-api-url (Optional) Github API url

If you are using github, use --git-token-path field to set your GitHub Token and --git-api-url field to set the # GitHub Enterprise API URL instead of GHE_TOKEN and GH_URL environment variables. If both GHE_TOKENGH_URL and --git-token-path--git-api-url pairs are provided, then --git-token-path and --git-api-url take precedence.

By default, the CLI on each invocation ensures that you work with an up-to-date version of a Git locker. This behavior can be disabled by setting COCOA_USE_CACHE to any value except 0, false, no, or n. In this case, the CLI uses its internal cache to look up evidence (much faster), but results might be stale.

Running the command: