vania-janet/multiturn-rag-retrieval-data huggingface dataset:
This also helps to continue with the deployment because thought the same issue is found in build, the deployment does not make the security posture worse. For more information, see [Incident issues with due date](https://cloud.ibm.com/docs/devsecops?topic=devsecops-incident-issuesdevsecops-issues-due-date).

The issues are created in the issues repository that is mentioned at the time of toolchain setup. A sample issue that indicates a vulnerability with a due date looks like the following:

Zoom

![DevSecOps sample incident issue](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops-cc-toolcain-explore-sample-issue.png)

Figure 20. DevSecOps sample incident issue created with CC pipeline





 Explore DevOps Insights 

Evidence from all compliance checks in the CC pipeline is uploaded to both the evidence locker repository and to the Cloud Object Storage bucket if Cloud Object Storage is enabled during setup.

Evidence is also published to DevOps Insights. You can navigate to DevOps Insights by clicking the Link DevOps Insights tool card in the toolchain, or you can go to the CI toolchain DevOps Insights instance, which is linked to the CC pipeline. You can review the collected evidence on the DevOps Insights quality dashboard page.

Zoom

![DevSecOps CC evidence](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops-cc-explore-evidence.png)

Figure 21. DevSecOps CC evidence

For more information, see [DevOps data aggregation](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-devops-data-aggregation).





 CI and CC pipeline comparison
Why does the Block storage plug-in Helm chart give CPU throttling warnings? 

Classic infrastructure

  What’s happening 

When you install the Block storage Helm chart, the installation gives a warning similar to the following:

Message: 50% throttling of CPU in namespace kube-system for container ibmcloud-block-storage-driver-container in pod ibmcloud-block-storage-driver-1abab.

  Why it’s happening 

The default Block storage plug-in resource requests are not sufficient. The Block storage plug-in and driver are installed with the following default resource request and limit values.

plugin:
resources:
requests:
memory: 100Mi
cpu: 50m
limits:
memory: 300Mi
cpu: 300m
driver:
resources:
requests:
memory: 50Mi
cpu: 25m
limits:
memory: 200Mi
cpu: 100m
Show more

  How to fix it 

Remove and reinstall the Helm chart with increased resource requests and limits.



1.  Remove the Helm chart.

helm uninstall <release_name> iks-charts/ibmcloud-block-storage-plugin -n <namespace>
2.  Reinstall the Helm chart and increase the resource requests and limits by using the --set option when running helm install. The following example command sets the plugin.resources.requests.memory value to 200Mi and the plugin.resources.requests.cpu value to 100m. You can pass multiple values by using the --set option for each value that you want to pass.

helm install <release_name> iks-charts/ibmcloud-block-storage-plugin -n <namespace> --set plugin.resources.requests.memory=200Mi --set plugin.resources.requests.cpu=100m
The Commands API executes one or group of Terraform commands by using the JSON file for your workspace command requirements. The access control such as plan, apply, destroy, or refresh are applicable for Commands API. Select your region where the workspace is created, and use the following syntax to run the commands API.

Syntax

ibmcloud schematics workspace commands --id WORKSPACE_ID --file FILE_NAME

Command options



Schematics Terraform commands flags

 Flag Required / Optional Description 

 --id or -i Required The unique ID of the workspace where you want to run the commands. To find the ID of your workspace, run ibmcloud schematics workspace list command. 
 --file or --f Required Path to the JSON file containing the list of Terraform commands. 



Sample payload of Test.JSON file:

{
"commands": [
{
"command": "state show",
"command_params": "data.template_file.test",
"command_name": "Test1",
"command_desc": "Showing state",
"command_onerror": "continue"
},
{
"command": "taint",
"command_params": "null_resource.sleep",
"command_name": "Test2",
"command_desc": "Marking taint",
"command_onerror": "continue"
},
{
"command": "untaint",
"command_params": "null_resource.sleep",
"command_name": "Test3",
"command_desc": "Marking untaint",
"command_onerror": "continue"
},
{
"command": "state list ",
"command_params": "",
"command_name": "Test4",
"command_desc": "Checking state list",
"command_onerror": "continue"
The following steps are general instructions. Before you use the container in a production environment, be sure that any security requirements are met.



1. Ensure that you have the following [IBM Cloud IAM roles](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms):



* Editor or Administrator platform access role for the cluster
* Writer or Manager service access role for the kube-system namespace



2. For the cluster where the log source is located: [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)
3. Set up a server that accepts a syslog protocol in 1 of 2 ways:



* Set up and manage your own server or have a provider manage it for you. If a provider manages the server for you, get the logging endpoint from the logging provider.
* Run syslog from a container. For example, you can use this [deployment .yaml file](https://github.com/IBM-Cloud/kube-samples/blob/master/deploy-apps-clusters/deploy-syslog-from-kube.yaml) to fetch a Docker public image that runs a container in your cluster. The image publishes the port 514 on the public cluster IP address, and uses this public cluster IP address to configure the syslog host. You need to inject the relevant certificate authority and server-side certificates and update the syslog.conf to enable tls on your server.



4. Save your certificate authority certificate to a file named ca-cert. It must be that exact name.
5. Create a secret in the kube-system namespace for the ca-cert file. When you create your logging configuration, use the secret name for the --ca-cert option.

kubectl -n kube-system create secret generic --from-file=ca-cert
6. Create a log forwarding configuration.
Initialize the Terraform CLI.

terraform init
4. Create a Terraform execution plan. This plan summarizes all of the actions that must run to delete the toolchain.

terraform plan
5. Apply the Terraform execution plan. Terraform takes all of the required actions to delete the toolchain.

terraform apply









 Take a tutorial: Using toolchains 

Try the [Add a toolchain to an app](https://www.ibm.com/cloud/architecture/tutorials/add-a-toolchain-to-an-app?task=2) tutorial on the [IBM Cloud Garage Method](https://www.ibm.com/garage/method).
Getting started 

Use this information to configure your server to use IBM Cloud® email service.



  Preparing for email delivery 



1.  Confirm that you can send emails from the device before you add or update smart host settings. Fix any existing problems in the send and receive process before you proceed.
2.  Follow these steps to access the Exim Configuration Editor:



*  Access WHM with your credentials.
*  Go to Service Configuration > Exim Configuration Editor.
*  Click Advanced Editor to open the editor.







  Notes 



*  Specific instructions for using the Advanced Editor are on the Exim Configuration Editor screen.
*  This procedure can cause Exim to fail.
*  The Exim Configuration Editor screen displays the contents of the file exim.conf. You can edit exim.conf by using the Exim Configuration Manager.









  Authenticating with SendGrid credentials 

Locate the Begin Authenticators section and enter the following commands in the corresponding text box that is labeled Section: AUTH

sendgrid_login:

driver = plaintext

public_name = LOGIN

client_send = : username@example.com :

YourSendgridPassword





  Configuring routers 

Add the following commands to Routers Configuration in the section that is labeled Section: PREROUTERS:

send_via_sendgrid:

driver = manualroute

domains = ! +local_domains

transport = sendgrid_smtp

route_list = "* smtp.sendgrid.net::587 byname"

host_find_failed = defer

no_more





  Configuring transports 



1.  Add the following commands to Transports Configuration in the section that is labeled Section: TRANSPORTSTART

sendgrid_smtp:

driver = smtp

hosts = smtp.sendgrid.net

hosts_require_auth = smtp.sendgrid.net

hosts_require_tls = smtp.sendgrid.net
2.  Click the Save at the end of the page.



To receive root/nobody/cpanel mail that is forwarded to external address, the hostname of the cPanel servers needs to be in the /etc/localdomains file.





  Next steps 

The system runs a series of checks against the updated configuration file and restarts Exim. If you are logged in to any WebMail pages, log out, and log back in after the restart is complete. Send a test email to make sure that the proper credits are used.
To use the actions in the natural-language-classifier-v1 Package, you must bind service credentials to the actions.



* To bind service credentials to all actions in the package, follow steps 4 and 5 in the [CLI instructions](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-pkg_natlang_classifiernlclassifier_cli).
* To bind service credentials to individual actions, complete the following steps in the console.



You must complete the following steps for each action that you want to use.



1. Click an action from the natural-language-classifier-v1 Package that you want to use. The details page for that action opens.
2. In the left navigation, click the Parameters section.
3. Enter a new parameter. For the key, enter __bx_creds. For the value, paste in the service credentials JSON object from the service instance that you created earlier.











 Using the Natural Language Classifier package 

To use the actions in this package, run commands in the following format.

ibmcloud fn action invoke natural-language-classifier-v1/<action_name> -b -p <param name> <param>

Try out the list-classifiers action.

ibmcloud fn action invoke natural-language-classifier-v1/list-classifiers -b
To follow step-by-step instructions using a toolchain template to deploy to Kubernetes, see [Tutorial: Use the "Develop a Kubernetes app" toolchain](https://www.ibm.com/cloud/architecture/tutorials/use-develop-kubernetes-app-toolchain?task=0) or [Tutorial: Use the "Develop a Kubernetes app with Helm" toolchain](https://www.ibm.com/cloud/architecture/tutorials/use-develop-kubernetes-app-with-helm-toolchain?task=0).

To create a pipeline.yml manually that is specifically for containers, see the [examples in GitHub](https://github.com/Puquios/).
You should see the following message: Terraform has been successfully initialized!.





 Step 4. Create a Terraform configuration file 

Next, create a Terraform configuration file that is named main.tf. In this file, you add the configuration to manage an ingestion key by using HashiCorp Configuration Language (HCL). For more information, see the [Terraform documentation](https://www.terraform.io/docs/language/index.html).

The following code shows a sample configuration file to manage an ingestion key.

resource "logdna_key" "ingestion-key" {
type = "ingestion"
name = "tf-my-ingestion-key"

lifecycle {
create_before_destroy = true
}
}

The lifecycle object is required when you rotate a key.





 Step 5. Manage an ingestion key 



 Create an ingestion key 

Complete the following steps to create a key:



1. Initialize the Terraform CLI.

./terraform init
2. Create a Terraform execution plan.

./terraform plan
3. Create the resources.

./terraform apply







 Rotate an ingestion key 

Complete the following steps to rotate a key from the directory where you have the terraform script that you use to create a key:



1. Initialize the Terraform CLI.

./terraform init
2. Rotate the key.

.terraform apply -replace="logdna_key.ingestion-key"







 Delete an ingestion key 

Complete the following steps to delete a key from the directory where you have the terraform script that you use to create the key:



1. Initialize the Terraform CLI.

./terraform init
2. Create a Terraform execution plan.

./terraform plan
3. Create the resources.

./terraform destroy









 Troubleshooting 



 Failed to query available provider packages 

If you get the following error:
For more information about ibm_cd_toolchain, see the argument reference details in the [Terraform Registry Documentation](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/cd_toolchain).
3. Initialize the Terraform CLI.

terraform init
4. Create a Terraform execution plan. This plan summarizes all of the actions that must run to create a toolchain.

terraform plan
5. Apply the Terraform execution plan. Terraform takes all of the required actions to create the toolchain.

terraform apply







 Viewing a toolchain 

You can view a toolchain by using the console, from the CLI, with the API, or with Terraform.



 Viewing a toolchain by using the console 

After you configure the toolchain and its tool integrations, you can view a visual representation of the toolchain.

You can view a toolchain from an app by clicking the toolchain name from your app's Details page.



1. From the IBM Cloud console, click the menu icon ![hamburger icon](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/icon_hamburger.svg), and select DevOps.
2. On the Toolchains page, select a Resource Group and Location. All of the toolchains that are contained within the selected resource group and location are displayed. Click the toolchain that you want to view to open its Overview page. Alternatively, on the App details page in your app, click the toolchain name.
3. To access a tool integration that is in your toolchain, go to the appropriate card, such as Delivery pipelines, and then click the tool integration.

You can also find your toolchains within the Developer tools category of the [Resource list](https://cloud.ibm.com/resources).
If you prefer to create the storage custom image with your own settings and configurations, follow the instructions that are provided [here](https://github.com/IBM-Cloud/hpc-cluster-symphony/tree/main/custom_image/storagereadme).





 Step 4: Gather Spectrum software entitlement information 

The offering uses the Bring Your Own License (BYOL) model for Spectrum software when you deploy an HPC cluster on IBM Cloud. This applies to IBM Spectrum Symphony in all cases and to IBM Spectrum Scale if you decide to use that for the HPC cluster storage instead of just NFS. Work with your business owners or license management team to make sure that your organization has procured enough licenses to deploy the HPC cluster using the Spectrum software. Failure to comply with licenses for production use of software is a violation of the [IBM International Program License Agreement](https://www.ibm.com/software/passportadvantage/programlicense.html).





 Step 5: Next steps 

After you've gathered the necessary input values to define your cluster configuration, you are ready to deploy your IBM Spectrum Symphony cluster. The Spectrum Symphony cluster can be deployed on IBM Cloud by using the IBM Cloud catalog, Schematics CLI, or the Schematics APIs. If you want to deploy your cluster by using the CLI or API, review the prerequisites for your interface of choice:



* [Setting up the IBM Cloud Schematics CLI](https://cloud.ibm.com/docs/hpc-spectrum-symphony?topic=hpc-spectrum-symphony-setting-up-cli)
* [Setting up the IBM Cloud Schematics API](https://cloud.ibm.com/docs/hpc-spectrum-symphony?topic=hpc-spectrum-symphony-setting-up-api)



After you've created and gathered your information and reviewed any additional prerequisites for your interface of choice, you are ready to begin [Creating a workspace](https://cloud.ibm.com/docs/hpc-spectrum-symphony?topic=hpc-spectrum-symphony-creating-workspace).
Flag Required / Optional Description 

 --id or -i Required The unique ID of the workspace where you want to run the commands. To find the ID of your workspace, run ibmcloud schematics workspace list command. 
 --file or --f Required Path to the JSON file containing the list of Terraform commands. 



Sample payload of Test.JSON file:

{
"commands": [
{
"command": "state show",
"command_params": "data.template_file.test",
"command_name": "Test1",
"command_desc": "Showing state",
"command_onerror": "continue"
},
{
"command": "taint",
"command_params": "null_resource.sleep",
"command_name": "Test2",
"command_desc": "Marking taint",
"command_onerror": "continue"
},
{
"command": "untaint",
"command_params": "null_resource.sleep",
"command_name": "Test3",
"command_desc": "Marking untaint",
"command_onerror": "continue"
},
{
"command": "state list ",
"command_params": "",
"command_name": "Test4",
"command_desc": "Checking state list",
"command_onerror": "continue"
},
{
"command": "state rm ",
"command_params": "data.template_file.test",
"command_name": "Test5",
"command_desc": "Removing state",
"command_onerror": "continue"
}
],
"operation_name": "workspace Command",
"description": "Executing command"
}
Show more
VRVDR-52404 Major ICMP error returned with corrupted inner header causes seg-fault when passed through a FW/NAT44/PBR rule with logging enabled 
 VRVDR-52401 Critical Degradation of throughput by 10%-40% on v150 with 100M physical interface & QOS 
 VRVDR-52221 Major Disabled PMTUD on GRE tunnel causes outer packet to inherit inner packet TTL value 
 VRVDR-52179 Critical Overlayfs file corruption of user accounting files 
 VRVDR-52152 Critical PTP: Use monotonic time for semaphores and mutexes 
 VRVDR-51643 Major SNMP Trap not receiving when CHILD_SA deleting 
 VRVDR-51465 Blocker Restore (opt-out) collection of shell history in tech-support 
 VRVDR-51455 Critical Bad file descriptor (src/epoll.cpp:100) when applying config 
 VRVDR-51443 Major IPv6 router-advert CLI missing on switch VLAN interfaces 
 VRVDR-51332 Major PTP: Unable to cope with config change where master and slave swap ds-ports (slave does not come up) 
 VRVDR-50884 Major Grub passwd printed in plain-text in installer logs 
 VRVDR-50619 Major LACP with VIF - still seeing Slaves not selected in 'balanced' mode 
 VRVDR-50544 Critical Opd logging YANG files missing in Edinburgh (VNF), Fleetwood onwards (VR and VNF) 
 VRVDR-50313 Major PTP: SIAD does not send "Follow_Up" msgs to slaves when two-step- flag is enabled 
 VRVDR-50026 Critical Dataplane crash: npf_timeout_get() 
 VRVDR-49447 Major show tech-support still logs /var/log/messages 
 VRVDR-49409 Major Dataplane reports that the bonding drivers doesn't support vlan filtering 
 VRVDR-49209 Minor tech-support should not use any user gpg config when encrypting tech support archives
: If VALUE is not given, the '--default' flag is to be specified to indicate resetting the configuration value back to the default. Multiple '--config' options can be specified. Each '--config' option can specify a semicolon-delimited list of assignments. The following list shows valid configuration keys:



* cleanup.policy
* retention.ms
* retention.bytes
* segment.bytes
* segment.ms
* segment.index.bytes



--default, -d (optional)
: Reset each configuration parameter that is specified by using '--config' to its default value.





 ibmcloud es topics 

List topics.

ibmcloud es topics [--filter FILTER] [--json]

Prerequisites: None

Command options:

--filter value, -f value (optional)
: Topic name.

--json (optional)
: Format output in JSON. Up to 1000 topics are returned.





 ibmcloud es group 

Display details of a consumer group.

ibmcloud es group [--group] GROUP_ID [--json]

>Prerequisites: None

Command options:

--group value, -g value
: Consumer group ID.

--json (optional)
: Format output in JSON.





 ibmcloud es group-reset 

Reset the offsets for a consumer group.

ibmcloud es group-reset [--group] GROUP_ID [--topic TOPIC_NAME] [--all-topics] --mode MODE --value VALUE [--dry-run] [--execute] [--json]

Prerequisites: None

Command options:

--group value, -g value
: Consumer group ID

--topic value, -t value
: Topic name. Apply to just this topic. Omit if '--all-topics' flag was supplied.

--all-topics, -a
: Apply to all topics assigned to the group.
For more information, see [Script settings](https://helpcenter.veeam.com/docs/backup/vsphere/backup_job_advanced_scripts_vm.html?ver=120) and [New-PSSession](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/new-pssession?view=powershell-7.2).

The New-PSSession module requires PowerShell 7. For more information, see [Installing the MSI package](https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-windows?view=powershell-7.2msi).

Another option is to use the Posh-Junos® PowerShell module to interface with the vSRX directly from the Veeam backup server. For more information, see [Scripting how to: Windows® PowerShell](https://community.juniper.net/browse/blogs/blogviewer?blogkey=0903395c-8f62-433d-be52-ad636d75ed9c).



 Opening and closing the airgap 

The document does not describe the configuration of the Juniper vSRX. You must create the required configuration. The playbook assumes that the vSRX configuration includes the following items:



* A user, called sa-ansible, with an SSH key.



* Set system login user sa-ansible uid 2002
* Set system login user sa-ansible class super-user
* Set system login user sa-ansible authentication ssh-rsa <public_key>



* NETCONF is enabled.



* Set system services netconf ssh port 830
* Set firewall filter PROTECT-IN term NETCONF from destination-address <vSRX_private_ip>/32
* Set firewall filter PROTECT-IN term NETCONF from protocol TCP
* Set firewall filter PROTECT-IN term NETCONF from destination-port 830
* Set firewall filter PROTECT-IN term NETCONF then accept
When you create a workspace, IBM Cloud Schematics automatically parses through your Terraform configuration files to find variable declarations.

What information do I need to include in my variable declaration?

When you declare an input variable, you must provide a name for your variable and the data type according to the Terraform version. You can optionally provide default value for your variable. When input variables are imported into Schematics and a default value is specified, you can choose to overwrite the default value. \n IBM Cloud Schematics accepts the values as a string for primitive types such as bool, number, string, and HCL format for complex variables.



* Terraform v0.12 supports string, list, map, bool, number, and complex data types such as list(type), map(type), object({attribute name=type,.}), set(type), tuple([type]).



Is there a character limit for input variables?

Yes. If you define input variables in your Terraform configuration file, keep in mind that the value that you enter for these variables can be up to 2049 characters. If your input variable requires a value that exceeds this limit, the value is truncated after 2049 characters.

Example variable declaration without a default value.

variable "datacenter" {
type = "string"
description = "The data center that you want to deploy your Kubernetes cluster in."
}

Example variable declaration with a default value.

variable "datacenter" {
type = "string"
description = "The data center that you want to deploy your Kubernetes cluster in."
default = "dal10"
}



 Referencing variables 

You can reference the value of the variable in other blocks of your Terraform configuration files by using the "${var.<variable_name>}" syntax.

Example for referencing a datacenter variable.

resource ibm_container_cluster "test_cluster" {
name = "test"
datacenter = var.datacenter
}







 Providing values to IBM Cloud Schematics for the declared variables