vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Classic: Why can't I add worker nodes with an invalid VLAN ID? 

Classic infrastructure

 What’s happening 

Your IBM Cloud account was suspended, or all worker nodes in your cluster were deleted. After the account is reactivated, you can't add worker nodes when you try to resize or rebalance your worker pool. You see an error message similar to the following:

SoftLayerAPIError(SoftLayer_Exception_Public): Could not obtain network VLAN with id 123456.

 Why it’s happening 

When an account is suspended, the worker nodes within the account are deleted. If a cluster has no worker nodes, IBM Cloud infrastructure reclaims the associated public and private VLANs. However, the cluster worker pool still has the previous VLAN IDs in its metadata and uses these unavailable IDs when you rebalance or resize the pool. The nodes fail to create because the VLANs are no longer associated with the cluster.

 How to fix it 

You can [delete your existing worker pool](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_worker_pool_rm), then [create a new worker pool](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_worker_pool_create).

Alternatively, you can keep your existing worker pool by ordering new VLANs and using these to create new worker nodes in the pool.

Before you begin: [Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)



1. To get the zones that you need new VLAN IDs for, note the Location in the following command output. Note: If your cluster is a multizone, you need VLAN IDs for each zone.

ibmcloud oc cluster ls
2.
Why do I get an error about a cloud object storage bucket when I create a cluster? 

Infrastructure provider: VPC

 What’s happening 

When you create a cluster, you see an error message similar to the following.

Could not store the cloud object storage bucket and IAM service key.

Could not find the specified cloud object storage instance.

Could not create an IAM service key to access the cloud object storage bucket '{{.Name}}'.

Could not create a bucket in your cloud object storage instance.

Verify your user permissions and the API key permissions to Cloud Object Storage, or use a different instance that you have permissions to, and try again. For more information, see 'http://ibm.biz/roks_cos_ts'.

 Why it’s happening 

When you create a Red Hat OpenShift on IBM Cloud version 4 cluster on VPC generation 2 compute infrastructure, a bucket is automatically created in a standard IBM Cloud Object Storage instance that you select in your account.

However, the bucket might not create for several reasons such as:



* IBM Cloud Object Storage is temporarily unavailable.
* No standard IBM Cloud Object Storage instance exists in your account, or the person whose API key is set for the region and resource group does not have permissions to view the instance.
* The person who created your cluster did not have the Administrator platform access role to IBM Cloud Object Storage in IAM.
* The service failed to set up service key access to the object storage instance, such as if the API key lacks permissions or IBM Cloud IAM is unavailable.
* Other conflicts, such as naming conflicts that exhaust the preset number of retries or saving the bucket and service key data in the backend service.



 How to fix it 

Manually set up your cluster to back up the internal registry to an IBM Cloud Object Storage bucket.



1. Make sure that the API key for the region and resource group is set and that you have the [required permissions to create a cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_referencecluster_create_permissions).
2.
[Best practices for securing the Schematics objects](https://cloud.ibm.com/docs/schematics?topic=schematics-bp-secure-objectsbp-secure-objects)



* [Best practices for creating Terraform Templates or modules in Git repositories](https://cloud.ibm.com/docs/schematics?topic=schematics-bp-secure-objectsbp-secure-repo)



* [What are the best practices that you must follow in developing the Terraform templates, and publishing the same in the Git repositories?](https://cloud.ibm.com/docs/schematics?topic=schematics-bp-secure-objectsbp-template-strategy)
* [Can you create tfvars files with the IBM Cloud® provider templates?](https://cloud.ibm.com/docs/schematics?topic=schematics-bp-secure-objectsbp-security-tfvars)
* [How can the Terraform developers ensure that the sensitive data is not leaked in the log files?](https://cloud.ibm.com/docs/schematics?topic=schematics-bp-secure-objectsbp-security-leak)



* [Best practices of managing Schematics Workspaces](https://cloud.ibm.com/docs/schematics?topic=schematics-bp-secure-objectsbp-workspaces)



* [What are the best practices that you must follow in creating a workspace for the Terraform template?](https://cloud.ibm.com/docs/schematics?topic=schematics-bp-secure-objectsbp-security-wks)
* [How can you ensure that the sensitive data used by the Terraform automation, do not leak in the logs or outputs?](https://cloud.ibm.com/docs/schematics?topic=schematics-bp-secure-objectsbp-security-leak-log)
* [How can you protect the access to workspaces and its data?]
These ESXi hosts can be used to host, for example, Juniper vSRX and they also behave such as [IBM Cloud gateway appliance](https://cloud.ibm.com/docs/gateway-appliance?topic=gateway-appliance-about).
4. You can add additional vSphere clusters on this secondary location. You can add vSphere clusters with different host specifications, and define how to functionally position these clusters and what workloads are run on each cluster.
5. You can add NFS based IBM Cloud File Storage for Classic to your clusters in the new data center location. These NFS shares are local to the data center, and they cannot be accessed from the initial data center.
6. You can also use vSAN with your vSphere clusters in the new data center location. When using vSAN, due to the nature of dedicated local storage, you must select vSAN option when ordering the cluster. This deployment pattern does not offer stretched vSAN clusters.
7. The hosts in the new data center (or POD) are attached to VLANs and subnets that are local to that IBM Cloud data center or POD. These VLANs and subnets cannot be extended or moved to other IBM Cloud data centers. However, these subnets can communicate with subnets that are provisioned to another IBM Cloud data center over IBM Cloud private network.



If you deploy clusters or hosts in another POD of the same IBM Cloud data center, you must use the same backend NFS storage. The storage is assigned for each cluster separately.





 Considerations for single site vCenter Server deployment topologies 

When designing or deploying this architecture pattern, you should take the following into consideration:



* You have several options to expand the capacity for the deployment, for example by provisioning new hosts on the initial cluster or by adding new clusters.
* This pattern provides a few examples how to expand and customize the initial deployment for a few use cases to fit your needs, but note that these are just examples.
* You should note VMware limitations.
Identify what user credentials are used for the region and resource group's infrastructure permissions.



1. Check the API key for a region and resource group of the cluster.

ibmcloud ks api-key info --cluster <cluster_name_or_ID>

Example output

Getting information about the API key owner for cluster <cluster_name>...
OK
Name Email
<user_name> <name@email.com>
2. Check if the classic infrastructure account for the region and resource group is manually set to use a different IBM Cloud infrastructure account.

ibmcloud ks credential get --region <us-south>

Example output if credentials are set to use a different classic account. In this case, the user's infrastructure credentials are used for the region and resource group that you targeted, even if a different user's credentials are stored in the API key that you retrieved in the previous step.

OK
Infrastructure credentials for user name <1234567_name@email.com> set for resource group <resource_group_name>.

Example output if credentials are not set to use a different classic account. In this case, the API key owner that you retrieved in the previous step has the infrastructure credentials that are used for the region and resource group.

FAILED
No credentials set for resource group <resource_group_name>.: The user credentials could not be found. (E0051)



2. Validate the infrastructure permissions that the user has.



1. List the suggested and required infrastructure permissions for the region and resource group.

ibmcloud ks infra-permissions get --region <region>

For console and CLI commands to assign these permissions, see [Classic infrastructure roles](https://cloud.ibm.com/docs/containers?topic=containers-classic-roles).
2. Make sure that the [infrastructure credentials owner for the API key or the manually set account has the correct permissions](https://cloud.ibm.com/docs/containers?topic=containers-access-credsowner_permissions).
If you use a basic redirect, such as forwarding the root domain to www.yourdomain.com, you lose anything else in the URL. For example, you could set up the pattern:

example.com

And have it forward to:

http://www.example.com

But then if someone entered:

example.com/some-particular-page.html

Then they are redirected to:

www.example.com

instead of:

www.example.com/some-particular-page.html

The solution is to use variables. Each wildcard corresponds to a variable that can be referenced in the forwarding address. The variables are represented by a $ followed by a number. To refer to the first wildcard you'd use $1, to refer to the second wildcard you'd use $2, and so on. To fix the forwarding from the root to www in the previous example, use the same pattern:

example.com/

Then set up the following URL for traffic to forward to:

http://www.example.com/$1

In this case, if someone went to:

example.com/some-particular-page.html

They are redirected to:

http://www.example.com/some-particular-page.html
FAQs: SSL certificates 



 Why doesn't the SSL certificate that I ordered automatically show up on the SSL certificates screen? 

SSL certificates are issued by a third-party certificate authority, which sends all of the certificate details directly to you in a confidential email. After receiving that email, you have the option to [import the SSL certificate](https://cloud.ibm.com/docs/infrastructure/ssl-certificates?topic=ssl-certificates-importing-ssl-certificatesimporting-ssl-certificates) to the IBM Cloud® console should you choose to use the certificate with IBM Cloud products and services. Because IBM Cloud never receives the details for SSL certificate, data cannot be imported automatically.





 What is an SSL certificate? 

SSL certificates are enabled by websites as a security measure to protect the user. They are generally used when you are required to transmit confidential information to a website, such as name, address, credit card numbers, and other personal data or are managing data that requires authentication (such as in the IBM Cloud console). SSL certificates are requested by the company that runs the website but are issued by a trusted, third-party company that ensures the validity of the website. Secure websites are preceded by HTTPS in the URL, as opposed to the standard HTTP.





 How can I order an SHA2 SSL? 

If you already ordered an SSL and it is showing errors that the SSL certificate is using SHA-1 instead of SHA-2, you need to request that the SSL is re-issued. You can do this by submitting a ticket.

If you have not yet ordered an SSL from IBM Cloud and need to order one with SHA-2, submit a ticket to manually order an SSL for the domain in question. IBM Cloud console still automatically creates SSL certificates using SHA-1, so if you do this, you will then need to have it re-issued.





 Why do I need to choose an email? 

To create an SSL certificate, you need to verify that you own the domain where you are requesting the SSL certificate. You can verify that you own the domain in one of two ways:



1.
-t = deployment type of this VM (RHEL, RHEL-SAP, RHEL-SAP-NETWEAVER)

b. For SLES, run the following command:

. /usr/local/bin/sles-cloud-init.sh -s RMT_Server_address -p private_ip_of_proxy_vm:3128

-s = the URL of the SLES Repository Mirroring Tool (RMT) server that you are using for registration

-p = "private_ip_of_powervs_vm":3128

If the system is already registered, you need to de-register the system before registering again by running the following two commands: SUSEConnect --de-register

SUSEConnect –cleanup

If the registration fails and the following note appears in the logs:

Could not register with SLES RMT servers, Please verify connection to the proxy server. If proxy is verified, it may be an issue with SLES RMT servers undergoing maintenance. If so, please try executing the command again within a few minutes

Then it could be a network issue and you should attempt to register again at a later time.
Access groups allow you to assign a minimal number of policies by giving the same access to all users and service IDs that belong to the same access group. In other words, instead of assigning the same access multiple times to multiple users or service IDs, you can create a group and assign a single policy to that group. This helps save time and keep access permissions organized.

The best practice for setting up access groups is to create one access group per wanted level of access. Then, you can map each access group to the previously created resource groups. For example, you might create Auditor, Developer, and Admin groups, then assign access to these groups based upon the individual’s role.

Now that you know what access groups are and why they’re important, let’s go over how to create an access group.

In the IBM Cloud console, click “Manage” and then “Access (IAM).” Then, select “Access Groups” and click “Create.”

Here you will enter the name and description for the group. Then, click “Create.

After you create an access group, you can then add users and service IDs to the group (clicks Users and Service ID tabs within the UI for managing the created access group).

Before we dive into how to assign access to the access groups, you need to understand how IAM access policies provide access. A policy consists of a subject, target, and role (clicks Access policies tab). The subject is the access group. The target will be what you want the subject to access. This could be a set of resources, a service instance, all services in the account, or all instances of a service.

Access policies can only be set for IAM-enabled services and account management services (clicks "Assign access" button on the Access policies tab for the created access group, then highlights two tiles for IAM-enabled services and Account management services). Cloud Foundry and Classic Infrastructure are separate.

The role defines the level of access granted to a user (Starts creating a policy by selecting All identity and access enabled services, then scrolling the available roles that display). The most commonly used roles are viewer, editor, and administrator. The viewer role provides the least amount of access for viewing instances and resource groups.
ipsec_policy_invalid_name 

Message: The name <ipsec_policy_name> is not a valid IPsec policy name.

A valid IPsec policy name starts with a letter, followed by letters, digits, underscores or hyphens.





 ipsec_policy_not_created 

Message: The IPsec policy <ipsec_policy_id> could not be created.

Try again in a few minutes. If this problem persists, [contact support](https://cloud.ibm.com/docs/vpc-on-classic?topic=vpc-on-classic-getting-help-and-support).





 ipsec_policy_not_deleted 

Message: The IPsec policy <ipsec_policy_id> could not be deleted.

Try again in a few minutes. If this problem persists, [contact support](https://cloud.ibm.com/docs/vpc-on-classic?topic=vpc-on-classic-getting-help-and-support).





 ipsec_policy_not_found 

Message: The IPsec policy <ipsec_policy_id> could not be found.

You referenced an IPsec policy that does not exist. Review your request and specify a valid IPsec policy ID. If you are sure the policy exists, [contact support](https://cloud.ibm.com/docs/vpc-on-classic?topic=vpc-on-classic-getting-help-and-support).





 ipsec_policy_not_updated 

Message: The IPsec policy <ipsec_policy_id> could not be updated.

Try again in a few minutes. If this problem persists, [contact support](https://cloud.ibm.com/docs/vpc-on-classic?topic=vpc-on-classic-getting-help-and-support).





 key_content_exists 

Message: The same key content already exists.
For data center location, click the Edit icon ![Edit icon](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/icons/edit-tagging.svg) and select the geography, site, and location to host the instance.
6. Select the network type.
7. Complete the resource reservation.



* If you select Preconfigured, select the preconfigured vCPU model and RAM size.
* If you select Customizable, specify the reserved vCPU and RAM limits according to your requirements.



8. On the Summary pane, verify the configuration and estimated price before you place the order.
9. Click Create.







 Results after you order VMware Shared 



* The deployment of the resources starts automatically and you receive confirmation that the order is being processed. You can check the deployment status, including any issues that might require your attention, by viewing the Virtual Data Center Status.
* When the resources are successfully deployed, the components that are described in [Technical specifications for VMware Shared](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-shared_overviewshared_overview-specs) are installed on your VMware® virtual platform.
* When the resources are ready to use, the status of the virtual data center changes to Available.







 What to do next 

View the virtual data center that you ordered and then set the admin password for the VMware Cloud Director Management console. For more information, see [Viewing and managing virtual data centers](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-shared_viewing-vdc-summary).





 Related links 



* [Operating VMware Shared](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-shared_vcd-ops-guide)
What if I want to connect my cluster to an on-prem data center? 

To connect your worker nodes and apps to an on-prem data center, you can configure a [VPN IPSec endpoint with a strongSwan service, a Virtual Router Appliance, or with a Fortigate Security Appliance](https://cloud.ibm.com/docs/openshift?topic=openshift-vpnvpn).





 Network segmentation and privacy for VPC clusters 

To protect your network and limit the range of damage that a user can do when access to a network is granted, you must make sure that your workloads are as isolated as possible and that you limit the number of apps and worker nodes that are publicly exposed.





 What network traffic is allowed for my VPC cluster by default? 

By default, worker nodes are connected to [VPC subnets](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-subnets) on the private network only and don't have a public network interface. All public ingress to your worker nodes is blocked. Public egress from your worker nodes is only allowed if the workers are connected to a VPC subnet that has a public gateway.

To access default Red Hat OpenShift components such as the web console or OperatorHub without being connected to your VPC's private network, you must attach a [public gateway](https://cloud.ibm.com/docs/vpc?topic=vpc-about-networking-for-vpcpublic-gateway-for-external-connectivity) to the VPC subnets that the worker nodes are deployed to. All egress is permitted for worker nodes on a subnet with an attached public gateway, but all ingress is still blocked.

If you deploy apps in your cluster that must receive traffic requests from the internet, you can [create a VPC load balancer](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaas) to expose your apps.
Release notes for the IBM Cloud platform 

Stay up-to-date with the new features that are available on the IBM Cloud® platform so that you get the most out of your IBM Cloud experience.



 July 2023 



 11 July 2023 

New multizone region (MZR) available in Madrid
: Resources can be deployed to a new MZR in Madrid, Spain. There are three data centers available in the eu-es region: MAD02, MAD04, and MAD05. For more information about location availability, see [Locations for resource deployment](https://cloud.ibm.com/docs/overview?topic=overview-locations).







 June 2023 



 6 June 2023 

New event notifications for projects
: You can now send out notifications when a deployment is complete or when resources are successfully destroyed. For more information, see the [available events for projects](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-event-notifications-events&interface=uievent-notifications-list).

Support for access management tags in the projects UI
: You can now add, edit, and delete access management tags directly in the projects UI. Previously, you could manage these tags only by using the command-line interface (CLI) or API.







 April 2023 



 25 April 2023 

Customized compliance validation
: In addition to using default controls, you can specify a Security and Compliance Center attachment to validate deployable architectures that you're configuring in a project. For more information, see [Configuring the architecture](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-config-projecthow-to-config).

Support for deployable architectures onboarded from private or public GitHub repositories
: You can now deploy architectures that are onboarded to the catalog from either a private or public GitHub repository. Previously, only deployable architectures onboarded from a public GitHub repository were supported.





 17 April 2023 

Check out deployable architectures in the catalog
FAQs 



 What Spectrum LSF packages are included in a cluster deployed with this offering? 

The following Spectrum LSF programs are included:



* IBM Spectrum LSF Standard Edition
* IBM Spectrum LSF License Scheduler
* IBM Spectrum LSF Data Manager







 What locations are available for deploying VPC resources? 

Available regions and zones for deploying VPC resources, and a mapping of those to city locations and data centers can be found in [Locations for resource deployment](https://cloud.ibm.com/docs/overview?topic=overview-locations).





 What permissions do I need in order to create a cluster using the offering? 

Instructions for setting the appropriate permissions for IBM Cloud services that are used by the offering to create a cluster can be found in [Granting user permissions for VPC resources](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-user-permissions-for-vpc-resources), [Managing user access for Schematics](https://cloud.ibm.com/docs/schematics?topic=schematics-access), and [Assigning access to Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-assign-access).





 How do I SSH among nodes? 

All of the nodes in the HPC cluster have the same public key that you register at your cluster creation. You can use ssh-agent forwarding, which is a common technique to access remote nodes that have the same public key. It automates to securely forward private keys to remote nodes. Forwarded keys are deleted immediately after a session is closed.

To securely forward private keys to remote nodes, you need to do ssh-add and ssh -A.

[your local PC]$ ssh-add {id_rsa for lsf cluster}
[your local PC] ssh -A -J root@jumpbox_fip root@management_private_ip
...
[root@management] ssh -A worker_private_ip

For Mac OS X, you can persist ssh-add by adding the following configuration to .ssh/config: