vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Dallas (us-south) kubectl create -f https://assets.us-south.logging.cloud.ibm.com/clients/logdna-agent-ds-k8s-v1.8.yaml -n ibm-observe 
 Washington (us-east) kubectl create -f https://assets.us-east.logging.cloud.ibm.com/clients/logdna-agent-ds-k8s-v1.8.yaml -n ibm-observe 









 Step 6. Verify that the logging agent is deployed successfully 

To verify that the logging agent is deployed successfully, run any of the following commands:

kubectl get all -n ibm-observe

kubectl get pods -n ibm-observe

The deployment is successful when you see one or more logging pods.



* The number of logging pods equals the number of worker nodes in your cluster.
* All pods must be in a Running state.
* Stdout and stderr are automatically collected and forwarded from all containers. Log data includes application logs and worker logs.
* By default, the logging agent pod that runs on a worker collects logs from all namespaces on that node, including kube-system logs.



To get a copy of the logging agent configuration that is deployed, you can run the following command:

kubectl get daemonset logdna-agent -o=yaml > prod-logdna-agent-ds.yaml -n ibm-observe







 Deploy the logging agent within the context of the cluster 

When you deploy and connect a logging agent within the context of the cluster, consider the following information:



* You can launch the logging UI from the Kubernetes cluster UI in IBM Cloud.
* The view that opens displays logs for your cluster.
* The agent is deployed in the ibm-observe namespace.
* A tag that informs about the cluster name is associated to each log line as metadata.
* A tag that informs about the version of the agent is associated to each log line as metadata.
* The logging instance must be available in the same IBM Cloud account where the cluster is provisioned.
* The logging instance can be in a different resource group and IBM Cloud region than your cluster.
Hardware monitoring and security controls 

The escalation and sophistication of malicious threats has you employing more stringent security requirements and scrutinizing every aspect of your execution environment. You're looking to your cloud providers to offer hardware monitoring and security controls that can determine whether a workload is running on trusted hardware in a known location. IBM Cloud® is leading the way to help you deploy hybrid and cloud environments with enhanced security verification of your launch environment by using Intel® Trusted Execution Technology (Intel TXT).



 How Intel TXT works 

Intel TXT provides hardware monitoring and security controls that help assure businesses that a workload that is deployed on or migrated to the IBM Cloud infrastructure is running on trusted hardware in a known location. IBM Cloud supports Intel TXT on a range of Bare Metal Servers. See [Intel® Trusted Execution Technology](https://www.ibm.com/cloud/bare-metal-servers/intel-txt) for a complete list.

Intel TXT analyzes and measures the components of a computing system from the operating system or hypervisor to the computing system’s boot firmware and hardware. The analysis includes the system’s basic input/output system (BIOS), main boot record (MBR), and boot loader. The measurements are compared to a standard baseline to determine whether the system is trusted or untrusted. System software and local or remote management software can use the trust decision to allow or deny a workload from running on that a computing system. Since Intel® TXT performs the analysis and measuring during boot up, the added security doesn’t add any increased processor usage to applications.

The baseline measurements are stored on a Trusted Platform Module (TPM) hardware device. The TPM device is integrated within the server system and provides a range of Intel TXT security-related functions.





 What does Intel TXT does for you 

Intel TXT is especially advantageous for large enterprises subject to compliance and audit regulations, such as healthcare, financial services, and government organizations. It helps assure that tracking of all trusted resources can be integrated, managed, and reported on with the relevant compliance organizations (HIPAA, PCI, FedRAMP, ISO, FISMA, and SSAE 16).
To configure the specifics of your development, staging, and production environment, use [Terraform input variables](https://cloud.ibm.com/docs/schematics?topic=schematics-create-tf-configconfigure-variables) in your configuration files. Input variables are automatically loaded into IBM Cloud Schematics when you create your workspace. To customize your workspace, you enter the environment-specific values for your variables. This setup is useful if you have one team that manages the lifecycle of the microservice component and where the configuration of your environments does not differ drastically. 
 One Git repo, use branches to distinguish between environments Create one Git repository for your microservice component, and use different Git branches to store the Terraform configuration files for each of your environments. With this setup, you have a clear distinction between your environments and more control over who can access and change a particular configuration. Make sure to set up how changes in one configuration file are populated across branches to avoid that you have different configurations in each environment. 
 One Git repo, use directories to distinguish between environments For organizations that prefer short-lived branches, and where configurations differ drastically across environments, consider creating directories that represent the different configurations of your environments. With this setup, all your directories listen for changes that are committed to the master branch. Make sure to set up how changes in one configuration file are populated across directories to avoid having different configurations in each environment. 
 Use one Git repo per environment Use one Git repository for each of your environments. With this setup, you have a 1:1 relationship between your workspace and Git repository and you can apply separate permissions for each of your Git repositories. Make sure that your team can manage multiple Git repositories and keep them in sync. 







 How can I reuse configuration files across environments and workspaces? 

Try to minimize the number of Terraform configuration files that you need to manage by creating standardized Terraform templates and by using variables to customize the template to your needs.

Now, you can use Terraform modules from the Terraform module registry for IBM Cloud.
Plan, create and update deployment environments 

This tutorial may incur costs. Use the [Cost Estimator](https://cloud.ibm.com/estimator/review) to generate a cost estimate based on your projected usage.

Multiple deployment environments are common when building a solution. They reflect the lifecycle of a project from development to production. This tutorial introduces tools like the IBM Cloud CLI and [Terraform](https://www.terraform.io/) to automate the creation and maintenance of these deployment environments.

Developers do not like to write the same thing twice. The [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) principle is one example of this. Similarly they don't like having to go through tons of clicks in a user interface to setup an environment. Consequently shell scripts have been long used by system administrators and developers to automate repetitive, error-prone and uninteresting tasks.

Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Container as a Service (CaaS), Functions as a Service (FaaS) have given developers a high level of abstraction and it became easier to acquire resources like bare metal servers, managed databases, virtual machines, Kubernetes clusters, etc. But once you have provisioned these resources, you need to connect them together, to configure user access, to update the configuration over time, etc. Being able to automate all these steps and to repeat the installation, configuration under different environments is a must-have these days.

Multiple environments are pretty common in a project to support the different phases of the development cycle with slight differences between the environments like capacity, networking, credentials, log verbosity. In [this other tutorial, we've introduced best practices to organize users, teams and applications](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-users-teams-applicationsusers-teams-applications) and a sample scenario. The sample scenario considers three environments, Development, Testing and Production. How to automate the creation of these environments? What tools could be used?



 Objectives 



* Define a set of environments to deploy
When you implement a multi-organization architecture, organizations provide the first level of boundary enforcement and abstraction that you can use to control and define what can be done and by whom. Design each organization around the different LOBs, the delivery phases, the roles of the users, specific projects, or a combination of these components.

The number of organizations that you require depends on multiple factors:



* The level of granularity that you require within your organization to manage quotas and control costs.
* The level of security that you must enforce in your different environments. For example, if you are using containers, you might want to separate container images that are used for development from the container images that are used for production.
* The location of the organizations due to corporate, country, and industry requirements. For example, you might want to run all of your apps in an environment that is located in a specific region in your geography (geo).



When you are defining the different organizations for your cloud structure, consider the following guidance:



* Define and then enforce a naming convention. For example, define a naming convention where the name of the organization includes information about the business area, the type of cloud, and the process phase (development, testing, or production). For organizations that are located in IBM Cloud Public, you might want to add information about the region too.
* Define the restrictions that apply to the organization. For example, define the role of the team members that are going to work in that organization.
* Identify the manager of the organization.
* Identify the area of the business that is allocated to this organization.



The following scenarios show different approaches that you can adopt when you define the number of Cloud Foundry organizations in an environment:



 Scenario 1: Segregation of user groups by business app delivery 

Description: Corporate rules require that the apps of each LOB must be developed, managed, and deployed by users from each LOB. Security must be enforced so that users can access only the apps that are relevant to their part of the business. So, the users work in different business areas, the apps they are working on require access to different IBM Cloud resources, and there is no activity overlap.

Solution: You can create an organization for each business app delivery process. For example, one organization for retail banking, and one for investment banking.
(Some primitives are future functions.)

Upload and iterate: Upload your own Qiskit quantum program and run it with different inputs and configurations each time. (Future function)

Receive intermediate results: Receive intermediate results as your execution runs. (Future function)





 Overview of primitive programs 

With Qiskit Runtime, we are introducing a new set of interfaces, in the form of primitive programs, to expand on how users run jobs on quantum computers.

The existing Qiskit interface to backends (backend.run()) was designed to accept a list of circuits and return counts for every job. Over time, it became clear that users have diverse purposes for quantum computing, and therefore the ways in which they define the requirements for their computing jobs are expanding. Therefore, their results also look different.

For example, an algorithm researcher and developer cares about information beyond counts; they are more focused on efficiently calculating quasiprobabilities and expectation values of observables.

Our primitives provide methods that make it easier to build modular algorithms and other higher-order programs. Instead of simply returning counts, they return more immediately meaningful information. Additionally, they provide a seamless way to access the latest optimizations in IBM Quantum hardware and software.

The basic operations that one can do with a probability distribution is to sample from it or to estimate quantities on it. Therefore, these operations form the fundamental building blocks of quantum algorithm development. Our first two Qiskit Runtime primitives (Sampler and Estimator) use these sampling and estimating operations as core interfaces to our quantum systems.





 Available primitives 

The following primitive programs are available:



Table 1. Available primitive programs

 Primitive Description Example output 

 Sampler Allows a user to input a circuit and then generate quasiprobabilities. This generation enables users to more efficiently evaluate the possibility of multiple relevant data points in the context of destructive interference. ![An example of Sampler output is shown.]
Multicloud apps with Istio 

By using the App Identity and Access Adapter, you can centralize all your identity management in a single place.

The App Identity and Access Adapter is not currently supported.

Because enterprises use clouds from multiple providers or a combination of on and off-premise solutions, heterogeneous deployment models can help you to preserve existing infrastructure and avoid vendor lock-in. The Adapter can be configured to work with any OIDC-compliant identity provider, such as App ID. The service enables the Adapter to control authentication and authorization policies in all environments, including front end and backend applications. And, it does it all without any change to your code or the need to redeploy your application.

What can the App Identity and Access Adapter do for you? Check out the following video to learn more.



 Multicloud architecture 

A multicloud computing environment combines multiple cloud and / or private computing environments into a single network architecture. By distributing workloads across multiple environments, you might find improved resiliency, flexibility, and greater cost-efficiency. To achieve the benefits, it's common to use a container-based application with an orchestration layer, such as Kubernetes.

Zoom

![App Identity and Access Adapter architecture diagram](https://cloud.ibm.com/docs-content/v1/content/27ecaa7a29890634603881a8e64789974a29916b/appid/images/istio-adapter.png)

Figure 1. Multicloud deployment - achieved with the App Identity and Access Adapter





 Understanding Istio and the Adapter 

[Istio](https://istio.io) is an open source service mesh that layers transparently onto existing distributed applications that can integrate with Kubernetes. To reduce the complexity of deployments, Istio provides behavioral insights and operational control over the service mesh as a whole. When App ID is combined with Istio, it becomes a scalable, integrated identity solution for multicloud architectures that does not require any custom application code changes.
Qiskit Runtime overview 

Get a glimpse of the quantum computing future with our world-leading Qiskit Runtime, a new architecture that delivers significant performance enhancements to program execution. By using our physical systems and simulators (cloud-based classical emulators of quantum systems), you can experience frictionless quantum computing. That is, the ability to run quantum programs in an environment where the classical computer is physically closer to the quantum computer. Test programs and algorithms, and develop new models with our cloud-based quantum runtime for drastically improved capacity and higher performance today.

Because this service is in Beta phase, many functions are not yet available and are still under development, including some of the functions that are outlined in the following diagram.

Zoom

![A user is shown running the Qiskit program by using APIs that control the Qiskit Runtime Manager.](https://cloud.ibm.com/docs-content/v1/content/5f399fa794584e8a662591b494b9a99aa927c74c/quantum-computing/images/Qiskit_Runtime_architecture.png)

Figure 1. Diagram of Qiskit Runtime's architecture



 Why use Qiskit Runtime? 

Run your experiments with an improved architecture: For variational algorithms such as VQE, the loops between classical and quantum computation happen with a low-latency connection to the quantum device.

Use primitives to get started quickly: Primitive programs provide a simplified interface for building and customizing applications. You can submit circuits and return shot counts, pre-shot readouts, or observable expectation values. (Some primitives are future functions.)

Upload and iterate: Upload your own Qiskit quantum program and run it with different inputs and configurations each time. (Future function)

Receive intermediate results: Receive intermediate results as your execution runs. (Future function)





 Overview of primitive programs 

With Qiskit Runtime, we are introducing a new set of interfaces, in the form of primitive programs, to expand on how users run jobs on quantum computers.
Remote state and cross-workspace access 

IBM Cloud® provides built in [remote-state](https://developer.hashicorp.com/terraform/language/state/remote) management for Terraform. Terraform state files are automatically preserved between runs and are accessible by IBM Cloud® commands and operations. IBM Cloud® remote-state management enables team work and workspace shared operations, with built in state locking preventing concurrent operations against the same state file.

The built in workspace remote-state management supports a number of Schematics use cases:



* The sharing of resource information between workspaces. This allows your infrastructure to be broken down into smaller components, with read-only resource information passed between environments using Schematics remote-state data sources. Discrete environments linked by data sources allows responsibility for different elements of infrastructure to be delegated to different teams with information shared between workspaces as read-only resources.
* Integration of Terraform and Ansible operations with [Actions](https://cloud.ibm.com/docs/schematics?topic=schematics-action-working). Workspace resource information can be directly passed as an Ansible [dynamic inventory](https://cloud.ibm.com/docs/schematics?topic=schematics-inventories-setupdynamic-inv) without the need for manual host inventory creation or use of inventory scripts.
* Management of large-scale IaC environments. [Blueprints](https://cloud.ibm.com/docs/schematics?topic=schematics-blueprint-intro) enables large environments to be composed from modular Terraform environments by the [direct passing of values](https://cloud.ibm.com/docs/schematics?topic=schematics-blueprint-templatesblueprint-module-outputs) and state information between deployed modules.





 Accessing workspace state and outputs
For SAP HANA and the high network performance and security that is required, additional VLANs can assist. Read the recommendations by SAP for on-premises environments on [SAP HANA Network Requirements](https://www.sap.com/documents/2016/08/1cd2c2fb-807c-0010-82c7-eda71af511fa.html) and identify the suitable network configuration for meeting your business needs.





 VMware on classic infrastructure separation of subnets 

To separate traffic with IBM Cloud for VMware Solutions Dedicated, use multiple subnets within the VMware Overlay VXLAN (powered by VMware NSX).

In IBM Cloud for VMware Solutions Dedicated, the VMware Overlay VXLAN (powered by VMware NSX) is connected back to public VLAN and private VLAN on the classic infrastructure network as the underlay; the VMware NSX management utilizes the private secondary portable subnets to achieve the VXLAN. This provides full control of the network design when running on VMware, and allows assigning VMware VM's an IP from any defined range.

If instead using a manual deployment of VMware to a bare metal, the VMware vSwitch would directly use the private VLAN's secondary portable subnet to assign VMware VM's an IP address from the classic infrastructure network.

Traffic segregation needs to be considered carefully within VMware deployments, because elaborate VMware-based deployments, where different kinds of network traffic might need to be more strictly separated for security reasons.
You need to provision and deploy a Hyper Protect Crypto Services instance to implement and use Unified Key Orchestrator.





 How is Hyper Protect Crypto Services with Unified Key Orchestrator different from the Hyper Protect Crypto Services Standard Plan? 

Hyper Protect Crypto Services with Unified Key Orchestrator extends the Standard Plan. IBM Cloud is the only cloud service provider that offers native cloud encryption key orchestration and lifecycle management across hybrid multicloud environments, including IBM Cloud, IBM Satellite, other cloud service providers, and on-premises environments.





 What type of HSM is used for Hyper Protect Crypto Services with Unified Key Orchestrator? 

Hyper Protect Crypto Services with Unified Key Orchestrator is built on the FIPS 140-2 Level 4 certified HSM as the Hyper Protect Crypto Services Standard Plan.





 Which cloud vendors or providers are supported by Hyper Protect Crypto Services with Unified Key Orchestrator as connected external keystores? 

The following list contains a few cloud providers:



* Keystores of another Hyper Protect Crypto Services instance
* Keystores of IBM® Key Protect for IBM Cloud®
* Keystores of IBM® Key Protect for IBM Cloud® on Satellite
* Microsoft Azure Key Vault
* AWS Key Management Service
* Google Cloud Key Management Service







 How is Unified Key Orchestrator different from EKMF Web? 

IBM® Enterprise Key Management Foundation - Web Edition (EKMF Web) and Unified Key Orchestrator share the same code base.

EKMF Web is an on-premises product for IBM Z14 or Z15 environments, running z/OS V2.3 or z/OS V2.4 and IBM Db2. Hyper Protect Crypto Services with Unified Key Orchestrator is a cloud native service in IBM Cloud, which offers key management and orchestration in a hybrid multicloud environment.





 What multizone regions is Hyper Protect Crypto Services with Unified Key Orchestrator available in? 

Hyper Protect Crypto Services with Unified Key Orchestrator is available in all regions where Hyper Protect Crypto Services is available. Refer to [Regions and locations](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-regions) for a list of available regions of Hyper Protect Crypto Services.