vania-janet/multiturn-rag-retrieval-data huggingface dataset:
If the peer box is checked, every peer will be included in the ZIP, and likewise for other components.
* If a console has already imported some of the information contained in a bulk transfer, for example a few of the peers, duplicate representations of these components will appear in the console after performing the import. These duplicates do no harm, but it is a best practice to only have one representation of a component at a time. The same duplication will not occur when importing ordering nodes.
* The Identities box is left deselected in the export panel by default for reasons we discussed earlier: these identities contain private keys, therefore it is inadvisable to export them unless it is necessary to do so. Also, unlike MSPs and nodes, the console does not permit duplicate identities. If you attempt to import a bulk data ZIP that includes an identity that already exists in your console, the import will fail. Note once again that all identities will be sent in the bulk transfer, regardless of the other boxes you check. For example, if you only leave the peer box selected, and select identities, every identity in your Wallet will be sent, not just the identities relevant to the peer.
* However, if you do choose to export identities along with nodes, the associations between identities and nodes will persist along with the transfer. That is, you will not have to perform the extra step of clicking on nodes and associating an admin identity with them.
* It is necessary that all of the members of a channel have the MSPs of all of the other members of a channel to allow for the validation of signatures. However, note that by selecting the MSPs button, all MSPs in your console would be exported, not just the MSPs relevant to a particular channel.



If you import a bulk data transfer of nodes and do not also import identities, you will have to perform the separate step of associating identities with the nodes. There are a few ways to procure an identity that can operate a node. For more information about, see [Gathering certificates or credentials](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-import-nodesibp-console-import-start-here).
* node_modules: created by node.js



10. Click Finished to close the Add new LoopBack project dialog box.
11. Exit API Designer by returning to the command window and entering Ctrl + C. Type Y to confirm the exit.
12. Close the browser session.









 Add a data source and model 

To add a model and data source to a LoopBack project using API Designer, complete the following steps:



 Add a data source 

To add a data source to a LoopBack project using API Designer, complete the following steps.



1. You must also create a LoopBack project (the "weather-data" project) as described in Create a LoopBack project from the command line and make sure that the current working directory is the project root directory:

cd weather-data
2. From the command line, enter the following command:

apic edit

After a brief pause, the console displays this message:

Express server listening on http://127.0.0.1:9000

API Designer opens in your default web browser, initially displaying the login page if you haven't logged in recently.
You can log in using your IBM Cloud account or create one.
3. Click ![Data Sources icon](https://cloud.ibm.com/docs-content/v1/content/78bb71851d95d7580503eb9ba10cf3ae31490ade/apiconnect/tutorials/images/datasource-icon.png).
4. Click Add. The "New LoopBack Data Source" window opens.
5. Enter weatherDS in the Name text field. Use any alphanumeric characters, dashes, and underscores in a data source name.
6. Click New.
7. By default, the Connector setting shows In-memory db and the other settings are blank. Keep the default settings for now, and API Designer automatically saves the new data source. The In-memory data source is built into LoopBack and is suitable only for development and initial testing.
--scale-down-unneeded-time=10m
--scale-down-delay-after-add=10m
--scale-down-delay-after-delete=10m
--scale-down-utilization-threshold=0.5
--scan-interval=1m
--expander=random
--leader-elect=false
--max-node-provision-time=120m







 Step 5: Search the pod logs 

Search the logs of the cluster autoscaler pod for relevant messages, such as failure messages like lastScaleDownFailTime, the Final scale-up plan, or [cluster autoscaler events](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.mdwhat-events-are-emitted-by-ca).

If your cluster autoscaler pod is unhealthy and can't stream logs, check your [IBM® Log Analysis instance](https://cloud.ibm.com/observe/logging) for the pod logs. Note that if your cluster administrator did not [enable Log Analysis for your cluster](https://cloud.ibm.com/docs/containers?topic=containers-health), you might not have any logs to review.

oc logs -n kube-system <pod_name> > logs.txt





 Step 5: Restart the pod 

If you don't find any failures or error messages and you already enabled logging, restart the cluster autoscaler pod. The deployment re-creates the pod.

oc delete pod -n kube-system <pod_name>





 Step 6: Disable and reenable 

Optional: If you completed the debugging steps and your cluster still does not scale, you can disable and reenable the autoscaler by editing the config map.



1. Edit the iks-ca-configmap.

oc edit cm iks-ca-configmap -n kube-system

Example output:

apiVersion: v1
data:
workerPoolsConfig.json:
You can get the Git commit ID by using the command sh(returnStdout: true, script: 'Git rev-parse HEAD').trim().





 DevOps Insights steps 

The Cloud DevOps plug-in adds four steps to Jenkins pipelines for you to use. Use these steps in your pipelines to interact with DevOps Insights. Add these steps to your pipeline definition wherever you need them to run. For example, you might upload test results after you run a test, and then evaluate those results at a gate after they are uploaded.



Table 3. DevOps Insights steps and uses

 Step Use 

 publishBuildRecord Publishes build information 
 publishTestResult Publishes test results 
 publishDeployRecord Publishes deployment records 
 evaluateGate Enforces policies 



By default, the version number is set to be {pipeline name}:{build number}, you can also set the custom version number in each step





 Sample pipeline and code 

Here are two complete pipeline examples that are defined as [declarative Jenkins file](https://github.com/jenkinsci/ibm-cloud-devops-plugin/blob/master/Declarative-Jenkinsfile) and a [scripted Jenkins file](https://github.com/jenkinsci/ibm-cloud-devops-plugin/blob/master/Scripted-Jenkinsfile).

The [Git repo](https://github.com/devops-insights/DemoDRA) contains a sample nodejs application code, tests, and Jenkins file that you can experiment with. Fork the repo and modify the Jenkins file with your actual information.

If you didn't install NodeJS in your Jenkins environment, you might have to install the node.js Jenkins plug-in. If you installed NodeJS, you can comment out the "tools" section in the Jenkins file.





 Viewing Build Frequency 

When this build job completes, the pipeline publishes a message to DevOps Insights that a build is complete. You can view the build record on the Build Frequency page. To view the Build Frequency page, use the following steps.



1.
--scale-down-unneeded-time=10m
--scale-down-delay-after-add=10m
--scale-down-delay-after-delete=10m
--scale-down-utilization-threshold=0.5
--scan-interval=1m
--expander=random
--leader-elect=false
--max-node-provision-time=120m







 Step 5: Search the pod logs 

Search the logs of the cluster autoscaler pod for relevant messages, such as failure messages like lastScaleDownFailTime, the Final scale-up plan, or [cluster autoscaler events](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.mdwhat-events-are-emitted-by-ca).

If your cluster autoscaler pod is unhealthy and can't stream logs, check your [IBM® Log Analysis instance](https://cloud.ibm.com/observe/logging) for the pod logs. Note that if your cluster administrator did not [enable Log Analysis for your cluster](https://cloud.ibm.com/docs/containers?topic=containers-health), you might not have any logs to review.

kubectl logs -n kube-system <pod_name> > logs.txt





 Step 5: Restart the pod 

If you don't find any failures or error messages and you already enabled logging, restart the cluster autoscaler pod. The deployment re-creates the pod.

kubectl delete pod -n kube-system <pod_name>





 Step 6: Disable and reenable 

Optional: If you completed the debugging steps and your cluster still does not scale, you can disable and reenable the autoscaler by editing the config map.



1. Edit the iks-ca-configmap.

kubectl edit cm iks-ca-configmap -n kube-system

Example output:

apiVersion: v1
data:
2. Set a Time frame to specify the number of seconds to gather data. The default capture time is 15 seconds. The maximum capture time is 86400 seconds (24 hours).
3. (Optional) Add a filter to restrict the amount of trace information that is collected.



6. Click START CAPTURE. The monitoring agent is signaled to start a capture, and send back the resulting trace file.
7. Click Go to captures page to display the list of captures in the Captures section of the web UI.



The Captures page shows a table that lists the capture file name, the host it was retrieved from, the time frame, and the size of the capture.

The status of a capture file can be any of the following values:



* Requested: A file is being generated.
* Uploaded: A file is available for download, and analysis.
* Error: A file is not available due to a timeout, data that was never received, or an agent error.







 Deleting a capture 

Complete the following steps to delete a capture file:



1. Navigate to the Captures section in the web UI. [Learn more](https://cloud.ibm.com/docs/monitoring?topic=monitoring-launchlaunch).
2. Identify and select the capture file that you want to delete.
3. Click Delete.







 Exploring a capture 

Complete the following steps to explore a capture file:



1. Navigate to the Captures section in the web UI. [Learn more](https://cloud.ibm.com/docs/monitoring?topic=monitoring-launchlaunch).
2. Identify and select the capture file that contains the data for the host that you want to analyze.
3. Click EXPLORE.







 Downloading a capture 

Complete the following steps to download a capture file:



1. Navigate to the Captures section in the web UI. [Learn more](https://cloud.ibm.com/docs/monitoring?topic=monitoring-launchlaunch).
2. Identify and select the capture file that contains the data that you want to download.
3.
The calico-cni also applies any changes to logging levels in the kube-system/calico-config ConfigMap.<-- </ol> --><-- </section "id="section-calico-increase-logging-node" "> --><-- <section "id="section-calico-increase-logging-kube-controllers" "> --> Increasing the log level for the calico-kube-controllers components Complete the following steps to increase the log level for the calico-kube-controllers component.<-- <ol> -->1. Edit the daemonset by running the following command.
oc edit ds calico-node -n calico-system
2. Under the DATASTORE_TYPE name and value pair, add the following entry.
- name: LOG_LEVEL
value: debug
3. Save the change. The calico-kube-controllers pod restarts and applies the changes.<-- </ol> --><-- </section "id="section-calico-increase-logging-kube-controllers" "> --><-- <section "id="section-calico-log-gather" "> --> Gathering Calico logs <-- <ol> -->1. List the pods and nodes in your cluster and make a node of the pod name, pod IP address, and worker node that has the issue.2. Get the logs for the calico-node pod on the worker node where the problem occurred.
oc logs calico-typha-aaa11111a-aaaaa -n calico-system
3. Get logs for the calico-kube-controllers pod.
oc logs calico-kube-controllers-11aaa11aa1-a1a1a -n calico-system
4. Follow the instructions for Debugging by using oc exec]] ! ! ! ! !
You can find the list of nodes, organizations, and channels that belong to the network in the Fabric Environments pane. Above these nodes, you can find the list of smart contracts that are deployed on your channels.

Use the following steps to create a new one organization or two organization network:



1. Ensure that Docker is running on your machine.
2. Hover your mouse over the Fabric Environments pane and click +, Add Environment.
3. Select Create new from template.
4. Select 1 Org template (1 CA, 1 peer, 1 channel). Alternatively, if you want a larger network or have generated a Private Data Contract then select 2 Org template (2 CAs, 2 peers, 1 channel).
5. Select V2_0 when asked to choose the channel capability version to use for the network. Alternatively, if you wish to have v1 channel capabilities select the other option.



This will then take a few minutes to create a local Fabric network including the environment, gateways, and wallets.



 Stopping, restarting, tearing down and deleting a preconfigured network 

You can stop or restart the preconfigured network while it is running:



1. In the Fabric Environments pane, click the overflow menu.
2. Select Restart, Stop, Teardown to stop, restart, or teardown the container.



Selecting Teardown will completely remove the local Fabric network. Note: This removal results in the loss of the ledger and world state data.

Selecting Delete will perform a Teardown as well as remove the network from the Fabric Environments pane.







 Deploying your smart contract (channel application capability V2) 

Smart contracts can be deployed by using the deploy view. This view handles all the deployment steps (install, approve, commit) which are required by the smart contract lifecycle on channels that are enabled with application capability v2.0 or higher.

Follow these steps if you have your channel is configured with application capability V2 or higher and a .tar.gz smart contract package.

To launch the deploy view:



1. Check that you are connected to the network in the Fabric Environments pane.
2.
Before attempting to deploy a node, it is the network operator's responsibility to monitor the cluster CPU, memory, and storage usage, and ensure that adequate resources are available in the cluster for the node.



 Allocating resources 

Because your instance of the IBM Blockchain Platform console and your Kubernetes cluster do not communicate directly about the resources that are available, the process for deploying components by using the console must follow this pattern:



1. Size the deployment that you want to make. The Resource allocation panels for the CA, peer, and ordering node in the console offer default CPU, memory, and storage allocations for each node. You may need to adjust these values according to your use case. If you are unsure, start with default allocations and adjust them as you understand your needs. Similarly, the Resource reallocation panel displays the existing resource allocations. For a sense of how much storage and compute you will need in your cluster, refer to the chart after step 3 that contains the current defaults for the peer, orderer, and CA:
2. Check whether you have enough resources in your Kubernetes cluster. If you are using a Kubernetes cluster that is hosted in IBM Cloud, we recommend using the [IBM Cloud Monitoring](https://www.ibm.com/cloud/cloud-monitoring) tool in combination with your IBM Cloud Kubernetes dashboard. If you do not have enough space in your cluster to deploy or resize resources, you need to increase the size of your cluster. For more information about how to increase the size of a cluster, see scaling [Kubernetes](https://cloud.ibm.com/docs/containers?topic=containers-caca) or [OpenShift](https://cloud.ibm.com/docs/openshift?topic=openshift-ca) clusters. If you have enough space in your cluster, you can continue with step 3.
3. Use the console to deploy or resize your node. If your Kubernetes pod is large enough to accommodate the new size of the node, the reallocation should proceed smoothly.
4. Change to the directory where you downloaded the Prometheus Windows exporter.
5. Run the windows_exporter and configure the collectors that you want to enable. For example:

.windows_exporter-0.16.0-amd64.exe --collectors.enabled <COLLECTORS>

Where <COLLECTORS> indicates the list of connectors that you want to configure.

For example, to collect computer system metrics (cs), CPU metrics, disk metrics and network interface I/O metrics, see the following example:

.windows_exporter-0.16.0-amd64.exe --collectors.enabled "os,cpu,logical_disk,net,system"







 Step 2: Configure network settings 

Complete the following steps:



1. Enable the Windows firewall to allow access to windows_exporter-0.16.0-amd64.exe.
2. [Optional] Update the VPC rules

If you use private endpoints, add an inbound rule to the security group for port 9182 with source type = Security Group and choose the security group for the Windows system.







 Step 3: Choose the method to collect metrics 



 Option 1. Collect metrics by running a monitoring agent on a Linux system 

Run a monitoring agent on a Linux system and remotely scrape the Windows endpoint.

Complete the following steps:



1. [Install the monitoring agent on a Linux node](https://cloud.ibm.com/docs/monitoring?topic=monitoring-config_agentconfig_agent_linux).

You can collect a maximum of 3000 time series per Linux agent. If you need to collect more than 3000 time series for all your Windows systems, you need more than one Linux agent.
2. Update the /opt/draios/etc/dragent.yml to [enable remote scraping](https://docs.sysdig.com/en/docs/installation/prometheus-remote-write/).

prometheus:
enabled: true
interval: 30
log_errors: true
The --start option also starts the cluster service on the nodes.

On NODE1, run the following command.

pcs cluster setup ${CLUSTERNAME} --start ${NODE1} ${NODE2}

pcs status





 Creating the fencing device 

STONITH is an acronym for "Shoot The Other Node In The Head" and protects your data from corruption in a split brain situation.

STONITH (fencing) must be enabled for a RHEL HA Add-On production cluster.

Fence agent fence_ibm_powervs is the only supported agent for a STONITH device on Power Systems Virtual Server clusters.

The fence agent connects to the [Power Cloud API](https://cloud.ibm.com/apidocs/power-cloud) by using parameters APIKEY, IBMCLOUD_CRN, CLOUD_REGION, GUID, and the instance IDs POWERVSI_01 and POWERVSI_02. You can test the agent invocation by using the parameters that were gathered in the [Gathering required parameters for the cluster configuration](https://cloud.ibm.com/docs/sap?topic=sap-ha-rhelha-rhel-gather-parameters-for-cluster-config) section.





 Identifying the virtual server instances for fencing 

Use the list option of fence_ibm_powervs to identify and or verify the instance IDs of the two cluster nodes:

On any node, run the following command.

fence_ibm_powervs --token=${APIKEY} --crn=${IBMCLOUD_CRN} --instance=${GUID} --region=${CLOUD_REGION} --api-type=public -o list

If the virtual server instances have access to only a private network, you must use the --api-type=private option, which also requires an extra --proxy option.

Example:

fence_ibm_powervs --token=${APIKEY} --crn=${IBMCLOUD_CRN} --instance=${GUID} --region=${CLOUD_REGION} --api-type=private --proxy=http://${PROXY_IP}:3128 -o list
The calico-cni also applies any changes to logging levels in the kube-system/calico-config ConfigMap.<-- </ol> --><-- </section "id="section-calico-increase-logging-node" "> --><-- <section "id="section-calico-increase-logging-kube-controllers" "> --> Increasing the log level for the calico-kube-controllers components Complete the following steps to increase the log level for the calico-kube-controllers component.<-- <ol> -->1. Edit the daemonset by running the following command.
kubectl edit ds calico-node -n kube-system
2. Under the DATASTORE_TYPE name and value pair, add the following entry.
- name: LOG_LEVEL
value: debug
3. Save the change. The calico-kube-controllers pod restarts and applies the changes.<-- </ol> --><-- </section "id="section-calico-increase-logging-kube-controllers" "> --><-- <section "id="section-calico-log-gather" "> --> Gathering Calico logs <-- <ol> -->1. List the pods and nodes in your cluster and make a node of the pod name, pod IP address, and worker node that has the issue.2. Get the logs for the calico-node pod on the worker node where the problem occurred.
kubectl logs calico-typha-aaa11111a-aaaaa -n kube-system
3. Get logs for the calico-kube-controllers pod.
kubectl logs calico-kube-controllers-11aaa11aa1-a1a1a -n kube-system
4. Follow the instructions for Debugging by using kubectl exec]] ! ! ! ! !
Use the following command in the source directory to run steps 4 and 5 inside the container.

docker run --rm -it --entrypoint "/bin/bash" -v $PWD:/nodejsAction ibmfunctions/action-nodejs-v16:1.0.2 -c "npm run prebuild && npm run build"
6. Create the action by using the npm script or the ibmcloud fn action update CLI.



* Run the following npm script.

npm run deploy
* Or run the following IBM Cloud CLI command.

ibmcloud fn action update my-action dist/bundle.js --kind nodejs:12



The bundle file that is built by webpack supports only JavaScript dependencies. Action invocations might fail if the bundle has other dependencies because these dependencies are not included with the file bundle.js.
7. You can clean up the generated artifacts package-lock.json, node_modules and dist by using one of the following options.

npm run clean

or

docker run --rm -it --entrypoint "/bin/bash" -v $PWD:/nodejsAction ibmfunctions/action-nodejs-v16:1.0.2 -c "npm run clean"







 Packaging JavaScript code as NPM files 

As an alternative to writing all your action code in a single JavaScript source file, you can package your code as a npm package in a compressed file.

Before you begin, [review the packages that are included with the JavaScript runtime](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-runtimesopenwhisk_ref_javascript_environments) 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. In the root directory, create the package.json and my-action.js file.