vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Working with IBM Cloud's carbon calculator 

Output that is provided by the carbon calculator is provided “as-is” for informational purposes only, and is based on cloud services information that are provisioned by client in client’s IBM Cloud account. Output is provided in a format according to GHG protocol standards. The data sources and tools used to calculate client's emissions are subject to change by IBM without notice. Client is responsible for confirming accuracy of any calculator output for purposes of client’s compliance with any applicable regulatory obligations or for any other purpose

IBM Cloud's carbon calculator displays the carbon emissions for an account by monitoring your electricity consumption for services, resources, and the location and efficiency of your data centers. Tracking your carbon emissions is important so that you can know how much carbon emissions your account is associated with, and it helps you manage and mitigate your carbon footprint over time.

Emissions data is currently tracked for a subset of services, but more services are under consideration to be added. Emission data is currently available for the following services:



* Bare Metal Servers for Classic
* Bare Metal Servers for VPC
* Cloud HSM
* Cloud Object Storage
* FortiGate Security Appliance 10Gbps
* Kubernetes Service
* Load Balancers for Classic
* Virtual Server for Classic
* Virtual Server for VPC



Because emissions are reported after the close of each billing cycle, data for newly added services and current quarter results take about two months to populate.

The carbon calculator provides a wide range of features to track your carbon emissions:



* View total emissions by service, resource group, and location.
* Filter emissions data by time period, service, or location.
* Best practices for cloud sustainability.
* Export data as a CSV file for additional analyses



All service workloads across all sites are metered for electricity consumption or estimations based on hardware profiles. Service usage is also tracked by account, location, and over time. Data is then processed to produce a standards-based carbon emission estimate for each account per service, per location, and resource group.



 Before you begin
Intel Xeon v3 Servers are recommended along with redundant uplinks, redundant power supplies, and RAID-1 for local (boot) disks.
2. Most customers with VMWare follow an N+1 hard capacity ceiling (all VMs can be comfortably allocated to servers with a single node removed (for maintenance/failure/etc).
3. Many customers want a higher "soft ceiling" of 80% (80% capacity on the 'n' server configuration) compared to the more standard 60-75% due to the short turn around of compute.
4. External OS Licensing (such as Microsoft, Red Hat) might be needed for vSphere guests from an external vendor.
5. Review [Performance Best Practices for VMware vSphere](https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-perfbest-practices-vsphere6-0-white-paper.pdf)



9. Design the vCenter Server:



1. Typically, a midsized virtual server instance is the entry point for small environments (8 vCPU + 16 GB RAM). While bare metal is used for larger environments.
2. vCenter can be deployed on a stand-alone virtual server instance Windows virtual machine as an OS add-on or as an appliance.



* Reference Links:



* [vCenter Server requirements for installation](https://kb.vmware.com/s/article/2107948)
* [VMware vCenter Server Performance and Best Practices](https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-vcenter6-performance-white-paper.pdf)
* [Deploying and Configuring a vCenter Server Appliance (vCSA) with VMware vSphere](https://cloud.ibm.com/docs/vmware?topic=vmware-config-vcsa)







10. Non-VMWare servers.
Part 2: Set up a Continuous Integration (CI) toolchain 

This tutorial is part 2 of a 4-part tutorial series where you learn IBM Cloud® DevSecOps best practices by using a complete reference implementation that is available as a service and powered by IBM Cloud® Continuous Delivery. In part 2 of this tutorial series, you use the toolchain template for continuous integration (CI) with security and compliance-related best practices in DevSecOps. It is preconfigured for continuous deployment with inventory integration, change management with Git Repos and Issue Tracking, evidence collection, and deployment to IBM Cloud Kubernetes Service.



 Before you begin 

Before you begin part 2 of this tutorial series, ensure that you complete the following prerequisites:



1. Complete [Part 1: Set up prerequisites](https://cloud.ibm.com/docs/devsecops?topic=devsecops-tutorial-cd-devsecops).
2. View the [Getting started with DevSecOps in IBM Cloud - Part 1](https://video.ibm.com/embed/recorded/130714354) video.
3. Start the [IBM Cloud console](https://cloud.ibm.com/). The console is the starting point of this tutorial.







 Continuous Integration (CI) toolchain introduction 

The CI toolchain implements the following best practices:



* Runs a static code scanner on the application repositories to detect secrets in the application source code and vulnerable packages that are used as application dependencies
* Builds a container image on every Git commit, setting a tag based on build number, timestamp, and commit ID for traceability
* Tests the Dockerfile before the image is created
* Stores the built image in a private image registry
* Automatically configures access permissions for target cluster deployment by using API tokens that can be revoked
* Scans the container image for security vulnerabilities
* Adds a Docker signature upon successful completion
* Inserts the built image tag into the deployment manifest automatically
The level of availability that is right for you depends on several factors, such as your business requirements, the Service Level Agreements that you have with your organizations, and the cost of redundancy.

Before proceeding, we recommend that you learn more about HA on Kubernetes by reviewing High availability for the [IBM Cloud Kubernetes service](https://cloud.ibm.com/docs/containers?topic=containers-ha) or [OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-ha).

Then, you can use this topic for details on blockchain-specific HA guidance along with the recommendations from the platform-specific topic above.



 Overview of potential points of failure in IBM Blockchain Platform 

The IBM Blockchain Platform architecture is designed to ensure reliability, low latency processing, and a maximum uptime of the service. However, failures can happen. IBM Blockchain Platform provides several approaches to add more availability to your cluster by adding redundancy and [anti-affinity](https://www.ibm.com/blogs/cloud-archive/2016/07/ibm-containers-anti-affinity/) policies. Anti-affinity ensures that blockchain components of the same type and organization are deployed across different worker nodes. By adding redundancy across your blockchain network, you can avoid failures or downtime.

To achieve maximum high availability, it is recommended that you build redundancy by provisioning peers and orderers in Kubernetes clusters in multiple regions. When the components are spread across regions and the blockchain ledger is distributed across those components, a failure in any single region will not impact processing of transactions. CAs are less critical for daily transaction processing. After all the users have been registered and enrolled with the CA, it is no longer required until the next time those services are required.



 Peer considerations 

HA for peers means always having redundant peers, that is at least two peers available for each organization on the same channel to process requests from client applications. Multiple peers can be deployed to a single worker node, or spread across worker nodes, zones (if you are using IBM Cloud), or even regions.
Why does my PVC remain in a pending state? 

[

 What’s happening 

When you create a PVC and you run kubectl get pvc <pvc_name>, your PVC remains in a Pending state, even after waiting for some time.

 Why it’s happening 

During the PVC creation and binding, many different tasks are executed by the IBM Cloud Object Storage plug-in. Each task can fail and cause a different error message.

 How to fix it 

Describe your PVC and review the common error messages.



1. Find the root cause for why the PVC remains in a Pending state.

kubectl describe pvc <pvc_name> -n <namespace>
2. Review common error message descriptions and resolutions.





Block Storage error messages

 Error message Description Steps to resolve 

 can't get credentials: can't get secret <secret_name>: secrets "<secret_name>" not found The Kubernetes secret that holds your IBM Cloud Object Storage service credentials does not exist in the same namespace as the PVC or pod. See [PVC or pod creation fails due to not finding the Kubernetes secret](https://cloud.ibm.com/docs/containers?topic=containers-cos_secret_access_fails). 
 can't get credentials: Wrong Secret Type.Provided secret of type XXXX.Expected type ibm/ibmc-s3fs The Kubernetes secret that you created for your IBM Cloud Object Storage service instance does not include the type: ibm/ibmc-s3fs. Edit the Kubernetes secret that holds your IBM Cloud Object Storage credentials to add or change the type to ibm/ibmc-s3fs. 
 Bad value for ibm.io/object-store-endpoint XXXX: scheme is missing. Must be of the form http://<hostname> or https://<hostname>Bad value for ibm.io/iam-endpoint XXXX: scheme is missing.
You specify the storage class with the blockStorageClass property of the Speech services custom resource. For more information about all supported storage classes, see the following topics in [Watson Speech services on IBM Cloud Pak for Data](https://www.ibm.com/docs/en/cloud-paks/cp-data/4.6.x?topic=services-watson-speech):



* Before you begin in Installing Watson Speech services
* Specifying a storage class in Using the Watson Speech services custom resource



Known issue: Some Watson Speech services pods do not have annotations that are used for scheduling
: Known issue: Some Watson Speech services pods are missing the cloudpakInstanceId annotation. If you use the IBM Cloud Pak for Data scheduling service, any Watson Speech services pods without the cloudpakInstanceId annotation are



* Scheduled by the default Kubernetes scheduler rather than the scheduling service
* Not included in the quota enforcement



Monitoring of the PostgreSQL datastore is now available
: You can now enable monitoring of the PostgreSQL datastore to receive updates on its usage and status by the Watson Speech services. The events can be consumed by Prometheus monitoring software or whatever application you use for monitoring. By enabling monitoring for user-defined projects in addition to the default platform monitoring, you can monitor your own projects with the Red Hat® OpenShift® Container Platform monitoring stack. This capability includes an additional property, spec.global.datastores.postgressql.enablePodMonitor, in the Speech services custom resource.

For more information, see the topic Monitoring the PostgreSQL datastore for Watson Speech services in the Administering section of [Watson Speech services on IBM Cloud Pak for Data](https://www.ibm.com/docs/en/cloud-paks/cp-data/4.6.x?topic=services-watson-speech).

Defect fix: PostgreSQL datastore is no longer installed if only runtime microservices are enabled
: Defect fix: The PostgreSQL datastore is no longer installed if only the runtime microservices are enabled.
For more information about importing standard keys, check out [Importing standard keys](https://cloud.ibm.com/docs/key-protect?topic=key-protect-import-standard-keys).





 Using Key Protect 



* If you added a root key to the service, learn more about using the root key to protect the keys that encrypt your data at rest by checking out [Wrapping keys](https://cloud.ibm.com/docs/key-protect?topic=key-protect-wrap-keys).
* To find out more about integrating the Key Protect service with other cloud data solutions, check out the [Integrations](https://cloud.ibm.com/docs/key-protect?topic=key-protect-integrate-services) documentation.
* To find out more about programmatically managing your keys, check out the [Key Protect API reference](https://cloud.ibm.com/apidocs/key-protect) documentation.





 Best practices for using Key Protect 

While the best way to use Key Protect ultimately depends on the needs of your use case, there are a number of best practices to keep in mind that are specific to Key Protect. These recommendations are in addition to the general best practices that should be observed when using any IBM Cloud or IBM Cloud Object Storage service.





 Using a secure backup 

If you import a root key into Key Protect, you are encouraged to maintain a secure backup of the key material. This key material will allow you to generate an equivalent key in the event that, for example, you accidentally delete your key. Deleted keys can be [restored within 30 days](https://cloud.ibm.com/docs/key-protect?topic=key-protect-delete-purge-keys) of being deleted, but if 30 days have passed, you can use stored key material to create a functionally identical key (it will be able to unwrap data encryption keys created by the deleted root key, for example). You will need to update your application to use the unique key ID given for this functionally identical key and to change the endpoint (if the new key is created in a different region).
You might aggregate a cluster role so that users in the admin cluster role are authorized to run the top pods command. For more information, [see the Kubernetes docs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/aggregated-clusterroles).



 What are some common operations that I might want to extend permissions for a default cluster role? 

Review [the operations that each default RBAC cluster role permits](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-service-access-rolesrbac_ref) to get a good idea of what your users can do, and then compare the permitted operations to what you want them to be able to do.

If your users in the same cluster role encounter errors similar to the following for the same type of operation, you might want to extend the cluster role to include this operation.

Error from server (Forbidden): pods.metrics.k8s.io is forbidden: User "IAMmyname@example.com" can't list resource "pods" in API group "metrics.k8s.io" in the namespace "mynamespace"

Before you begin: [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).



1. Create a cluster role YAML file. In the labels section, specify the existing cluster role that you want to aggregate permissions to. The following example extends the predefined admin cluster role to allow users to run oc top pods. For more examples, [see the Kubernetes docs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/aggregated-clusterroles).

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: view-pod-metrics
labels:
rbac.authorization.k8s.io/aggregate-to-admin: "true"
rules:
oc get rolebinding <role_binding_name> -o yaml | sed 's/<namespace_1>/<namespace_2>/g' | oc -n <namespace_2> create -f -

For example, copy the custom-role role binding from the default namespace to the testns namespace.

oc get rolebinding custom-role -o yaml | sed 's/default/testns/g' | oc -n testns create -f -
2. Verify that the role binding is copied. If you added an IBM Cloud IAM access group to the role binding, each user in that group is added individually, not as an access group ID.

oc get rolebinding -n <namespace_2>





Now that you created and bound a custom Kubernetes RBAC role or cluster role, follow up with users. Ask them to test an action that they have permission to complete due to the role, such as deleting a pod.





 Extending existing permissions by aggregating cluster roles 

You can extend your users' existing permissions by aggregating, or combining, cluster roles with other cluster roles. When you assign a user an IBM Cloud service access role, the user is added to a [corresponding Kubernetes RBAC cluster role](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-service-access-roles). However, you might want to allow certain users to perform additional operations.

For example, a user with the namespace-scoped admin cluster role can't use the oc top pods command to view pod metrics for all the pods in the namespace. You might aggregate a cluster role so that users in the admin cluster role are authorized to run the top pods command. For more information, [see the Kubernetes docs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/aggregated-clusterroles).



 What are some common operations that I might want to extend permissions for a default cluster role?
Ordering node storage When you anticipate that this ordering node will be part of an ordering service on many channels. Recall that the ordering service keeps a copy of the blockchain for every channel they host. The default storage of an ordering node is 100G, same as the container for the peer itself. 



If you plan to deploy a five node Raft ordering service, note that the total of your deployment will increase by a factor of five, a total of 1.75 CPU, 3.5 GB of memory, and 500 GB of storage for the five Raft nodes. A 4 CPU Kubernetes single worker node cluster is the minimum recommended to allow enough CPU for the ordering service cluster and any other nodes you deploy.

If an ordering service is overstressed, it might hit timeouts and start dropping transactions, requiring transactions to be resubmitted. This causes much greater harm to a network than a single peer struggling to keep up. In a Raft ordering service configuration, an overstressed leader node might stop sending heartbeat messages, triggering a leader election, and a temporary cessation of transaction ordering. Likewise, a follower node might miss messages and attempt to trigger a leader election where none is needed.

For more details on the resource allocation panel in the console see [Allocating resource](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-adv-deploymentibp-console-adv-deployment-allocate-resources).





 Customizing an ordering service configuration 

In addition to the ordering node settings that are provided in the console when you provision an ordering node, you have the option to override some of the default settings. If you are familiar with Hyperledger Fabric, these settings are configured in the orderer.yaml file when an ordering node is deployed. The IBM Blockchain Platform console configures these fields for you using default settings so many of these fields are not exposed by the console. You can find the orderer configuration JSON and an example of how to use the configuration override to customize your deployment in the sections below.

The ability to override the ordering service configuration by using the console or APIs is available only in paid clusters.



 Why would I want to override an ordering service configuration?
See the Red Hat OpenShift [documentation](https://docs.openshift.com/container-platform/4.3/logging/cluster-logging-viewing.htmlcluster-logging-viewing-logs-console_cluster-logging-viewing). Access the logs for the peer pod where the smart contract is running and select the dind container.









 Using IBM Log Analysis to view the node logs 

By default, the logs of your nodes are collected locally within your cluster. You can also use IBM Cloud services or a third-party service to collect, store, and analyze the logs from your network. For more information, see Logging and monitoring cluster health for the [IBM Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-healthhealth) or [OpenShift](https://cloud.ibm.com/docs/openshift?topic=openshift-health). It is recommended that you take advantage of the [IBM Log Analysis](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-kubekube) service that allows you to easily parse the logs in real time. See this [tutorial](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-tracking) on using IBM Log Analysis with the IBM Blockchain Platform.







 Upgrading your nodes 

The underlying IBM Hyperledger Fabric Docker images for the peer, CA, and ordering nodes might need to be updated over time, for example, with security updates or to a new Fabric point release. The Upgrade available text on a node tile is the indicator that such a patch is available and can be installed on the node whenever you are ready. Unless otherwise noted in the [Release notes](https://cloud.ibm.com/docs/blockchain?topic=blockchain-release-notes-saas-20), these upgrades are optional, but recommended. You cannot upgrade nodes that have been imported into the console.

The best practice is to apply upgrades to one node at a time. While the upgrade is being applied, the node is unavailable to process requests or transactions.
[Building a Static Website](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-static-website-tutorial)Building a Static Website

This tutorial shows how to host a static website on IBM Cloud® Object Storage, including creating a bucket, uploading content, and configuring your new website.

Object Storage



* 15 minutes
* 2020-11-07



[Developing a web application](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-web-application)Developing a web application

This tutorial shows you how to build a simple image gallery using IBM Cloud® Object Storage, bringing together many different concepts and practices key to web development.

Object Storage Cloud Foundry Public



* 1 hour
* 2020-09-04



[Setting capacity quotas for apps that use IBM Cloud Object Storage](https://cloud.ibm.com/docs/containers?topic=containers-storage-cos-tutorial-quota)Setting capacity quotas for apps that use IBM Cloud Object Storage

With IBM Cloud Object Storage, you can dynamically provision buckets for apps running in your IBM Cloud Kubernetes Service clusters. You can also dynamically set capacity quotas on those buckets during provisioning. Quotas can help you manage the resources your workloads use while also avoiding unnecessary charges.

Kubernetes service Object Storage



* 45 minutes
* 2023-02-16



[Setting up a bastion host that uses Teleport](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-connectivity-bastion-tutorial-teleport)Setting up a bastion host that uses Teleport

This tutorial shows you one way that can be used to meet the IBM Cloud Framework for Financial Services requirements that are related to bastion host. There are various ways to implement a compliant bastion solution, but we show you how to configure a bastion host in your VPC by using Teleport Enterprise Edition, along with Object Storage and App ID for enhanced security.