vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Planning for Code Engine 

IBM Cloud® Code Engine supports two basic workloads: Applications and Jobs.

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.

A job runs one or more instances of your executable code. Unlike applications, which handle HTTP requests, jobs are designed to run one time and exit. When you create a job, you can specify workload configuration information that is used each time that the job is run.

A Function is a stateless code snippet that performs tasks in response to an HTTP request. With IBM Code Engine Functions, you can run your business logic in a scalable and serverless way. IBM Code Engine Functions provide an optimized runtime environment to support low latency and rapid scale-out scenarios. Your Function code can be written in in Node.js or Python, which are optimized to run in IBM Code Engine Functions. In addition, your Function code can be written for any OpenWhisk compatible runtime environment or a custom runtime image.



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
See [Configuring platform logs through the Observability dashboard](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-config_svc_logsconfig_svc_logs_ui) for the steps you need to follow to enable logging through the Observability dashboard.





 Logging APIs 

After you have enabled platform logging through the Observability dashboard, proceed with the steps in the following sections to learn how to use the API endpoints to enable logging, disable logging and view the logging configuration.

The logging API calls require the GUID of the service instance. If you didn't make a note of the GUID, see [Retrieving the GUID of a serverless instance](https://cloud.ibm.com/docs/AnalyticsEngine?topic=AnalyticsEngine-retrieve-instance-details).

At present, two logging API endpoints are exposed:



* log_forwarding_config
* logging. Note that this API endpoint is deprecated and will be discontinued in the near future. Although you may use this endpoint, you should start using the log_forwarding_config endpoint.







 Enabling log forwarding from IBM Analytics Engine 

To enable forwarding IBM Analytics Engine platform logs to IBM Log Analysis, invoke the following API against an existing Analytics Engine instance.

There are two methods that you can use to enable forwarding logs:



* Default: In this case you only put a request for enabling log forwarding, and the logs related to the default log source or sources (spark-driver), will start getting forwarded. You can do this in one of the following ways:



* By using the log_forwarding_config API endpoint:

curl -X PUT https://api.us-south.ae.cloud.ibm.com/v3/analytics_engines/<instance_guid>/log_forwarding_config -H "Authorization: Bearer $TOKEN" -H "content-type: application/json" -d '{"enabled":true}'
* By using the logging API endpoint (deprecated):
DI always starts after the CI starts because the DI depends on CI as the main instance where message server and enqueue server exist. DI is used to balance the load and handle more workload rather than use only the Central Instance. The new name for DI is Additional Application Server (AAS).

Structure:

DI/AAS = GW + ICM + Disp

For more information about configuring and adding a AAS instance in heterogeneous SAP environment, see [SAP Note 680617 - INST: Appl. Server in Heterogeneous SAP System Environment](https://launchpad.support.sap.com//notes/680617).

The benefit of an AAS and DI is to balance the load from the PAS instance by distributing a significant percent of the workload, to an additional DI and AAS server. With help of SAP load balancer mechanism, the AAS and DI provide good performance. Having an AAS and additional DI increases the processing power as well, using the resources of its new server capacity for all system business workload.

For more information, see [SAP Note 26317 - Set up for LOGON group for autom load balancing](https://launchpad.support.sap.com//notes/26317).









 Distributed system 

In a distributed system, there are multiple virtual server instances and every instance can run on a separate host:

Zoom

![Figure 3. Distributed installation](https://cloud.ibm.com/docs-content/v1/content/f89cc64b006ca59b35404693959c83d5747fee3e/sap/images/refarch-sap-mssql-dist-only.svg)

Figure 3. SAP NetWeaver 7.x MS SQL Server distributed installation with AAS

The components in a distributed system are the same as the components in a standard system, but there are restrictions as to which instances can go on which hosts.





 Related information 

SAP One Support Notes that apply to this document:
* Instance - Collects data for all network interfaces on a specific virtual server.
* Interface - Collects data for a specific network interface on a specific virtual server.



* Storage - Flow logs are stored in an IBM Cloud Object Storage (COS) bucket. This bucket is configured during the setup of the flow log collector.
* Presentation - IBM Cloud SQL Query is IBM's serverless SQL service on data on COS, and is used to create queries on the flow logs stored in COS. Refer to [Viewing flow log objects](https://cloud.ibm.com/docs/vpc?topic=vpc-fl-analyze) and [Using IBM Cloud SQL Query](https://dataplatform.cloud.ibm.com/exchange/public/entry/view/4a9bb1c816fb1e0f31fec5d580e4e14d) for further information.







 Monitoring 

IBM Cloud Monitoring is a cloud-native monitoring system that you can include as part of your IBM Cloud architecture, to gain operational visibility into the performance and health of your servers. After an instance of the IBM Cloud Monitoring service has been provisioned, a monitoring agent is installed on each host that you want to monitor. Via the web UI you are able to monitor your resources, configure alerts and explore events.

To monitor a Windows system with IBM Cloud Monitoring, the Prometheus WMI Exporter is used to perform the collection of the metrics on the system. There are two options for publishing the metrics:



1. Run a monitoring agent on a Linux system and remotely scrape the Windows endpoint.
2. Use the Prometheus remote-write capabilities to push the metrics from the Windows system by running Prometheus as a client collector on Windows.



To see the step by step installation and configuration refer to [Monitoring a Windows environment](https://cloud.ibm.com/docs/monitoring?topic=monitoring-windows).





 Log analysis 

The IBM Log Analysis service enables the management of event logs from resources in IBM Cloud. IBM Log Analysis offers features to filter, search, define alerts, and design custom views to monitor logs.
You can build a high availability application within a data center and know that your virtual servers are isolated from each other.

Placement groups with the “spread” rule are available to create in select IBM Cloud data centers. After a "spread" rule is created, you can provision a virtual server into that group and guarantee that won't be on the same host as any of your other virtual servers. The best part? There’s absolutely no charge for using this feature.

You can create your placement group, then assign up to five new virtual server instances. With the "spread" rule, each of your virtual servers are provisioned on different physical hosts.



 Next steps 

To create and manage placement groups, see [Managing placement groups](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-vsi_managing_placegroupvsi_managing_placegroup).
The DI has no Message Server and Enqueue Work Process.

DI always starts after the CI starts because the DI depends on CI as the main instance where message server and enqueue server exist. DI is used to balance the load and handle more workload rather than use only the Central Instance. The new name for DI is Additional Application Server (AAS).

Structure:

DI/AAS = GW + ICM + Disp

For more information about configuring and adding a AAS instance in heterogeneous SAP environment, see [SAP Note - 680617 INST: Appl. Server in Heterogeneous SAP System Environment](https://launchpad.support.sap.com//notes/680617).

The benefit of an AAS and DI is to balance the load from the PAS instance by distributing a significant percent of the workload, to an additional DI and AAS server. With help of SAP load balancer mechanism, the AAS and DI provide good performance. Having an AAS and additional DI increases the processing power as well, using the resources of its new server capacity for all system business workload.

For more information, see [SAP Note 26317 - Set up for LOGON group for autom load balancing](https://launchpad.support.sap.com//notes/26317).







 Distributed system 

In a distributed system, there are multiple virtual server instances and every instance can run on a separate host:

Zoom

![Figure 3. Distribured architecture Sybase](https://cloud.ibm.com/docs-content/v1/content/f89cc64b006ca59b35404693959c83d5747fee3e/sap/images/refarch-sap-syb-dist-only.svg)

Figure 3. SAP NetWeaver SYB standard installation with AAS

The components in a distributed system are the same as the components in a standard system, but there are restrictions as to which instances can go on which hosts.

The Sybase db and the ASE components must reside on the same virtual server instance.
* We will use access groups without resource groups.
* Users are defined in IBM Cloud and project assignments are done there as well.
* Users should be able to delete jobs.



The steps to implement this setup are:



2. The Cloud administrator creates three service instances: QR-ml, QR finance, and QR-common.
3. The Cloud administrator creates a custom rule that includes the quantum-computing.job.delete action.
4. The Cloud administrator creates two access groups:



* The ml access group can access QR-ml and QR-common.
* The finance access group can access QR-finance and QR-common.



5. The Cloud administrator invites cloud users to the appropriate project. Specifically, they invite and assign users to an access group that includes the project.



* Fatima is added to the "ml" access group.
* Ravi is added to the "finance" access group.
* Amyra is added to both the "ml" and "finance" access groups.



6. Users can log in through the IBM Cloud portal, create API keys, and work with their projects' service instances.







 Next steps 



* See [Additional considerations](https://cloud.ibm.com/docs/quantum-computing?topic=quantum-computing-considerations-org) for more information.
Instead, consider [Istio](https://cloud.ibm.com/docs/containers?topic=containers-istio).
9. Disposability: Design your app to be disposable, with minimal startup, graceful shutdown, and toleration for abrupt process terminations. Remember, containers, pods, and even worker nodes are meant to be disposable, so plan your app accordingly.
10. Dev-to-prod parity: Set up a [continuous integration](https://www.ibm.com/garage/method/practices/code/practice_continuous_integration) and [continuous delivery](https://www.ibm.com/garage/method/practices/deliver/practice_continuous_delivery) pipeline for your app, with minimal difference between the app in development and the app in prod.
11. Logs: Treat logs as event streams: the outer or hosting environment processes and routes log files. Important: In IBM Cloud Kubernetes Service, logs are not turned on by default. To enable, see [Configuring log forwarding](https://cloud.ibm.com/docs/containers?topic=containers-health).
12. Admin processes: Keep any one-time admin scripts with your app and run them as a [Kubernetes Job object](https://kubernetes.io/docs/concepts/workloads/controllers/job/) to ensure that the admin scripts run with the same environment as the app itself. For orchestration of larger packages that you want to run in your Kubernetes clusters, consider using a package manager such as [Helm](https://helm.sh/).







 What about serverless apps? 

You can run serverless apps and jobs through the [IBM Cloud Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-getting-started) service. Code Engine can also build your images for you. Code Engine is designed so that you don't need to interact with the underlying technology it is built upon.
The mirrors are part of the [service endpoints](https://cloud.ibm.com/docs/vpc?topic=vpc-service-endpoints-for-vpc) available for IBM Cloud VPC. There is no ingress cost for reading the mirrors.

Consider both updating the version lists available to the provisioned instances and upgrading the installed software from these mirrors.





 Initialize and customize cloud instances with cloud-init 

When provisioning a virtual server instance, you can specify a [cloud-init](https://cloudinit.readthedocs.io/en/latest/index.html) script to be executed during the server initialization. Cloud-init is a multi-distribution package that handles early initialization of a cloud instance. It defines a collection of file formats to encode the initialization of cloud instances.

In IBM Cloud, the cloud-init file contents are provided in the user-data parameter at the time the server is provisioned. See [User-Data Formats](https://cloudinit.readthedocs.io/en/latest/topics/format.htmluser-data-formats) for acceptable user-data content. If you need to debug script execution, cloud-init logs the output of the initialization script in /var/log/cloud-init-output.log on virtual server instances.

This tutorial uses a shell script named [install.sh](https://github.com/IBM-Cloud/vpc-tutorials/blob/master/vpc-app-deploy/shared/install.sh) as initialization script:

!/bin/bash
set -x
apt-get update
apt-get install -y nginx
indexhtml=/var/www/html/index.html

 Demonstrate the availability of internet repositories. If www.python.org is availble then other software internet software like
 npm, pip, docker, ... if isolated only the software from the ibm mirrors can be accessed
[Change User Access](https://cloud.ibm.com/docs-content/v1/content/5f399fa794584e8a662591b494b9a99aa927c74c/quantum-computing/images/org-guide-manage-user.png)

Figure 11. Change User Access
2. Add access groups with Assign group or remove the user from an access group by clicking the three dot menu and choosing Remove user.







 Step 3: User Flow 



1. After they accept an invitation, users can log in through the [IBM Cloud portal](https://cloud.ibm.com/).
2. To work with Qiskit Runtime service instances, users must create an API key by going to ([Manage → Access (IAM) → API keys](https://cloud.ibm.com/iam/apikeys)).
3. For further information, users can review [Getting started, Step 2](https://cloud.ibm.com/docs/quantum-computing?topic=quantum-computing-get-startedinstall-packages).







 Example scenario 

In our example, we want to create the following setup:



* We have two projects, ml and finance.



* The ml project should have access to the service instances QR-ml and QR-common.
* The finance project should have access to the service instances QR-finance and QR-common.



* We have three users:



* Fatima should have access to the ml project.
* Ravi should have access to the finance project.
* Amyra should have access to both projects.



* We will use access groups without resource groups.
* Users are defined in IBM Cloud and project assignments are done there as well.
* Users should be able to delete jobs.



The steps to implement this setup are:



2. The Cloud administrator creates three service instances: QR-ml, QR finance, and QR-common.
3. The Cloud administrator creates a custom rule that includes the quantum-computing.job.delete action.
4.
b45450d3-1a17-2226-c518-a8ad0a75f5f8 windows-2012-amd64 Windows Server (2012 Standard Edition) 2018-10-30T06:12:06.678+00:00 available public
81485856-df27-93b8-a838-fa28a29b3b04 windows-2012-r2-amd64 Windows Server (2012 R2 Standard Edition) 2018-10-30T06:12:06.564+00:00 available public
5ccbc579-dc22-0def-46a8-9c2e9b502d37 windows-2016-amd64 Windows Server (2016 Standard Edition) 2018-10-30T06:12:06.59+00:00 available public

IBM has internal mirrors to support the IBM images. The mirrors will contain new versions for the software in the IBM provided images as well as the optional packages associated with the distribution. The mirrors are part of the [service endpoints](https://cloud.ibm.com/docs/vpc?topic=vpc-service-endpoints-for-vpc) available for IBM Cloud VPC. There is no ingress cost for reading the mirrors.

Consider both updating the version lists available to the provisioned instances and upgrading the installed software from these mirrors.





 Initialize and customize cloud instances with cloud-init 

When provisioning a virtual server instance, you can specify a [cloud-init](https://cloudinit.readthedocs.io/en/latest/index.html) script to be executed during the server initialization. Cloud-init is a multi-distribution package that handles early initialization of a cloud instance. It defines a collection of file formats to encode the initialization of cloud instances.

In IBM Cloud, the cloud-init file contents are provided in the user-data parameter at the time the server is provisioned. See [User-Data Formats](https://cloudinit.readthedocs.io/en/latest/topics/format.htmluser-data-formats) for acceptable user-data content.
* [Invocation concurrency and scaling of Function instances](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cefunctionsfunctions-concur-ce)
* [Packaging your source code for a Function](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cefunctionsfunctions-packaging)





 Isolation 

Code Engine is a multi-tenant, regional service where tenants share the same network and compute infrastructure. In particular, the network and compute infrastructure are shared resources and some management components are common to all tenants. However, tenants and their workloads are isolated from each other by using Code Engine projects. Code Engine prevents communication between projects, providing isolation to your applications inside a multi-tenant environment, which can include applications, batch jobs, and functions. in In addition, there are access controls that are performed on a resource level to only allow authorized users to perform certain operations on project resources, such as Functions or other Code Engine workloads.

For more information about workload isolation, see [Code Engine workload isolation](https://cloud.ibm.com/docs/codeengine?topic=codeengine-architectureworkload-isolation).





 Logging 

Function code can write stdout and stderr logs that are captured and forwarded to an IBM Cloud Log Analysis instance. IBM Cloud Log Analysis is a Platform logging instances that you can set up to index your logs. For more information, see [Viewing logs](https://cloud.ibm.com/docs/codeengine?topic=codeengine-view-logs).





 Runtimes 

Code Engine includes Managed runtimes that you can use for your Functions, but also supports Custom runtimes if the Function program logic has specific demands on its runtime environment.

Managed runtimes include Node.js and Python versions and specific CPU and memory combinations. These runtimes are optimized for fast startup. These runtimes are pre-warmed, which avoids the overhead of pulling container images and starting containers and processes. Your code is injected into an already running container. Use these managed runtimes when possible.
If REGISTRY is not specified, the default is docker.io. If TAG is not specified, the default is latest. This value is optional.

--instances, --is
: Specifies the number of instances that are used for runs of the job. When you use this option, the system converts to array indices. For example, if you specify instances of 5, the system converts to array-indices of 0 - 4. This option can only be specified if the --array-indices option is not specified. This value is optional. The default value is 0.

--maxexecutiontime, --met
: The maximum execution time in seconds for runs of the job. This option can only be specified if mode is task. This value is optional. The default value is 7200.

--memory, -m
: The amount of memory that is set for runs of the job. Use M for megabytes or G for gigabytes. For valid values, see [Supported memory and CPU combinations](https://cloud.ibm.com/docs/codeengine?topic=codeengine-mem-cpu-combo). This value is optional.

--mode
: The mode for runs of the job. Valid values are task and daemon. In task mode, the maxexecutiontime and retrylimit options apply. In daemon mode, since there is no timeout and failed instances are restarted indefinitely, the --maxexecutiontime and --retrylimit options are not allowed. This value is optional.

--mount-configmap, --mount-cm
: Add the contents of a configmap to the file system of runs of the job by providing a mount directory and the name of a configmap, with the format MOUNT_DIRECTORY=CONFIGMAP_NAME. Each mounted configmap must use a unique mount directory. For each key-value pair in the configmap, a file is added to the specified mount directory where the filename is the key and the contents of the file is the value of the key-value pair.
id 7f7096d2-5c44-4d9a-ac01-b904c7611b7b
state finished
start_time 2022-03-01T12:58:54.000Z
finish_time 2022-03-01T13:09:14.000Z

The application might take between 2 to 5 minutes to complete.







 Step 4: Create logging service to see logs 

You can use use the Analytics Engine CLI to enable logging to help you troubleshoot issues in IBM Analytics Engine. Before you can enable logging, you need to create an IBM Log Analysis service instance to which the logs are forwarded.



1. Create a logging instance:

Action
: Enter:

ibmcloud resource service-instance-create NAME logdna SERVICE_PLAN_NAME LOCATION

Parameter values:



* NAME: Any name of your choice for the IBM Log Analysis service instance
* SERVICE_PLAN_NAME: The name of the service plan. For valid values, see [Service plans](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-service_plans).
* LOCATION: Locations where Analytics Engine is enabled to send logs to IBM Log Analysis. For valid locations, see [Compute serverless services](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-cloud_services_locationscloud_services_locations_serverless).



Example
: Enter:

ibmcloud resource service-instance-create my-log-instance logdna 7-day us-south

Once the logging service is created, you can log in to [IBM Cloud®](https://cloud.ibm.com/docs/cloud.ibm.com), search for the logging service instance, and click on the monitoring dashboard. There you can view the driver and executor logs, as well as all application logs for your Spark application.

Search using the application_id or instance_id.
2. Enable platform logging:

To view IBM Analytics Engine platform logs, you must use the Observability dashboard in IBM Cloud to configure platform logging.