vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* If you did not specify a custom pod subnet during cluster creation, your cluster uses the default pod subnet. In the first cluster that you create in a VPC, the default pod subnet is 172.17.0.0/18. In the second cluster that you create in that VPC, the default pod subnet is 172.17.64.0/18. In each subsequent cluster, the pod subnet range is the next available, non-overlapping /18 subnet.







 How do I create subnets for classic infrastructure access? 

If you enable classic access when you create your VPC, [classic access default address prefixes](https://cloud.ibm.com/docs/vpc?topic=vpc-setting-up-access-to-classic-infrastructureclassic-access-default-address-prefixes) automatically determine the IP ranges of any subnets that you create. However, the default IP ranges for classic access VPC subnets conflict with the subnets for the IBM Cloud Kubernetes Service control plane. Instead, you must [create the VPC without the automatic default address prefixes, and then create your own address prefixes and subnets within those ranges for your cluster](https://cloud.ibm.com/docs/containers?topic=containers-vpc-subnetsclassic_access_subnets).





 Can I specify subnets for pods and services in my cluster? 

If you plan to connect your cluster to on-premises networks through IBM Cloud Direct Link or a VPN service, you can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for your pods, and a custom subnet CIDR to provide the private IP addresses for services.

To specify custom pod and service subnets during cluster creation, use the --pod-subnet and --service-subnet options in the ibmcloud ks cluster create CLI command.

To see the pod and service subnets that your cluster uses, look for the Pod Subnet and Service Subnet fields in the output of ibmcloud ks cluster get.





 Pods 

Default range
: In the first cluster that you create in a VPC, the default pod subnet is 172.17.0.0/18.
* If you did not specify a custom pod subnet during cluster creation, your cluster uses the default pod subnet. In the first cluster that you create in a VPC, the default pod subnet is 172.17.0.0/18. In the second cluster that you create in that VPC, the default pod subnet is 172.17.64.0/18. In each subsequent cluster, the pod subnet range is the next available, non-overlapping /18 subnet.







 How do I create subnets for classic infrastructure access? 

If you enable classic access when you create your VPC, [classic access default address prefixes](https://cloud.ibm.com/docs/vpc?topic=vpc-setting-up-access-to-classic-infrastructureclassic-access-default-address-prefixes) automatically determine the IP ranges of any subnets that you create. However, the default IP ranges for classic access VPC subnets conflict with the subnets for the Red Hat OpenShift on IBM Cloud control plane. Instead, you must [create the VPC without the automatic default address prefixes, and then create your own address prefixes and subnets within those ranges for your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-subnetsclassic_access_subnets).





 Can I specify subnets for pods and services in my cluster? 

If you plan to connect your cluster to on-premises networks through IBM Cloud Direct Link or a VPN service, you can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for your pods, and a custom subnet CIDR to provide the private IP addresses for services.

To specify custom pod and service subnets during cluster creation, use the --pod-subnet and --service-subnet options in the ibmcloud oc cluster create CLI command.

To see the pod and service subnets that your cluster uses, look for the Pod Subnet and Service Subnet fields in the output of ibmcloud oc cluster get.





 Pods 

Default range
: In the first cluster that you create in a VPC, the default pod subnet is 172.17.0.0/18.
Use the terraform apply and terraform destroy times in the following table as a reference for when you can expect your commands to complete.

If the Terraform on IBM Cloud operation does not complete due to a timeout, wait for the resource state change to complete and retry the operation.



Overview of Terraform apply and destroy command completion times

 Resource terraform apply return time terraform destroy return time 

 IBM Cloud platform resources A few seconds A few seconds 
 Virtual servers A few seconds A few seconds 
 IBM Cloud Load Balancers A few seconds Up to 30 minutes 
 Bare Metal servers Up to a few hours Up to a few hours 







 How do I set up Terraform on IBM Cloud greater than v0.13.0 ? 

For detailed steps, see how to [install the Terraform on IBM Cloud](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-setup_clitf_installation) and [install the IBM Cloud Provider plug-in](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-setup_cliinstall_provider).





 How can I resolve the error when provisioning a ibm_container_alb_cert resource with secret? 


stderr :
Error: Error waiting for create resource alb cert (buvlsclf0qcur3hjcrng/ingress-tls-cert) : The resource alb cert buvlsclf0qcur3hjcrng/ingress-tls-cert does not exist anymore: Request failed with status code: 404, ServerErrorResponse: {"incidentID":"5f82fa1696ce299a-IAD","code":"E0024","description":"The specified Ingress secret name is not found for this cluster."
Use the terraform apply and terraform destroy times in the following table as a reference for when you can expect your commands to complete.

If the Terraform on IBM Cloud operation does not complete due to a timeout, wait for the resource state change to complete and retry the operation.



Overview of Terraform apply and destroy command completion times

 Resource terraform apply return time terraform destroy return time 

 IBM Cloud platform resources A few seconds A few seconds 
 Virtual servers A few seconds A few seconds 
 IBM Cloud Load Balancers A few seconds Up to 30 minutes 
 Bare Metal servers Up to a few hours Up to a few hours 



* How do I set up Terraform on IBM Cloud greater than v0.13.0 ?

For detailed steps, see how to [install the Terraform on IBM Cloud](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-setup_clitf_installation) and [install the IBM Cloud Provider plug-in](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-setup_cliinstall_provider).
* How can I resolve the error when provisioning a ibm_container_alb_cert resource with secret?


stderr :
Error: Error waiting for create resource alb cert (buvlsclf0qcur3hjcrng/ingress-tls-cert) : The resource alb cert buvlsclf0qcur3hjcrng/ingress-tls-cert does not exist anymore: Request failed with status code: 404, ServerErrorResponse: {"incidentID":"5f82fa1696ce299a-IAD","code":"E0024","description":"The specified Ingress secret name is not found for this cluster."
10 February 2023 

New troubleshooting doc for how to recover after deleting a portable subnet in Classic clusters.
: For more information, see [I deleted a portable subnet and now my Classic cluster my Load Balancers are failing. How do I recover?](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-network-subnet-recover).





 9 February 2023 

Block Storage for VPC add-on version 5.1.
: For more information, see [the change log](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc_bs_changelog).





 8 February 2023 

Cloud Image Key Synchronizer add-on version 1.0.0_1329.
: For more information, see the [change log](https://cloud.ibm.com/docs/openshift?topic=openshift-image-key-synchronizer-changelog).





 2 February 2023 

Istio add-on 1.14
: Version 1.14 of the managed Istio add-on is no longer supported. For more information, see the [change log](https://cloud.ibm.com/docs/containers?topic=containers-istio-changelogv114).





 1 February 2023 

Persistent VPC load balancers
: You can now create a [persistent VPC load balancer](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaasvpc_lb_persist) that remains available even after your cluster is deleted.

Customized VPC load balancer health checks
: For more control over your VPC load balancer health checks, you can use [optional annotations](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaasvpc_lb_health_custom) to customize your health checks with advanced configurations for test intervals, timeouts, and retries.







 January 2023 



 30 January 2023
: After scaling, hosts enter a Reload required state and can't be used for scaling again, until they are rebooted. Unassign these hosts from the worker pool, remove them from your location, reboot them, and reattach to make them available for scaling again.

How do I set up autoscaling in my Satellite cluster
: To set up autoscaling, you must complete the following steps.



1. Create a Satellite location.
2. Set up the location control plane.
3. Attach hosts for the default worker pool.
4. Create a cluster that uses your Satellite hosts.
5. Verify or create the required storage secrets in your cluster.
6. Attach more hosts to your location and create a second worker pool in your cluster.
7. Attach more hosts to your location and leave them unassigned and available for scaling.
8. Install the cluster-autoscaler add-on.
9. Edit the autoscaler ConfigMap and enable scaling.







 Setting up your location and cluster for autoscaling 



1. [Create a location](https://cloud.ibm.com/docs/satellite?topic=satellite-locations) and set up your control plane.
2. After setting up your control plane, [attach more hosts](https://cloud.ibm.com/docs/satellite?topic=satellite-attach-hosts) that you want to use in the default worker pool for your cluster.
3. [Create a cluster in your location](https://cloud.ibm.com/docs/openshift?topic=openshift-satellite-clusters).
4. Copy the following storage-secret-store secret and save it as a file. You can find your openshift-api endpoint details on the Satellite Link endpoints [page for your location](https://cloud.ibm.com/satellite/locations).

apiVersion: v1
kind: Secret
metadata:
name: storage-secret-store
namespace: kube-system
type: Opaque
stringData:
You cannot mix and match BYOL and IBM-provided licensing for any VMware component within a cluster.





 Can you use BYOL when you create a cluster? 

No. BYOL is no longer supported except for migrations or upgrades of existing BYOL clusters. Select I will provide, and enter your own license key only if you are performing an upgrade or migration of an existing BYOL cluster.





 How do you manage BYOL licenses? 

You can manage your BYOL licenses by using the VMware vSphere Web Client.





 Does IBM provide support if you select the BYOL licensing option? 

IBM Support continues to be your point of contact for any instance configuration concern. However, if the reported concern is determined to be for a BYOL VMware component, you are directed to VMware Support.





 Related links 



* [Accessing the console](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-loginmethod)
* [Contacting IBM Support](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-trbl_support)
* [FAQ about licensing](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-faq_licensing)
For more information about how to specify version constraints, see the [Terraform documentation](https://developer.hashicorp.com/terraform/language/expressions/version-constraints).



 Version constraints for the Terraform CLI 

When you create a Schematics Workspaces and choose a Terraform version such as v0.13, your Terraform templates are executed by using the default patch version that is set in Schematics. For example, if you choose terraform_v0.13, your templates are applied by using Terraform v0.13.4. You can use the required_providers block in your provider definition to force the Terraform engine in Schematics to pull a later version.

You can only specify versions that are higher than the default MAJOR.MINOR.PATH version that is set in Schematics. In the codeblock version = "x.x.x" signifies the IBM Cloud provider version.

terraform {
required_providers {
version = "1.39.1"
}
}

You can specify Terraform required_versions that are higher than the default MAJOR.MINOR.PATH in the Terraform configuration file. In the codeblock the required_version = ">=1.0.0, <2.0" signifies the Terraform version.

terraform {
required_version = ">=1.0.0, <2.0"
required_providers {
ibm = {
source = "IBM-Cloud/ibm"
}
}
}





 Version constraints for Terraform providers 

To use any of the predefined [Schematics images](https://cloud.ibm.com/docs/schematics?topic=schematics-version-constraintsschematics-image-ov), you must explicitly declare the version of the IBM Cloud Provider plug-in in your Terraform template that includes the provider versions that you want.

If IBM Cloud Provider plug-in version is not declared in your Terraform template, the latest version of the provider plug-in is automatically used in Schematics.

Example to specify a predefined Schematics image:
FAQs about projects 

FAQs for IBM Cloud® projects might include questions about support options, configurations, access to projects, and cost estimation.



  What are IBM Cloud projects? 

As an enterprise, you use projects to ensure that the configuration of your deployable architecture is always compliant, cost effective, and secure. Projects are a named collection of configurations that are used to manage related resources and Infrastructure as Code (IaC) deployments across accounts.





  How do I add users to my project? 

To add a user to a project, they must be a member of your account with correct IAM access roles assigned.

To assign access to the IBM Cloud Projects service, complete the following steps:



1.  In the IBM Cloud console, click Manage > Access (IAM), and then select Users.
2.  Click the user or access group that you want to assign access, then go to Access > Assign access.
3.  For the service, select Project. Then, click Next.
4.  Scope the access to All resources or Specific resources. Then, click Next.
5.  Select any combination of roles or permissions, and click Review.
6.  Click Add to add your policy configuration to your policy summary.
7.  Click Assign.



In addition, users must be assigned the Editor and Manager role on the Schematics service and the Viewer role on the resource group for the project.





  How do I estimate project costs? 

During the validation process, the starting costs for the project are estimated. You can view the cost details associated with the project from the validation modal after your changes to the configuration are saved and validated.





  Who has access to my project? 

Any user that is a member of your account that is assigned access to the IBM Cloud Projects service, Schematics, and the resource group for your project can access your project.
[Terraform](https://www.terraform.io/) is an open source project that lets you specify your cloud infrastructure resources and services by using a high-level scripting language. Your specification is stored in a Terraform configuration file. The complexity of using APIs, provisioning, and managing your cloud resources is removed from the user. The cloud providers create a plug-in for Terraform that contains the information for how to connect to the cloud provider. And what APIs to invoke with a certain cloud resource? IBM's plug-in is called the [IBM Cloud Provider Plug-in for Terraform](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-setup_cliinstall_provider).

To use the capabilities of the IBM Cloud Provider Plug-in for Terraform, you create a workspace that points to the Terraform configuration files that you want to provision. The plug-in analyzes the resources that you specified and determines the order in which these resources including any dependencies that must be provisioned. Review the following image for the detailed information about how to run Terraform configuration files with Schematics Workspaces.

Zoom

![Provisioning IBM Cloud resources with IBM Cloud Schematics and Terraform](https://cloud.ibm.com/docs-content/v1/content/ba89e173287b28d1453d2a327d8a1f74ae2f1662/schematics/images/schematics_flow.png)

Figure 1. Provisioning IBM Cloud resources with IBM Cloud Schematics and Terraform



1. Codify your IBM Cloud resources. Use Terraform HashiCorp Configuration Language (HCL) or JSON format to specify the IBM Cloud resources that you want to provision in your IBM Cloud environment. If you are not familiar with Terraform, you can select one of the default Terraform templates that Schematics provides to provision the IBM Cloud resources that you want.
Specifying version constraints 

Use version constraints to declare the Terraform, Terraform provider, or Ansible version that you want to use for your Terraform template, Ansible playbook or blueprint templates.

Schematics concurrently supports multiple images that each package a specific version of the IBM Cloud Provider plug-in, other Terraform providers, such as the REST API provider, and the Ansible executable. Each image is built, tested, and verified by IBM Cloud. Included Terraform provider versions are tested and packaged for a specific Terraform CLI version.

It is good practice to declare the version that your Terraform template, Ansible playbook or blueprint template requires by using version constraints. This way, you can ensure that your templates and playbooks continue to work, even if Terraform, Terraform providers, or Ansible publish new versions that might introduce breaking changes.



 Overview of Schematics images and packaged Terraform providers 

Use the ibmcloud schematics version command to retrieve a list of Schematics images and the Terraform provider and Ansible executable versions that are packaged in each image. For example in the following CLI output, the IBM Cloud Provider plug-in latest version is tested on Terraform v1.1.

Schematics supports the 5 most recent versions of IBM Cloud Provider Plug-in for Terraform binaries in its image. For more information, see [latest releases](https://github.com/IBM-Cloud/terraform-provider-ibm/releases). Following are some constraints that you must follow when using the IBM Cloud provider in your Terraform template.

It is recommended to use Terraform v1.0 or higher.



* If you are using Terraform v0.13 or higher, you can arbitrarily choose any version of the IBM Cloud provider, in your template. Then, Schematics automatically download the IBM Cloud provider either locally from the cache or remotely from the [HashiCorp Configuration Language (HCL) Terraform Registry](https://registry.terraform.io/namespaces/IBM-Cloud).
For example, when a usage report is generated the project tags will be included, allowing the accounting team to allocate costs to projects without any additional effort. Other types of configuration management tasks such as determining an inventory of particular types of applications or resources can also be accomplished by project tagging and resource views.





 Essential concepts 

Review the following concepts and processes to help you learn about working with projects in your account.



 Configurations 

A single project typically manages configurations for one or more IaC templates called deployable architectures in IBM Cloud. The set of input values and the architecture that you are configuring together become a configuration. In addition to providing review and approval work flows, projects monitor each configuration for cost, compliance, and version updates from the catalog.

Typically, a project holds several configurations of each architecture. An architecture might have separate configurations for the development, test, and production environments, or for three separate regions, all of which are in the production environment.





 Deployable architectures 

Projects provide governance and management for deployable architectures, which are infrastructure as code templates. [Custom deployable architectures can be developed](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-customize-from-catalog) by using the tooling of your choice and can be [added to a private catalog](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-onboard-custom) in the IBM Cloud console. You must select Deployable Architecture as the type of product that you are onboarding for it to be used with projects.





 Project tooling 

Projects have internal versioned configuration storage and validation pipelines to support project governance. Projects also leverage Schematics workspaces to store the Terraform state for each configuration and to run the automation. These workspaces are in the region and resource group that you specify when you create the project. The Schematics workspace is also tagged with the project name, making it easier to identify that workspace among other ones.

Don't delete or directly modify these workspaces. This can cause projects to lose track of the configuration state that can lead to creation of duplicate resources and other issues.
Default: main

git_release





 modules.source.git.git_release 

Type: string

Default: implicitly latest

If content type is git, the release tag of the version of the Terraform config or module to be used. This option is mutually exclusive with the git_branch option. If not specified, Schematics will default to always pulling the latest commit during a blueprint update operation.







 modules.source.git.git_token 

Type: string

Default: []

Access templates in private Git repos by specifying the Git user token of the repo. The value for git_token can be sourced from the template inputs using the $blueprint token.

Example

git:
git_repo_url: "https://github.com/Cloud-Schematics/blueprint-example-modules/tree/main/IBM-ResourceGroup"
git_token: $blueprint.git_token





 modules.settings 

Type: list

Default: []

Optional

Environment variables are used to modify the behavior and execution of Terraform and Ansible without modifying the IaC code itself. Refer to the section [Using environment variables with workspaces](https://cloud.ibm.com/docs/schematics?topic=schematics-set-parallelism) for more information about the environment variables that can be passed to configure Terraform runtime behavior in Schematics.





 modules.settings.TF_VERSION 

Type: number

Optional

Blueprint templates set the Terraform version to be used at module execution time based on the value of TF_Version. This value can be used to pin the version of Terraform used by Schematics to remain compatible with the template supported version. Updating this value will change the Terraform version that is used on the next execution.

When not specified the required Terraform version is determined by inspecting the TF module code for a required_version definition. Based on the specified version or range of versions, Blueprints will used the most recent version of Terraform supported by Schematics.