vania-janet/multiturn-rag-retrieval-data huggingface dataset:
In a development Catalog, staging and publishing actions are forced. If you republish a Product, the new version overwrites the old version without warning. If conflicts are found, they are automatically resolved by the system. Unpublish actions happen automatically. When you use the test tool in a development Catalog, any Product that you test overwrites staged and published Products. The newer version replaces the old version even if the operations are being used on the Developer Portal. A Developer Portal created from a development Catalog must be used only for testing purposes only and not for real cases.
* Automatic subscription: If you enable automatic subscription for a Catalog, testing of your APIs in the API Manager user interface is made easier because a test application is used. The test application includes a pre-supplied client ID and client secret. The test application's credentials are automatically subscribed to all the Plans in the Catalog. The test application is not subject to rate limits. Automatic subscription is available only for a development Catalog.
* Default: You can set one of your Catalogs to be the default Catalog. Then, calls to APIs that are published to that Catalog can use a shorter URL that does not include the Catalog name.



For more information about using the Developer Portal, see [Discovering and using APIs](https://www.ibm.com/support/knowledgecenter/en/SSFS6T/com.ibm.apic.devportal.doc/capim_devportal_overview.html).







 Syndication 

With the IBM® API Connect for IBM Cloud® syndication feature, you can partition your Catalogs into Spaces. Each Space is used by a different API provider development team. A Space has its own set of management capabilities, so that each team can manage their APIs independently.

When you stage or publish an API to a Catalog that has Spaces enabled, you specify the Space within that Catalog that you want to stage or publish to. However, application developers that access the Developer Portal for the Catalog are unaware of the Space partitioning of the Catalog and see the APIs as a coordinated offering. Each Space has its own Product lifecycle management, subscription approvals, and analytics data.
Retail use cases for IBM Cloud 

These use cases highlight how workloads on IBM Cloud® Kubernetes Service can take advantage of analytics for market insights, multi-region deployments across the globe, and inventory management with IBM® Event Streams for IBM Cloud® and object storage.



 Brick-and-mortar retailer shares data, by using APIs with global business partners to drive omnichannel sales 

A Line-of-Business (LOB) Exec needs to increase sales channels, but the retail system is closed off in an on-premises data center. The competition has global business partners to cross-sell and up sell permutations of their goods: across brick-and-mortar and online sites.

IBM Cloud Kubernetes Service provides a public-cloud ecosystem, where containers enable new business partners and other external players to co-develop apps and data, through APIs. Now that the retail system is on the public cloud, APIs also streamline data sharing and jump-start new app development. App deployments increase when Developers experiment easily, pushing changes to Development and Test systems quickly with toolchains.

IBM Cloud Kubernetes Service and key technologies:



* [Clusters that fit varied CPU, RAM, storage needs](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodesplanning_worker_nodes)
* [IBM Cloud® Object Storage to persist and sync data across apps](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-getting-started-cloud-object-storage)
* [DevOps native tools, including open toolchains in IBM Cloud® Continuous Delivery](https://www.ibm.com/cloud/architecture/toolchains/)





 Context 



* The retailer is faced with strong competitive pressures. First, they need to mask the complexity of crossing into new products and new channels. For example, they need to expand product sophistication. At the same time, it needs to be simpler for their customers to jump across brands.
* That ability to jump brand means that the retail ecosystem requires connectivity to business partners. Then, the cloud can bring new value from business partners, customers, and other external players.
It's the standard virtualization block device, and the disk shows up as a Virtio block device. For more information about Virtio, see Virtio.





 Reporting instance storage information 

You can report instance storage information for your virtual server instance by using the following CLI example.

$ ibmcloud is instance-disks 0716_f8c0fd3b-cada-46c3-91f6-c271937ef488
Listing disks of instance 0716_f8c0fd3b-cada-46c3-91f6-c271937ef488 under account YYYYYY as user vpc-user@myco.com...
ID                                          Name                               Size   Interface Type
0716-6ebed02f-c421-4b06-a73b-f334413e84b3   clunky-refocus-tidings-underpaid   600    virtio_blk
0716-54ee0659-d92a-4d4c-ac6b-8f03cb178a07   linguini-epiphany-lush-preschool   600    virtio_blk





 Updating one of the default names 

You can update the custom names of the instance storage disks by using the following CLI command.

$ ibmcloud is instance-disk-update 0716_f8c0fd3b-cada-46c3-91f6-c271937ef488 0716-6ebed02f-c421-4b06-a73b-f334413e84b3 --name my-instance-disk1
Updating instance disk 0716-6ebed02f-c421-4b06-a73b-f334413e84b3 of instance 0716_f8c0fd3b-cada-46c3-91f6-c271937ef488 under account YYYYYY as user vpc-user@myco.com...
The Dashboard Overview 

The Overview page shows information about your IBM Cloud® Messages for RabbitMQ deployment. The overview includes essential identifying information.



 Overview 



 Type 

The type of database that is offered by the service, and the database version that your service uses.





 ID 

The ID is a [CRN (Cloud Resource Name)](https://cloud.ibm.com/docs/account?topic=account-crn) which uniquely identifies the database deployment. The CRN is used to refer to the database in the API and can be used with the CLI. The Overview pane shows details of your service.





 Recent Tasks 

Every time that you make administrative changes to your service (such as scaling, or taking a manual backup), a task starts up. The Recent Tasks panel shows the task name and progress bar for any running tasks, and a list of the most recently completed tasks. Depending on how busy your deployment is, successful tasks can be shown for 24 - 48 hours. Unsuccessful tasks can show for 7 - 8 days. Tasks can also be retrieved from the [Cloud Databases API](https://cloud.ibm.com/apidocs/cloud-databases-apiget-currently-running-tasks-on-a-deployment) and [CLI plug-in](https://cloud.ibm.com/docs/databases-cli-plugin?topic=databases-cli-plugin-cdb-referencedeployment-tasks-list). A historical record of tasks from any time period is available through the [IBM Cloud® Activity Tracker integration](https://cloud.ibm.com/docs/messages-for-rabbitmq?topic=cloud-databases-activity-tracker).





 Endpoints 

The Endpoints pane within the Overview pane contains connection strings for your deployment. Each tab contains connection information that is tailored to the type of connection or the protocol that uses it. Basic information includes things like hostname and port, as well as the TLS self-signed certificate, TLS/SSL parameters, and the default database of your deployment.
The default app name is hello-containers.
* IBM Cloud API Key: The API key that is used to interact with the ibmcloud CLI tool in several tasks. Use one of the following methods to specify the API key that you want to use:



* Click the key icon to import an existing API key from a secret vault of your choice.
* Copy and paste an existing API key.
* Click New to create an API key.
* Generate a new api-key if you don’t have an existing API key.



You can immediately save the generated API key to an existing secrets vault of your choice.



The app is deployed by using the deployment strategy that you specified. The following example shows the details for a Rolling or Blue-Green deployment.

Zoom

![Kubernetes secure app deployment target details for Rolling or Blue-Green](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/ds_kub_setup_dep_target_rolling_bluegreen.png)

Figure 7. Kubernetes secure app Rolling deployment target details

If you selected the Canary deployment strategy, you must specify extra deployment target details.



* Canary step size: Defines the amount of traffic to redirect to the new release of the Canary deployment.
* Canary step interval: Defines the time interval between each Canary test to move to the new release of the Canary deployment.



Zoom

![Kubernetes secure app deployment target details for Canary](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/ds_kub_setup_dep_target_canary.png)

Figure 8. Kubernetes secure app Canary deployment target details





 Step 3: Add optional tool integrations 

You can add the IBM Cloud® DevOps Insights tool integration to your toolchain without any additional configuration.
[global-ingest-config]
target-tables:iceberg_cat.ice_schema.customer1_tab
ingestion-engine:hostname=localhost,port=8080
create-if-not-exist:true

[ingest-config1]
source-files:/tmp/customer1.parquet
staging-location:s3://cust-bucket/warehouse/staging/
staging-s3-creds:AWS_ACCESS_KEY_ID=zzzzzz,AWS_SECRET_ACCESS_KEY=vvvvvv,ENDPOINT=http://some_site/xxx.com?addsf:dfsdf,AWS_REGION=us-east-1,BUCKET_NAME=cust-bucket

[global-ingest-config]
target-tables:iceberg_cat.ice_schema.customer1_tab
ingestion-engine:hostname=localhost,port=8080
create-if-not-exist:true

[ingest-config1]
source-files:/tmp/
staging-location:s3://cust-bucket/warehouse/staging/
staging-s3-creds:AWS_ACCESS_KEY_ID=zzzzzz,AWS_SECRET_ACCESS_KEY=vvvvvv,ENDPOINT=http://some_site/xxx.com?addsf:dfsdf,AWS_REGION=us-east-1,BUCKET_NAME=cust-bucket
: Support replication [basic auth credentials in auth object](https://github.com/apache/couchdb/pull/3586).

Basic auth credentials
: No longer display basic auth credentials (for example, username:) in the output of these endpoints:



* _scheduler/jobs
* _scheduler/docs
* _active_tasks









 April 2021 



 1 April 2021 

The following changes were made in build 8192:

New! Fair share replicator
: Added Fair share replicator. For more information, see [Fair Share Replication Scheduler Implementation](https://github.com/apache/couchdb/commit/ab38c2dd3f429ce8f347fa4f04e2815b810a8a19).

Improvements
: Internal bug fixes.







 March 2021 



 15 March 2021 

The following changes were made in build 8182:

Improvements
: Internal bug fixes.

Caching
: Apply caching to account-local _users databases.

Error condition
: Treat 408 as a retryable error condition for replicator.

Compressed requests
: Allow compressed (gzipped) requests to /_session endpoint.

/_active_tasks endpoint
: Show process status in /_active_tasks endpoint.

/{DB}/_changes endpoint
: Validate JSON payload on POST to /{DB}/_changes endpoint.







 December 2020 



 1 December 2020 

The following changes were made in build 8169:

New! Mango query operator
: Introduce the Mango query operator, $keyMapMatch that offers the ability to make queries on the keys of a map.

Improvements
: Internal bug fixes.

Database reporting
: Report the database that was used for authentication for a GET /_session request, provided it is configured.







 September 2020 



 1 September 2020 

The following changes were made in build 8162:

Improvements
: Internal bug fixes.

Drilldown parameters
The support to use custom providers is not available in the shared multi-tenant Schematics service. It is only available with Agents. Agents does not include a local or private provider registry. The registry must be provided and configured by the user on the users private network accessible to the agents.

By default, Schematics jobs running the Terraform CLI will download Terraform provider plug-ins or Terraform modules from the public Terraform registry via the Internet or public network. When an Agent is deployed on a private network, security policies may dictate that a proxy or mirror site must be used for downloading and caching provider plug-ins. Additionally it may be desired to use custom developed Terraform providers to configure environment specific resources using Terraform.

For these usecases, Terraform allows configuration of provider download from alternate provider registries via the use of a provider_installation block in the Terraform CLI configuration. This allows customization of the Terraform default installation behavior. Review the Terraform documentation for [provider installation](https://developer.hashicorp.com/terraform/cli/config/config-fileprovider-installation) for more detail on configuring provider download.

When using Agents, the following two workspace environment variables, can be used to configure the Terraform CLI to refer to an alternate repository and select providers by name and namespace from this registry.



* The TF_NETWORK_MIRROR_URL Terraform private repository, website or Artifactory instance where custom Terraform providers are hosted.
* The TF_NETWORK_MIRROR_PROVIDER_NAME name and namespace of provider that is to be downloaded from the custom location. Refer to the Terraform documentation for [provider naming and namespaces](https://developer.hashicorp.com/terraform/language/providers/requirementsnames-and-addresses). This is an optional variable. If not specified it is defaulted to all providers in all namespaces "/".



Schematics auto generates the following Terraform CLI configuration file parameters which tell Terraform during job execution to use an alternate registry for some or all of the providers you intend to use.

provider_installation {
network_mirror {
exclude = ["user_namespace/provider_name"]
}
}





 Configuring a remote Artifactory provider registry 

A remote Artifactory registry can be used to cache public providers for use by Terraform, without giving Terraform public network access. Artifactory access is configured using the following workspace environment variables, to configure the Terraform CLI to refer to the the remote repository and retrieve all providers using this proxy registry.

TF_TOKEN_name.artifactory.user.com:<artifactory_remote_registry_token>TF_NETWORK_MIRROR_URL=https://name.artifactory.user.com/artifactory/api/terraform/user-terraform-remote/providers/

Refer to the Artifactory documentation and UI to source the values for the bearer token and URL of the remote registry.

Schematics will generate a Terraform CLI configuration of the form below.

provider_installation {
network_mirror {
url = "https://name.artifactory.user.com/artifactory/api/terraform/user-terraform-remote/providers/"
include = ["/"]
}
direct {
exclude = ["/"]
}
}





 Configuring a virtual Artifactory provider registry 

A virtual Artifactory registry can be used to combine the hosting of custom provides with the caching of public providers for use by Terraform. Artifactory access is configured using the following workspace environment variables, to configure the Terraform CLI to refer to the the virtual repository and retrieve all providers using this proxy registry.

TF_TOKEN_name.artifactory.user.com:<artifactory_virtual_registry_token>TF_NETWORK_MIRROR_URL=https://name.artifactory.user.com>/artifactory/api/terraform/<user-terraform-virtual/providers/

Refer to the Artifactory documentation and UI to source the values for the bearer token and URL of the virtual registry. The virtual repository must be configured as an aggregate of a local and remote registry as discussed in the previous sections.

Schematics will generate a Terraform CLI configuration of the form below.
: The solution now checks for a valid license that is associated with ibm_customer_number, which has been added as a required variable.







 October 2022 



 27 October 2022 

Windows® support
: You can now deploy Windows® worker nodes in your IBM Spectrum Symphony cluster.







 September 2022 



 23 September 2022 

Bug fix
: Code fixes were applied to address an issue that was seen in regions where instance storage profiles are not available even though Spectrum Scale is not selected as the storage option.

Updated RHEL stock image
: Made an update to use a RHEL 8.6 stock image instead of a RHEL 8.2 stock image for the login node and the NFS storage node.







 August 2022 



 11 August 2022 

Bug fix
: Code fixes were applied related to an Ansible version 2.10 upgrade.







 June 2022 





 30 June 2022 

Security update and enhancements
: This release provides fixes for the Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034) and for the Spring Framework Vulnerability (CVE-2022-22965) within the RHEL 8.4 based custom image accessible by the solution. This release also removes the earlier Polkit mitigation implemented through changes to the post-provisioning scripts. The RHEL 8.4 custom image replaces the RHEL 8.2 image that was provided in the previous release. In addition, changes in the code now allow creation of compute nodes in the cluster by Host Factory on VPC resource groups other than the default group. And, security group rules have been added to provide more secure access to the cluster by allowing SSH from only specific nodes.





 January 2022 



 28 January 2022 

IBM Spectrum Symphony enhancements
: You now have the option to use Spectrum Scale for shared storage that's accessible by the Spectrum Symphony compute nodes. For more information, see [Using Spectrum Scale storage](https://cloud.ibm.com/docs/hpc-spectrum-symphony?topic=hpc-spectrum-symphony-using-spectrum-scale-storage).
"SAP HANA Backint Agent for Amazon S3" requires Python3.7, including SSL support. The Python package delivered as part of the SAP HANA 2 installation does not include SSL support. Python 3.7 with SSL support is installed in addition in /usr/local/bin directory, in case it isn't previously installed. SAP HANA Backint Agent for Amazon S3 is installed in /hana/shared/< SID >/backint_agent directory.

The setup runs onetime initial full data backup to Cloud Object Storage for SYSTEM and TENANT databases. The regular backup policy for the databases must be configured by the customer.

All data backup, log backup, and catalog backup files are saved in the same dedicated bucket (with no enforced storage quota) created in a Cloud Object Storage instance by using an existing bastion host with secure remote SSH access in the same IBM Cloud Gen2 VPC as the SAP HANA system. The setup uses the REGIONAL Storage Class with the Smart Tier pricing option and the STANDARD pricing plan. The SAP HANA system must be previously deployed on one of the following Operating Systems: SUSE Linux Enterprise Server 15 SP 4 for SAP, SUSE Linux Enterprise Server 15 SP 3 for SAP, Red Hat Enterprise Linux 8.6 for SAP, Red Hat Enterprise Linux 8.4 for SAP.





 Script files 

The configuration and script files are provided on GitHub. Each supported interface for the SAP solution installation has its own folder in the GitHub repository:

[GitHub repository for Terraform - HANA backup COS](https://github.com/IBM-Cloud/sap-hana-backup-cos)





 Terraform interface 

To run the Terraform scripts, you modify:



* The input.auto.tfvars file to specify the existing VPC resources for your solution. You specify the variables for the existing VPC:



* VPC name
* Security group
* Subnet
* HostName(s)





You can change the default SAP system configuration settings to match your solution. You also specify the location where you downloaded the SAP kits.
Retail use cases for IBM Cloud 

These use cases highlight how workloads on Red Hat® OpenShift® on IBM Cloud® can take advantage of analytics for market insights, multi-region deployments across the globe, and inventory management with IBM® Event Streams for IBM Cloud® and object storage.



 Brick-and-mortar retailer shares data, by using APIs with global business partners to drive omnichannel sales 

A Line-of-Business (LOB) Exec needs to increase sales channels, but the retail system is closed off in an on-premises data center. The competition has global business partners to cross-sell and up sell permutations of their goods: across brick-and-mortar and online sites.

Red Hat OpenShift on IBM Cloud provides a public-cloud ecosystem, where containers enable new business partners and other external players to co-develop apps and data, through APIs. Now that the retail system is on the public cloud, APIs also streamline data sharing and jump-start new app development. App deployments increase when Developers experiment easily, pushing changes to Development and Test systems quickly with toolchains.

Red Hat OpenShift on IBM Cloud and key technologies:



* [Clusters that fit varied CPU, RAM, storage needs](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesplanning_worker_nodes)
* [IBM Cloud® Object Storage to persist and sync data across apps](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-getting-started-cloud-object-storage)
* [DevOps native tools, including open toolchains in IBM Cloud® Continuous Delivery](https://www.ibm.com/cloud/architecture/toolchains/)





 Context 



* The retailer is faced with strong competitive pressures. First, they need to mask the complexity of crossing into new products and new channels. For example, they need to expand product sophistication. At the same time, it needs to be simpler for their customers to jump across brands.
* That ability to jump brand means that the retail ecosystem requires connectivity to business partners.