vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Referencing a full configmap --env-from-configmap NAME where NAME is the name of the configmap or --env-from-configmap PREFIX=NAME to reference the full configmap where each key is prefixed with PREFIX. [job create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-job-create), [job update](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-job-update), [jobrun submit](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-jobrun-submit), [jobrun resubmit](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-jobrun-resubmit) [app create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-application-create), [app update](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-application-update) 
 Referencing specific keys in a secret --env-from-secret NAME:KEY_A,KEY_B where KEY_A,KEY_B are the keys of a key-value pair.
For example, add the "address_prefix_management": "manual" parameter when you create the VPC by using the API.

To bring your own subnets:



1. Create a VPC.
2. For each zone in which you plan to create subnets, create one or more address prefixes.
3. When you create subnets in each zone, specify IP ranges that are within one of the address prefixes that you created for that zone.



If you use an IP range outside of those ranges [RFC 1918](https://tools.ietf.org/html/rfc1918) (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) defined for a subnet, the instances that you attach to that subnet might be unable to reach parts of the public internet. If you plan to configure VPCs that use both non-RFC-1918 addresses and also have public connectivity (floating IPs or public gateways), make sure to use a custom route that contains the Delegate-VPC action.



 Address prefixes and the IBM Cloud console 

When you create a VPC by using the IBM Cloud console, the system selects your address prefixes automatically and requires you to create subnets within the default prefixes. If this address scheme does not suit your requirements, you can clear the Default address prefixes option to not assign default address prefixes to each zone in your VPC. After you create your VPC, go to its details page and set your own address prefixes. Then, you can create subnets within the address prefixes you specified.





 CLI example 

The following example shows you how to use the CLI to bring your own IP addresses for subnets in the 'us-south-1' and 'us-south-2' zones of your VPC.



1. Create an address prefix named my-first-prefix in the us-south-1 zone:

ibmcloud is vpc-address-prefix-create my-first-prefix $VPC us-south-1 172.16.0.0/23
2. Create an address prefix named another-prefix in the us-south-2 zone:
* ibmcloud is instance-template-create my-template-name my-vpc us-south-1 mx2-2x16 my-subnet --image r123-72b27b5c-f4b0-48bb-b954-5becc7c1dcb8 --dedicated-host-group my-dedicated-host-group Create instance template to be placed in the wanted dedicated host group by using resource name.
* ibmcloud is instance-template-create my-template-name my-vpc us-south-1 mx2-2x16 my-subnet --image r123-72b27b5c-f4b0-48bb-b954-5becc7c1dcb8 --placement-group my-placement-host-group Create instance template to be placed in the wanted placement group by using resource name.
* ibmcloud is instance-template-create my-template-name my-vpc us-south-1 bx2-2x8 --image ibm-ubuntu-20-04-2-minimal-amd64-1 --primary-network-interface '{"name": "primary-nic", "allow_ip_spoofing": true, "subnet": {"name":"my-subnet"}, "primary_ip": {"name": "my-reserved-ip"}, "security_groups": [{"name": "my-security-group-1"}, {"name": "my-security-group-2"}]}' Create instance template with primary network interface configuration by using resource name.
* ibmcloud is instance-create my-instance-name my-vpc us-south-1 mx2-2x16 my-subnet --image r123-72b27b5c-f4b0-48bb-b954-5becc7c1dcb8 --dedicated-host-group my-dedicated-host-group Create instance to be placed in the wanted dedicated host group by using resource name.
* ibmcloud is instance-create my-instance-name my-vpc us-south-1 mx2-2x16 my-subnet --image r123-72b27b5c-f4b0-48bb-b954-5becc7c1dcb8 --placement-group my-placement-host-group Create instance to be placed in the wanted placement group by using resource name.
* ibmcloud is instance-create my-instance-name my-vpc us-south-1 bx2-2x8 --image ibm-ubuntu-20-04-2-minimal-amd64-1 --primary-network-interface '{"name": "primary-nic", "allow_ip_spoofing": true, "subnet": {"name":"my-subnet"}, "primary_ip": {"name": "my-reserved-ip"}, "security_groups": [{"name": "my-security-group-1"}, {"name": "my-security-group-2"}]}' Create instance with primary network interface configuration by using resource name.
Key GET /keys [List all keys](https://cloud.ibm.com/apidocs/vpc/latestlist-keys) 
 VPC GET /vpcs [List all VPCs](https://cloud.ibm.com/apidocs/vpc/latestlist-vpcs) 
 Subnet GET /subnets [List all subnets](https://cloud.ibm.com/apidocs/vpc/latestlist-subnets) 
 Zone GET /regions/<region>/zones [List all zones in a region](https://cloud.ibm.com/apidocs/vpc/latestlist-region-zones) 
 Placement groups GET /placement_groups [List all placement groups](https://cloud.ibm.com/apidocs/vpc/latestlist-placement-groups) 







 Creating an instance by using the API 

After you retrieved the information that you need, you can run the [POST /instances](https://cloud.ibm.com/apidocs/vpc/latestcreate-instance) method to create an instance.





 Provision an instance from a stock or custom image by using the API 

You can provision an instance with a stock or custom image by specifying the image's id subproperty as the value of the image property.

curl -X POST "$vpc_api_endpoint/v1/instances?version=$api_version&generation=2" -H "Authorization:$iam_token" -d '{
"name": "my-instance",
"zone": {
"name": "us-south-3"
},
"vpc": {
"id": "'$vpc'"
},
"primary_network_interface": {
"subnet": {
"id": "'$subnet'"
}
},
"keys":[{"id": "'$key'"}],
"profile": {
"name": "'$profile_name'"
},
"image": {
Referencing secrets and configmaps with environment variables (CLI) 

In Code Engine, after you create secrets and configmaps, the information that is stored as key-value pairs can be consumed by your job or application as an environment variable by referencing the full secret or configmap or by referencing individual keys.

The following table lists command information for setting environment variables on jobs and apps to reference secrets and configmaps.



Setting environment variables from secrets and configmaps

 Action Option format Commands for jobs Commands for apps 

 Referencing a full secret --env-from-secret NAME where NAME is the name of the secret or --env-from-secret PREFIX=NAME to reference the full secret where each key is prefixed with PREFIX. [job create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-job-create), [job update](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-job-update), [jobrun submit](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-jobrun-submit), [jobrun resubmit](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-jobrun-resubmit) [app create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-application-create), [app update](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-application-update) 
 Referencing a full configmap --env-from-configmap NAME where NAME is the name of the configmap or --env-from-configmap PREFIX=NAME to reference the full configmap where each key is prefixed with PREFIX.
Assigning the next larger subnet size (/23) allows for horizontal scaling beyond the limits that were given previously because it allows for adding new subnets to each layer, from within the same address prefix.

After you determine the correct subnet size, you can assign the actual address prefixes, one for each zone:



Table 2. Zones assigned address prefixes

 Zone Address prefix 

 Zone 1 172.16.0.0/23 
 Zone 2 172.16.2.0/23 
 Zone 3 172.16.4.0/23 



And from this basis, you can also assign the three subnets within each zone:



Table 3. Subnets assigned within each zone

 Zone Tier Subnet CIDR 

 Zone 1 Middle 172.16.0.0/25 
 Zone 1 Front 172.16.1.0/26 
 Zone 1 Database 172.16.1.128/27 
 Zone 2 Middle 172.16.2.0/25 
 Zone 2 Front 172.16.3.0/26 
 Zone 2 Database 172.16.3.128/27 
 Zone 3 Middle 172.16.4.0/25 
 Zone 3 Front 172.16.5.0/26 
 Zone 3 Database 172.16.5.128/27 







 Considerations for extending an existing infrastructure 

When you're planning a VPC that extends an existing infrastructure, you can follow the previous steps, whether that infrastructure is your on-premises infrastructure, another VPC, or even another cloud. Keep in mind that you must not reuse existing address ranges. By avoiding address reuse, you can maximize your ability to take advantage of IBM Cloud VPC features.
Connecting to your on-premises network 

You can use IBM Cloud VPN for VPC to securely connect your VPC to an on-premises network through a VPN tunnel. This topic provides guidance about how to configure your VPN gateway to connect to your on-premises network.

Create a VPN gateway in your VPC and create a VPN connection between the VPC and the peer gateway of the on-prem network by specifying the following information.



* Connection name - Enter a name for the connection, such as onprem-connection.
* Peer gateway address - Specify the IP address of the VPN gateway for the on-prem network.
* Preshared key - Specify the authentication key of the VPN gateway for the on-prem network.
* Local subnets (Policy-based VPN only) - Specify one or more subnets in the VPC you want to connect through the VPN tunnel.
* Peer subnets (Policy-based VPN only) - Specify one or more subnets in the on-prem network you want to connect through the VPN tunnel.



For the Internet Key Exchange (IKE) and IPsec security parameters, select Auto so the cloud gateway uses auto-negotiation to automatically establish the connection with the on-premises gateway.

The gateway status appears as Pending while the VPN gateway is being created, and the status changes to Available after it is created.



 Configuring the on-premises VPN gateway 

The next step is configuring your on-premises VPN gateway peer to connect to your IBM Cloud VPN for VPC. The configuration depends on the type of VPN gateway. See the following topics for details.



* [Connecting to an AWS peer](https://cloud.ibm.com/docs/vpc?topic=vpc-aws-config)
* [Connecting to a Check Point Security Gateway peer](https://cloud.ibm.com/docs/vpc?topic=vpc-check-point-config)
* [Connecting to a Cisco ASAv peer](https://cloud.ibm.com/docs/vpc?topic=vpc-cisco-asav-config)
* --dns-servers: Space separated list of new DNS Servers to use for this network.
* --gateway: New gateway to use for this network.
* --ip-range: New IP addresses range or ranges for this network.
* --json: Format output in JSON.



--------------------







 ibmcloud pi networks 



 List all networks 

ibmcloud pi networks [--long] [--json]

Options



* --long: Retrieve all network details.
* --json: Format output in JSON.



--------------------







 ibmcloud pi placement-groups 



 List all server placement groups. 

ibmcloud pi placement-groups [--json]

Options



* --json: Format output in JSON.



--------------------







 ibmcloud pi placement-group-create 



 Create a server placement group. 

ibmcloud pi placement-group-create PLACEMENT_GROUP_NAME --policy POLICY [--json]



* PLACEMENT_GROUP_NAME: A unique name of the placement group.



Options



* --policy value: Affinity policy for placement group being created. Valid values are affinity and anti-affinity.
* --json: Format output in JSON.



--------------------







 ibmcloud pi placement-group-delete 



 Delete a server placement group. 

ibmcloud pi placement-group-create PLACEMENT_GROUP_NAME --policy POLICY [--json]



* PLACEMENT_GROUP_ID: The unique identifier of the placement group.



--------------------







 ibmcloud pi placement-group-server-add 



 Add a server to the server placement group.
If you want to configure a VPN connection for multiple workspaces for the same account, open a [Service Ticket](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-getting-help-and-support).





 Connecting to your on-premises network 

You can configure your VPN to connect to your on-premises network by following these steps in the Power Systems Virtual Server CLI or API.



1. [Create an IKE policy](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-VPN-connectionscreating-IKE-policies).
2. [Create an IPsec policy](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-VPN-connectionscreating-IKE-policies).
3. [Create a VPN connection](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-VPN-connectionscreating-VPN-connections).
4. Configure your on-premises IPsec gateway enduring IKE policy, IPsec policy, and VPN connection parameters that are compatible.





 Configuring the on-premises VPN gateway 

The next step is to configure your on-premises VPN gateway peer to connect to your IBM Cloud VPN Gateway for Power Virtual Server workspace. The configuration depends on the type of VPN gateway. See the following topics for details.

Any configurations that are not listed in this section are not supported by Power Systems Virtual Server. If you need a different configuration or predictable performance, you must opt for the configuration that is described in [Site-to-site VPN connectivity](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-vpn-connectivity) with redundant VPN connections.



* [Connecting to a Juniper vSRX peer](https://cloud.ibm.com/docs/vpc?topic=vpc-juniper-vsrx-config)
* UI







 Prepending an AS path to influence route priority 

In the situation where the same route prefixes are being advertised to IBM Cloud through the BGP session for Direct Link, you can prepend one or more Autonomous System Numbers (ASNs) to the route advertisement. AS prepend makes the AS path longer, and therefore, the route for the prefix is less preferred by the BGP protocol on the IBM Cloud router. If the duplicate route prefixes are received with the same AS path length from different origin routers, IBM Cloud gives preference to the oldest route received. In other words, the first BGP session that advertises a given route prefix receives path preference.

You can create AS prepends and manage your AS prepend configurations after direct link provisioning. You can also view prepended prefixes of other direct links.



 Before you begin 



* You must have two competing routes of equal priority before an AS prepend will take effect.
* Make sure to review [known limitations](https://cloud.ibm.com/docs/dl?topic=dl-known-limitations&interface=ui).







 Prepending an AS path by using the UI 

To prepend an AS path by using the UI, follow these steps:



1. From your browser, open the [IBM Cloud console](https://cloud.ibm.com/login) and log in to your account.
2. Select the Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) from the upper left, then click Interconnectivity > Direct Link.
3. In the Direct Link table, click the Direct Link name of the gateway where you want to manage route priority.
4. On the Details page, click the BGP tab and scroll to the AS prepends section. Then, click Go to AS prepends.

Alternatively, you can use the AS prepends shortcut on the Overview tab.
5. From the AS prepends page, click Create to create an AS prepend, or use the Actions !
You can specify your dedicated group (or dedicated host) as the placement_target. When you specify a dedicated group for the placement_target, the instance is provisioned to an available dedicated host within the group.

The profile family and class must match for the dedicated host or dedicated group and instances that are provisioned on them. For more information, see [Dedicated host profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-dh-profiles).

curl -X POST ”$vpc_api_endpoint/v1/instances?version=2020-11-17&generation=2" -H "Authorization: $iam_token" -d '{
"primary_network_interface": {
"name": "my-network-interface",
"subnet": {
"id": "0076-2249dabc-8c71-4a54-bxy7-953701ca3999"
}
},
"placement_target": {
"id": "0076-edf611ff-0fd6-44bf-b5f3-102eeb3cf928"
},
"name": "my-instance-2",
"zone": {
"name": "us-south-1"
},
"vpc": {
"id": "r006-e49dbfc6-03b5-4609-b680-684311be5457"
},
"profile": {
"name": "mx2-2x16"
},
"image": {
"id": "r006-72b27b5c-f4b0-48bb-b954-5becc7c1dcb8"
},
"keys": [
{
"id": "r006-c23faac2-5983-428c-91b8-2959620e1b96"
}
]
}'
The service-instance-create command supports a -p flag, which allows JSON-formatted parameters to be passed to the provisioning process. Some parameter values are Cloud Resource Names (CRNs), which uniquely identify a resource in the cloud. All parameter names and values are passed as strings.

For example, if a database is being provisioned from a particular backup and the new database deployment needs a total of 9 GB of memory across three members, then the command to provision 3 GBs per member looks like:

ibmcloud resource service-instance-create databases-for-mongodb <SERVICE_NAME> standard us-south -p '{
"backup_id": "crn:v1:blue:public:databases-for-mongodb:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71717:backup:06392e97-df90-46d8-98e8-cb67e9e0a8e6",
"members_memory_allocation_mb": "3072"
}'







 Provisioning through the Resource Controller API 

Follow these steps to provision using the [Resource Controller API](https://cloud.ibm.com/apidocs/resource-controller/resource-controller).



1. Obtain an [IAM token from your API token](https://cloud.ibm.com/apidocs/resource-controller/resource-controllerauthentication).
2. You need to know the ID of the resource group that you would like to deploy to. This information is available through the [IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_resourceibmcloud_resource_groups).

Use a command like:

ibmcloud resource groups
3. You need to know the region you would like to deploy to.
Run the following command from the /opt/ocpinstall directory:

watch -n5 oc get clusteroperators
7. Monitor for cluster completion. An output is provided in the following example. Replace 4.x.5 with the current Red Hat OpenShift version, for example, 4.7.5.

Every 5.0s: oc get clusteroperators

NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE
authentication 4.x.5 True False False 20m
cloud-credential 4.x.5 True False False 38m
cluster-autoscaler 4.x.5 True False False 38m
console 4.x.5 True False False 27m
dns 4.x.5 True False False 35m
image-registry 4.x.5 True False False 14m
ingress 4.x.5 True False False 30m
kube-apiserver 4.x.5 True False False 33m
kube-controller-manager 4.x.5 True False False 33m
kube-scheduler 4.x.5 True False False 32m
machine-api 4.x.5 True False False 38m
machine-config 4.x.5 True False False 33m
marketplace 4.x.5 True False False 30m
monitoring 4.x.5 True False False 28m
network 4.x.5 True False False 37m
node-tuning 4.x.5 True False False 32m
openshift-apiserver 4.x.5 True False False 31m
openshift-controller-manager 4.x.5 True False False 33m
openshift-samples 4.x.5 True False False 24m
operator-lifecycle-manager 4.x.5 True False False 35m
operator-lifecycle-manager-catalog 4.x.5 True False False 35m
service-ca 4.x.5 True False False 38m
service-catalog-apiserver 4.x.5 True False False 32m
service-catalog-controller-manager 4.x.5 True False False 32m
storage 4.x.5 True False False 30m
Show more







 Related links
Change log for master fix pack 1.20.12_1561, released 17 November 2021 

The following table shows the changes that are in the master fix pack patch update 1.20.11_1561. Master patch updates are applied automatically.



Changes since version 1.20.11_1558

 Component Previous Current Description 

 Cluster health image v1.2.16 v1.2.18 Updated Go module dependencies and to use Go version 1.16.9. Updated image for [CVE-2021-22946](https://nvd.nist.gov/vuln/detail/CVE-2021-22946), [CVE-2021-22947](https://nvd.nist.gov/vuln/detail/CVE-2021-22947), [CVE-2021-33928](https://nvd.nist.gov/vuln/detail/CVE-2021-33928), [CVE-2021-33929](https://nvd.nist.gov/vuln/detail/CVE-2021-33929) and [CVE-2021-33930](https://nvd.nist.gov/vuln/detail/CVE-2021-33930). 
 etcd v3.4.17 v3.4.18 See the [etcd release notes](https://github.com/etcd-io/etcd/releases/v3.4.18). 
 Gateway-enabled cluster controller 1510 1567 Updated to use Go version 1.16.9.
4.7.59 4.7.60 For more information, see the [change log](https://docs.openshift.com/container-platform/4.7/release_notes/ocp-4-7-release-notes.htmlocp-4-7-60). 







 Change log for master fix pack 4.7.59_1589_openshift, released 16 November 2022 

The following table shows the changes that are in the master fix pack 4.7.59_1589_openshift. Master patch updates are applied automatically.



Changes since version 4.7.59_1587_openshift

 Component Previous Current Description 

 Cluster health image v1.3.12 v1.3.13 Updated Go dependencies, golangci-lint, gosec, and to Go version 1.19.3. Updated base image version to 116. 
 etcd v3.4.18 v3.4.21 See the [etcd release notes](https://github.com/etcd-io/etcd/releases/v3.4.21). 
 Gateway-enabled cluster controller 1823 1902 Go module updates.
Change log for master fix pack 1.20.15_1576, released 6 April 2022 



Changes since version 1.20.15_1574

 Component Previous Current Description 

 Load balancer and load balancer monitor for IBM Cloud Provider 1865 1899 Revert setting gratuitous ARP on LBv1. 







 Change log for master fix pack 1.20.15_1574, released 30 March 2022 



Changes since version 1.20.15_1571

 Component Previous Current Description 

 Cluster health image v1.3.3 v1.3.5 Updated image to fix CVEs [CVE-2021-3999](https://nvd.nist.gov/vuln/detail/CVE-2021-3999), [CVE-2022-23218](https://nvd.nist.gov/vuln/detail/CVE-2022-23218), [CVE-2022-23219](https://nvd.nist.gov/vuln/detail/CVE-2022-23219). Updated golang dependencies. 
 Gateway-enabled cluster controller 1653 1669 Updated to use Go version 1.17.8. 
 GPU device plug-in and installer d7daae6 13677d2 Updated GPU images to resolve CVEs. 
 IBM Calico extension 929 950 Updated to use Go version 1.17.8. Updated universal base image (UBI) to resolve CVEs. 
 IBM Cloud File Storage for Classic plug-in and monitor 405 407 Updated Go to version 1.16.14. Updated UBI image to version 8.5-240. 
 IBM Cloud RBAC Operator 0fc9949 6c43ef1 Upgraded Go packages to resolve vulnerabilities 
 Key Management Service provider v2.4.3 v2.5.3 Updated to use Go version 1.17.8. Updated golang dependencies. Fixed CVE [CVE-2022-24407](https://nvd.nist.gov/vuln/detail/CVE-2022-24407)
Cluster autoscaler add-on change log 

View information for patch updates to the cluster autoscaler add-on in your Red Hat OpenShift on IBM Cloud clusters.

Patch updates
: Patch updates are delivered automatically by IBM and don't contain any feature updates or changes in the supported add-on and cluster versions.

Release updates
: Release updates contain new features for the cluster autoscaler or changes in the supported add-on or cluster versions. You must manually apply release updates to your cluster autoscaler add-on. To update your cluster autoscaler add-on, see [Updating the cluster autoscaler add-on](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-install-addoncluster-scaling-update-addon).

Refer to the following tables for a summary of changes for each version of the [cluster autoscaler add-on](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-classic-vpc).

To view a list of add-ons and the supported cluster versions, run the following command or see the [Supported cluster add-ons table](https://cloud.ibm.com/docs/openshift?topic=openshift-supported-cluster-addon-versions).

ibmcloud oc cluster addon versions



 Version 1.1.0 (Beta) 

Version 1.1.0 is a Satellite Beta release. Patches might be slower on this version.



 Change log for patch update 1.1.0_1066, released 15 May 2023 



* Image tags: 1.21.0 110-9, 1.22.0 110-9, 1.23.0 110-9, 1.24.0 110-9, 1.25.0 110-9
* Resolves issues while reading secrets.







 Change log for patch update 1.1.0_1060, released 26 April 2023