vania-janet/multiturn-rag-retrieval-data huggingface dataset:
By using the IBM PowerVM underneath, the customization of the Virtual Servers is flexible, with fast self-service provisioning available in worldwide locations - all with pay-as-you-use billing that makes it easier for you to scale up and out.

IBM Power Virtual Servers are colocated in the same IBM Cloud data centers that are used by both IBM Cloud Classic Infrastructure and VPC Infrastructure, but are separated from the rest of the IBM Cloud servers with separate networks and storage. They can be connected to/from an on-premises network, the IBM Cloud Classic Infrastructure or IBM Cloud VPC Infrastructure networks by using IBM Cloud® Direct Link on Classic.

The IBM Power Virtual Servers can be used for several workload scenarios such as disaster recovery, development environments, partial IT infrastructure moves and enabling you to stay competitive with flexible scaling of infrastructure capacity in a hybrid cloud deployment. This Infrastructure-as-a-Service (IaaS) offering is designed for large mission-critical workloads where scale-up over 12 TB of memory and density of 6,000 SAPS per CPU Core are required to meet performance.

As the IBM Power Virtual Servers are IaaS once provisioned are managed by the account holder; either you, your customer, or your services partner depending on your business operations model.

IBM Power Systems clients who rely on on-premises data center deployments for their infrastructure, can now quickly and economically extend their IBM Power resources into the cloud in a matter of minutes. The IBM Power Systems Virtual Servers provide:



* Straightforward billing: Hourly rates on Monthly Billing, with IBM PowerLinux customers can use Bring-your-own-License (BYOL), to use their own licenses for the OS Images provided by IBM Power Systems Virtual Servers and reduce costs of their Cloud environment.
* Enterprise Hybrid Cloud deployment: run workloads on IBM Power in both Cloud IaaS and on-premises, accessing Cloud's self-service, fast delivery, elasticity, and connectivity to other IBM Cloud® services. Although your Linux® workloads are running in IBM Power Systems Virtual Servers, you keep the same scalable, resilient, production-ready features that Power Systems hardware is known to provide.
* Infrastructure customization: Flexibility of IBM Power Systems Virtual Servers hardware capabilities:



* Cores (CPU)
* Memory (RAM)
* Data volume size
About IBM security groups 

An IBM Cloud® security group is a set of IP filter rules that define how to handle incoming (ingress) and outgoing (egress) traffic to both the public and private interfaces of a virtual server instance. The rules that you add to a security group are known as security group rules.



* You can assign security groups to the public and/or private network interfaces of a single virtual server or multiple virtual server instances.
* You can assign security groups that are provided by IBM or that you create.
* When a security group is applied to the network component of a virtual server instance, all traffic to and from that network component is denied, unless explicitly permitted by a security group rule.
* The inbound traffic to a virtual server instance is referred to as ingress traffic.
* The outbound traffic from a virtual server instance is referred to as egress traffic.



Security groups are implemented on the hypervisor hosting the virtual server.



 Security groups provided by IBM 

You can assign any of the following security groups that are provided by IBM to the network interfaces of your virtual server instances:



* allow_ssh - This security group defines the IP rules that allow ingress TCP traffic on the SSH port only (22/TCP).
* allow_http - This security group defines the IP rules that allow ingress traffic on HTTP port only (80/TCP).
* allow_https - This security group defines the IP rules that allow ingress TCP traffic on HTTPS port only (443/TCP).
* allow_outbound - This security group defines the IP rules that allow all egress traffic from the server.
* allow_all - This security group defines the IP rules that allow all ingress traffic on all ports.







 Security groups and audit logs 

All security group interactions are logged to an account's audit log. The entries track specific security group changes as well as which user requested the change. Logs are written for the following interactions:



* A security group is added to or removed from a virtual server's network interface.
* A security group's rules are changed by add rule, edit rule, or remove rule.



For each of those interactions, one log is written for each affected object.
Securing your connection 

To ensure that you have enhanced control and security over your data when you use IBM® Log Analysis, you have the option that use private routes to IBM Cloud service endpoints. Private routes are not accessible or reachable over the internet. By using the IBM Cloud Private service endpoints feature, you can protect your data from threats from the public network and logically extend your private network.



 Before you begin 

Consider the following factors when you must decide which network to choose:



* Corporate requirements on how services and applications can access cloud-based services in your account.
* Security on production workloads.
* Industry compliance regulations.



For example, you might have the following requirements when you are working in the IBM Cloud:



* No access to Internet to connect to IBM Cloud services.
* Isolated connectivity for workloads in your account.



When you have these requirements, consider moving from the public network to the private network.

You can configure a logging agent to connect to an IBM Log Analysis instance through the public network or through the private network. By default, the agent connects through the public network.

The type of network defines the level of isolation and security that is configured to move workloads between cloud-based resources in your account. Consider connecting the logging agent over the private network.





 Setting up private service endpoints for IBM Log Analysis 

Private network endpoints support routing services over the IBM Cloud Private network instead of the public network.



* A private network endpoint provides a unique IP address that is accessible to you without a VPN connection.
* Private endpoints work between regions offering a global network. You can run your applications and services in Dallas, and connect to a logging instance in Sydney with a private endpoint.





 Step 1. Enabling your account 

To use private network endpoints, the following account features must be enabled for your account:



* Virtual routing and forwarding (VRF)
* Service endpoints

Enabling service endpoints means that all users in the account can connect to private network endpoints.



You must first enable virtual routing and forwarding in your account, and then you can enable the use of IBM Cloud private service endpoints.



* To enable VRF, you create a support case.
Application workloads 

IBM Cloud® Code Engine is designed to address the needs of developers who just want their code to run. Code Engine abstracts the operational burden of building, deploying, and managing workloads in Kubernetes so that developers can focus on what matters most to them: the source code. Developers can deploy and scale their applications, which are written in any framework or language, by delegating the complexity of building and managing their workloads to Code Engine. Learn about working with applications in IBM Cloud® Code Engine.



 What are application workloads? 

An application, or app, runs your code to serve HTTP requests. In addition to traditional HTTP requests, IBM Cloud® Code Engine also supports applications that use WebSockets as their communications protocol. The number of running instances of an app are automatically scaled up or down (to zero) based on incoming requests and your configuration settings. An app contains one or more revisions. A revision represents an immutable version of the configuration properties of the app. Each update of an app configuration property creates a new revision of the app.





 How do apps compare to jobs and functions? 



Table 1. Comparing Code Engine apps, jobs, and functions

 Characteristic App Job Function 

 Execution time (duration) Long-running 10min per request Long-running up to 24hrs Short-running (<=2mins) 
 Startup latency Medium Scheduled start Low 
 Termination Run-continuously Run-to-completion Run-to-completion 
 Invocation On request or permanently running Scheduled On request, instant 
 Programming Model Container based build and execution Container based build and execution Language specific source code files and dependency meta data 
 Parallelism Parallel execution, flexible Low to medium parallel execution High parallel execution 
 Scale-out Based on number of requests Based on job workload definition Based on events or direct invocations 
 Optimized for Long running highly complex workload and on-demand scale-out Scheduled/planned workloads with high resource demands Startup time and rapid scale-out 







 What are the key features of working with Code Engine applications? 

Review the following topics to learn more about working with applications in Code Engine.
Viewing logs 

Logging is automatically enabled in IBM Cloud® Functions to help you troubleshoot issues. You can also use the IBM Cloud® Activity Tracker service to track how users and applications interact with the Cloud Functions service. Finally, you can [view logs in IBM Log Analysis](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-logslogs_console).



 Viewing action logs as they occur 

Cloud Functions actions can be invoked by other users, in response to various events, or as part of an action sequence. To get information about when actions were invoked and what the output was, it can be useful to monitor the action logs.

Activation data is only accessible through the Cloud Functions API (CLI or REST) for 24 hours after the action finishes processing. In addition, the activation data is also sent to your logging instance and can be accessed there for longer period of time, depending on the service plan that has been chosen for the logging instance.

You can use the Cloud Functions CLI to watch the output of actions as they are invoked.



1. Start a polling loop that continuously checks for logs from activations.

ibmcloud fn activation poll
2. Switch to another window and invoke an action.

ibmcloud fn action invoke /whisk.system/samples/helloWorld --param payload Bob

Example output

ok: invoked /whisk.system/samples/helloWorld with id 7331f9b9e2044d85afd219b12c0f1491
3. In the polling window, you can see the activation log.

Activation: helloWorld (7331f9b9e2044d85afd219b12c0f1491)
2016-02-11T16:46:56.842065025Z stdout: hello bob!

You might also see the logs for any actions that are run on your behalf in Cloud Functions in real time.







 Viewing activation details 

Cloud Functions actions can be invoked by other users, in response to various events, or as part of an action sequence. When an action is invoked, an activation record is created for that invocation.
This step is described in [Prerequisites for installation](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-openshift-runbook-runbook-prereq-intro).
* Add logical switches - Two logical switches are created; OpenShift-LS the network the OpenShift VMs are deployed onto and OpenShift-DLR-Transit, the uplink between the DLR and the Edge.
* Add an ESG - An external services gateway (ESG) is a virtual appliance that provides North-South routing, and other network functions. In this architecture, the ESG is used for; routing, NAT, firewall, and load-balancing. As the ESGs are configured as active - passive pair, DRS anti-affinity rules are used to ensure that NSX Edges do not run on the same host. Static routes are used to direct traffic to either the internet or the IBM private Network. This step is described in [Red Hat OpenShift NSX Edge configuration](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-openshift-runbook-runbook-nsxedge-intro).
* Add a DLR - A distributed logical router (DLR) is a virtual appliance that contains the routing control plane and it distributes the data plane in kernel modules to each hypervisor host. The DLR provides East-West distributed routing and is the default gateway for the Red Hat OpenShift VMs that will be installed on the Red Hat OpenShift logical switch. The NSX DLR virtual machines are configured as an active - passive pair, and vSphere Distributed Resource Scheduler (DRS) anti-affinity rules are created to ensure that the DLR VMs do not run on the same host. This step is described in [Red Hat OpenShift NSX DLR configuration](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-openshift-runbook-runbook-nsxdlr-intro).
* If your virtual server needs access to internal services, such as an update server, network attached storage (NAS), or advanced monitoring, ensure that the security group rules accommodate traffic for those internal services. For more information, see [IBM Cloud IP ranges](https://cloud.ibm.com/docs/hardware-firewall-dedicated?topic=hardware-firewall-dedicated-ibm-cloud-ip-ranges).







 Interfaces 



* A security group can be applied to a private network, a public network, or both network interface types.
* You can attach one or more security groups to the list of security groups that are assigned to a network interface. The security group rules of each security group apply to the associated virtual server instances.
* The first time that you assign an existing security group to a network interface (public or private), a restart is required for each interface. However, if the public and private interfaces were assigned to the security group at the same time, then only one restart is required. After a restart, changes are automatically applied.







 Access 



* All users within an account can read, attach, and detach security groups on the virtual server instances to which they have access. Only users with the Manage Security Groups privilege in Network Permissions can create, update and delete security groups.
* You cannot assign security groups to bare metal servers.







 Deletion 



* You cannot delete a security group that is assigned to one or more running virtual server instances.
* You cannot delete a security group that another security group is referencing in one of its rules.
* If you want to deploy FortiGate-VM16 or FortiGate-VM32, it is recommended that you consider deploying on a gateway cluster instead of a management cluster because of resource requirements. For more information about Fortinet® sizing, see [FortiGate-VM on VMware ESXi data sheet](https://www.fortinet.com/content/dam/fortinet/assets/data-sheets/FortiGate_VM_ESXi.pdf).
* You cannot install Juniper® vSRX and FortiGate Virtual Appliance on the same gateway cluster.
* The initial memory allocation is determined by your initial CPU selection. However, you can change the memory allocation after deployment.
* For larger deployment sizes, such as FortiGate-VM16 and FortiGate-VM32, the initial CPU allocation is set to half the deployment size limit to ensure successful deployment. After deployment, you can change the CPU allocation up to the deployment size limit.
* When you deploy FortiGate Virtual Appliances to your instance, SNAT and firewall rules are defined on the Management NSX Edge™ Services Gateway (ESG). In addition, static routes on the FortiGate Virtual Appliances are defined to allow outbound HTTPS communications from your instance to the public network. These communications are needed for license activation and for acquiring the most updated security policies and content.
* For high CPU licenses, make sure you have enough CPUs available on the consolidated cluster.



* At least 2 VMware ESXi™ servers are available and each active host has sufficient resources to host a single FortiGate VM.
* VMware® vSphere HA has enough resources to host two FortiGate VMs.



Because of the requirements, you must plan carefully for the space that is needed for the FortiGate Virtual Appliance. If needed, before you order FortiGate Virtual Appliance, add 1 - 2 ESXi servers to your instance, or reduce the vSphere HA CPU reservation for failover, or both.



The following table shows the configuration of network and storage for your FortiGate Virtual Appliance, depending on where they are deployed.



Table 1. Network and storage configuration

 Component Management cluster Gateway cluster 

 Management IP Existing management subnet IBM Cloud® primary subnet
(https://cloud.ibm.com/docs/schematics?topic=schematics-locationswhere-wks-created), and [Where is my information stored?](https://cloud.ibm.com/docs/schematics?topic=schematics-secure-datapi-location)





 What ports and IP addresses are used by Schematics? 

Schematics communicates with the ports that are specified by the related resources. For example, VPC related ports, see [VPC: Opening required ports and IP addresses in other network firewalls](https://cloud.ibm.com/docs/containers?topic=containers-vpc-firewall).





 When do I use Schematics versus the individual resource dashboards? 

With IBM Cloud Schematics, you can run your infrastructure code in IBM Cloud to manage the lifecycle of IBM Cloud resources. After you provision a resource, you use the dashboard of the individual resource to work and interact with your resource. For example, if you provision a virtual server instance in a Virtual Private Cloud (VPC) with IBM Cloud Schematics. You can use the VPC console, API, or command-line to stop, reboot, and power on your virtual server instance. However, to remove the virtual server instance, you can use IBM Cloud Schematics.





 Are changes to Git repos refreshed in Schematics? 

No, if you change the code of your Terraform template in GitHub, these changes are not available automatically when you create an execution plan in IBM Cloud Schematics. To pull the current changes from your GitHub repository, make sure that you click the Pull latest option from the workspace settings page before you create your execution plan.





 Where is the Terraform state file stored? 

After you successfully provisioned IBM Cloud resources by running a Schematics apply action, the state of resources is stored in a Terraform state file (terraform.tfstate). Schematics uses this state file as the single source of truth to determine what resources exist in your account. The state file maps the resources that you specified in your Terraform configuration file to the IBM Cloud resource that you provisioned.
Working with dashboards 

Use dashboards to monitor your infrastructure, applications, and services. You can use pre-defined dashboards. You can also create custom dashboards through the Web UI or programmatically. You can backup and restore dashboards by using Python scripts.

A dashboard shows groups of metrics that report on the health, performance, and state of your infrastructure, applications, and services for a single host or a group of hosts. Dashboards offer a specialized insight into network data, application data, topology, services, hosts, and containers.

In the Dashboards section of the Web UI, dashboards are organized into three main groups:



* My Dashboards are dashboards that are created by the user who is currently logged in. An icon indicates if the dashboard is shared with other team members.
* Dashboards Shared By My Team are dashboards that are created by other users, and shared with the current user.



You can copy and share dashboards through the Web UI.

In the Explore section allows you to review specific metrics for your environment. This section also provides support for PromQL queries.

You can run scripts to complete any of the following actions programmatically:



* Save existing dashboards to a local file.
* Create new dashboards that are identical to the dashboards that you save.
* Restore dashboards.





 Pre-defined dashboards 

Pre-defined dashboards are designed around various supported applications, network topologies, infrastructure layouts, and services.

Pre-defined dashboards include a series of panels that are already configured.

For more information on pre-defined dashboards, see [Dashboard Templates](https://docs.sysdig.com/en/dashboard-templates-209032.html).





 Creating custom dashboards in the Web UI 

When you create a custom dashboard, you can start from a template such as a pre-defined dashboard, or choose a blank dashboard. A dashboard includes panels that are configured to display specific data in a number of different formats. You also set how data is aggregated. The scope defines what data is used for aggregation and displayed. You can set the scope at a dashboard level, or override for individual panels.
Service rollout policy 

IBM Cloud® has a resilient global network of locations to host your highly available cloud workload. To ensure that the cloud infrastructure and services are consistent and stable across our deployment locations, we created best practices for our service catalog management. These best practices help us to accomplish rollouts in the most efficient manner and minimize business impact, costs, and risks. The following information describes our guidelines on when to expect or how to request that a service is available in your region.

This policy covers all IBM Cloud public [MZRs](https://cloud.ibm.com/docs/overview?topic=overview-locationstable-mzr), public [single-campus MZRs](https://cloud.ibm.com/docs/overview?topic=overview-locationssingle-campus-mzr) and public [data centers](https://cloud.ibm.com/docs/overview?topic=overview-locationsdata-centers).

IBM® classifies our services deployed to our public locations as core or market-driven.



 Core services 

All IBM® multi-zone regions contain the following core services, which are the most basic and vital services that are needed for the majority of customer workloads.



* IBM Cloud platform (console, CLI, Identity and Access Management, and global catalog)
* IBM Cloud® Virtual Private Cloud



* IBM® Cloud Block Storage for Virtual Private Cloud
* IBM Cloud® Virtual Servers for Virtual Private Cloud
* Virtual Private Network (VPN) for VPC
* IBM Cloud® Transit Gateway
* Network Load Balancer for VPC
* Application Load Balancer for VPC
* Virtual Private Endpoint (VPE) for VPC
* IBM Cloud® DNS Services



* IBM Cloud Object Storage
* IBM Cloud Databases for PostgreSQL
* IBM Key Protect for IBM Cloud
* IBM Cloud® Continuous Delivery
* IBM Cloud Container Registry
* IBM Cloud Kubernetes Service
* Red Hat OpenShift on IBM Cloud



The IBM Cloud platform, including the console, CLI, Identity and Access Management, and global catalog, is a globally accessible instance that is independent of any region or zone.