vania-janet/multiturn-rag-retrieval-data huggingface dataset:
"j-rhel71.fyre.ibm.com",
3.145
],
"t": 1555404830
},
{
"d":
"j-rhel71.fyre.ibm.com",
4.09
],
"t": 1555404840
},
{
"d":
"j-rhel71.fyre.ibm.com",
5.057
],
"t": 1555404850
}
],
"end": 1555404850,
"start": 1555404790
}





 Sample: cURL sample to extract latest metric 

To get the latest value of a metric, specify only the metric name. The most recent value that was generated no more than 5 minutes ago is returned.

For instance, to get the latest value of host_cpu_used_percent:

curl <SYSDIG_REST_API_ENDPOINT>/prometheus/api/v1/query?query=sysdig_host_cpu_used_percent -H "Authorization: $AUTH_TOKEN" -H "IBMInstanceID: $GUID" -H "SysdigTeamID: $TEAM_ID" -H "content-type: application/json"

Where



* <SYSDIG_REST_API_ENDPOINT>indicates the endpoint targetted by the REST API call. For more information, see [Monitoring REST API endpoints](https://cloud.ibm.com/docs/monitoring?topic=monitoring-endpointsendpoints_rest_api). For example, the public endpoint for an instance that is available in us-south is the following: https://us-south.monitoring.cloud.ibm.com/api
* You can pass multiple headers by using -H.

Authorization and IBMInstanceID are headers that are required for authentication.

SysdigTeamID is optional. When you specify this header, you limit the request to the data and resources available for the team specified.
To enable VLAN spanning, you need the Network > Manage Network VLAN Spanning[infrastructure permission](https://cloud.ibm.com/docs/containers?topic=containers-access-credsinfra_access), or you can request the account owner to enable it. To check whether VLAN spanning is already enabled, use the ibmcloud ks vlan spanning get[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_vlan_spanning_get). You can't enable the private cloud service endpoint if you choose to enable VLAN spanning instead of VRF.









 Worker-to-master and user-to-master communication: Service endpoints 

A communication channel must be set up so that worker nodes can establish a connection to the Kubernetes master. You can allow your worker nodes and Kubernetes master to communicate by enabling the public cloud service endpoint only, public and private cloud service endpoints, or the private cloud service endpoint only.

To secure communication over public and private cloud service endpoints, IBM Cloud Kubernetes Service automatically sets up a Konnectivity connection between the Kubernetes master and the worker node when the cluster is created. Workers securely talk to the master through TLS certificates, and the master talks to workers through the OpenVPN connection.



 Public service endpoint only 

If you don’t want to or can't enable VRF for your account, your worker nodes can automatically connect to the Kubernetes master over the public VLAN through the public cloud service endpoint.



* Communication between worker nodes and master is established securely over the public network through the public cloud service endpoint.
* The master is publicly accessible to authorized cluster users only through the public cloud service endpoint. Your cluster users can securely access your Kubernetes master over the internet to run kubectl commands, for example.







 Public and private cloud service endpoints 

To make your master publicly or privately accessible to cluster users, you can enable the public and private cloud service endpoints. VRF is required in your IBM Cloud account, and you must enable your account to use service endpoints.
Migrating Cloud Foundry service instances and apps to a resource group 

To make your experience with using IBM Cloud® simpler and more flexible, we introduced [resource groups](https://cloud.ibm.com/docs/account?topic=account-rgs), which are conceptually similar to Cloud Foundry spaces. However, resource groups include several extra benefits, such as finer-grained access control by using IBM Cloud Identity and Access Management (IAM), the ability to connect service instances to apps and service across different regions, and an easy way to view usage per group.

We're starting to move services from Cloud Foundry to benefit from resource groups, which means when you see the Migrate icon ![Migrate this service instance to a resource group](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/account/images/migrate.svg) next to one of your services on the Resource list page, you must start a migration plan for your service instances or apps that are created through the [IBM Cloud App Service](https://cloud.ibm.com/developer/appservice/dashboard) to move from their current Cloud Foundry org and space to a resource group. Until an IBM Cloud service moves from using Cloud Foundry orgs, spaces, and roles to using IAM and resource groups, you can’t migrate your existing Cloud Foundry service instances to a resource group.

When you migrate existing Cloud Foundry service instances or App Service apps to a resource group, the group that you choose can't be changed after the migration is complete. So, it's essential to plan how you want to organize resources in the account before you migrate. This might mean that you need to create one or more resource groups, if you have a billable account, before migrating.

You can try organizing your resources in resource groups the same way you organized resources in Cloud Foundry spaces. For more information about using resource groups, see [Best practices for organizing resources and assigning access](https://cloud.ibm.com/docs/account?topic=account-account_setup).



 Why migrate? 



 Cloud Foundry service instances
Why can't I access a project? 

You try to find a project that you created or a project that you thought you had access to from the Projects page in the console, but it isn't listed.

  What’s happening 

A project that you expected to find in the console from the Menu![Menu icon](https://cloud.ibm.com/docs-content/v1/content/d4595e5202a9a27767cf034e81b038cdf772e0d5/icons/icon_hamburger.svg) > Projects page isn't included in your list of projects.

  Why it’s happening 

Your project might have been deleted by another member of your team, or you don't have the required level of access to view projects.

  How to fix it 

Make sure that you have the correct access to view projects. For more information, see [Assigning users access to projects](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-access-project). If your project was deleted, create a new one. If you have the IBM Cloud® Activity Tracker service set up for your account, you can use that to [audit events for a project](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-at_events), including project deletions.
Why can't I see a location that another user gave me access to? 

 What’s happening 

You are granted access to another user's Satellite location. However, when you list locations, you do not see the location.

 Why it’s happening 

The location owner might have scoped your Satellite access in IBM Cloud IAM to only the location resource type, which prevents the location from returning unless you target the regional endpoint that the location is managed from.

 How to fix it 

Target the regional endpoint, or ask the location owner to update your permissions.



 Target the regional endpoint 



1. Ask the location owner which [IBM Cloud multizone region](https://cloud.ibm.com/docs/satellite?topic=satellite-sat-regions) the Satellite location is managed from. For example, the owner can run ibmcloud sat location get --location <location_name_or_ID> and review the Managed from field.
2. From the CLI, [target the regional endpoint](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_init), such as Washington, D.C. (us-east) in the following example.

ibmcloud oc init --host https://us-east.containers.cloud.ibm.com
3. Verify that you can view the Satellite location.

ibmcloud sat location ls



If you still cannot view the Satellite location, ask the location owner to check your access policy. If the access policy is scoped to a particular location, the policy must be scoped to the location ID, not to the location's name.





 Ask the location owner to update your permissions 

Ask the location owner to update your access policy in IBM Cloud IAM so that access to Satellite locations is no longer scoped to locations. The steps vary depending on how the location owner set up your access policy. The following commands provide examples for updating access group and individual policies from the CLI.
The lessons in this tutorial walk you through creating a sample web server app, exposing the app by using a network load balancer (NLB) service, and protecting the app from unwanted unusual traffic with both allowlist and blocklist Calico policies.



 Objectives 



* Learn to block all incoming traffic to all node ports by creating a high-order Pre-DNAT policy.
* Learn to allow specific source IP addresses to access the NLB public IP and port by creating a low-order Pre-DNAT policy. Lower-order policies override higher-order policies.
* Learn to block specific source IP addresses from accessing the NLB public IP and port by creating a low-order Pre-DNAT policy.







 Audience 

This tutorial is intended for software developers and network administrators who want to manage network traffic to an app.





 Prerequisites 



* [Create a classic cluster with at least 3 worker nodes. Single worker node clusters don’t have the required resources to complete this tutorial](https://cloud.ibm.com/docs/openshift?topic=openshift-clusters). This tutorial is not available for VPC clusters.
* [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
* [Install and configure the Calico CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policiescli_install).
* Ensure that you have the following IBM Cloud IAM access policies for IBM Cloud Kubernetes Service:



* [Any platform access role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms)
* [The Writer or Manager service access role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms)









 Step 1: Deploy an app and expose it by using an NLB 

The first lesson shows you how your app is exposed from multiple IP addresses and ports, and where public traffic is coming into your cluster.
For more information, see [IBM Cloud Load Balancer migration FAQs](https://cloud.ibm.com/docs/loadbalancer-service?topic=loadbalancer-service-faqs-for-ibm-cloud-load-balancer).
* Migrate your [IBM Cloud Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-migrate-data-centermigrating-your-resources) data to a new IBM Cloud data center.



Copy only applications and application data between systems. Copying older versions of operating system files to a newer version can cause problems. Shut down databases before you copy them between the systems to ensure that the data is consistent. When migrating database data, migrate the data in a way that doesn’t limit your options to import it into the new system. Rather than copying database data from system to system, consider exporting it to a format so you can import it to a newer database. Flat text files, CSV files, and other files provide more options than using proprietary or closed file formats when it comes to moving data between systems. Always test your data migration approaches on a small set of test data before officially copying.
4. Cancel your servers. You continue to be invoiced for the old servers until you cancel them. For more information, see [Device types and actions](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-managing-virtual-serversdevice-types-and-actions).
With scaling policy, you save money by only paying for virtual servers when you need them and deleting them when you don’t.

Placement group can be used with auto scale. If at any point the (min or max) number of VSI is greater than 3, then placement group is recommended with auto scale.

Auto scale adjusts resources in an automated and orchestrated fashion and is available in both compute and cloud load balancer configurations.



* Compute – Scaling the virtual server instances is determined by the average target load utilization across all of the virtual server instances in the Auto scale group. Target load utilization can be based on CPU, memory, network, or a combination of these resources. If the virtual server instances load is not at the wanted target load, then instances automatically scale - up or down - to meet the average target load utilization. The number of virtual server instances that are being added or deleted will exceed the minimum or maximum virtual server instances for an Auto scale group. More information on Auto scale can be found [here](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-auto-scale-instance-group).



Zoom

![Autoscale.](https://cloud.ibm.com/docs-content/v1/content/df269b100c3499f1efcbb7d030dce8dec25c539b/ha-infrastructure/images/autoscale-compute.svg)

Figure 1. Auto scale Compute adds virtual servers based on load



* Cloud load balancers – Auto scale for the cloud load balancer has two parts. The first part is the horizontal scaling of the cloud load balancer. The cloud load balancer scales depending on load so that it does not become the bottleneck. This process is managed by the IBM cloud controller. The second part is making the cloud load balancer aware of membership changes to the backend server pool. In a non-Auto scale environment, this adjustment is made by the customer manually; the customer must add or remove virtual instances from the backend server pool. With Auto scale, this adjustment is an automated process and removes the need for customer intervention.



Zoom

!
Why do I get a manifest unknown error? 

You get a manifest unknown error when you try to pull an image in IBM Cloud® Container Registry.

  What’s happening 

You're trying to pull an image, but you receive the following manifest error message: manifest unknown

  Why it’s happening 

The manifest does not exist in the registry.

  How to fix it 

To resolve the problem, try the following options:



*  Check that the image name is correct.
*  Check that you're pointing at the correct Container Registry region by running the [ibmcloud cr region](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_region) command.
Supplemental VRA documentation (current) 

You can find links to supplemental documentation here for the Vyatta 5600 OS 17.2 or newer. For archived supplemental documentation for the Vyatta 5600 OS older than 17.2, see [this topic](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-supplemental-vra-documentation-archivedsupplemental-vra-documentation-archived).

AT&T Vyatta vRouter and the AT&T Vyatta Network Operating System are referred to as a virtual router, vRouter, or router in these guides.



Vyatta 5600 OS 17.2 or newer documentation

 Vyatta documentation Description 

 [ALG Configuration Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_alg_configuration_5600.pdf) This guide describes the Application Layer Gateways (ALGs) available on the AT&T Vyatta Network Operating System. 
 [Basic Routing Configuration Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_basic_routing_configuration_5600.pdf) This guide describes information about forwarding and routing on AT&T products that run on the AT&T Vyatta Network Operating System. 
 [Basic System Configuration Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_basic_system_configuration_5600.pdf) This guide describes the architecture of the products that run on the AT&T Vyatta Network Operating System. It includes basic system concepts and describes how to use the CLI of the router, perform basic system management and monitoring tasks, manage user accounts, access system logs, and hot-plug interfaces.
[jmathews@shelladmindal0101 ]$ ssh 10.115.174.6 -l vyatta
Welcome to AT&T vRouter

Welcome to AT&T vRouter
Version: 5.2R6S5
Description: AT&T vRouter 5600 5.2R6S5
Last login: Fri Feb 2 12:42:45 2018 from 10.0.80.100
vyatta@acs-jmat-vyatta01:$ show int
-vbash: show: command not found

In this case, the problem is not with the upgrade itself. If there were errors in that process, you would see them when you issued the add system image command. In this instance, the device was rebooted, but it now has a new and empty /home directory space, and any users that appear in the configuration need their home directories regenerated. The error stems from the failure to properly copy the needed "dotfiles" to the vyatta user directory:

vyatta@acs-jmat-vyatta01:$ ls -la
total 16
drwxr-x--- 3 vyatta users 4096 Feb 2 12:44 .
drwxr-xr-x 1 root root 4096 Feb 2 11:57 ..
-rw------- 1 vyatta users 456 Feb 2 12:44 .bash_history
-rw-r--r-- 1 vyatta users 0 Feb 2 12:43 .bash_logout
-rw-r--r-- 1 vyatta users 0 Feb 2 12:43 .bashrc
-rw-r--r-- 1 vyatta users 0 Feb 2 12:43 .profile
drwxr-x--- 2 vyatta users 4096 Feb 2 11:57 .ssh

Note that three files are zero length, and thus have no configuration. Without the commands to initialize the environment for the VRA user on login, the current shell is unable to interpret the Vyatta commands you issue.
Why are the ibm-cloud-provider-ip pods for the Istio ingress gateway stuck in pending? 

Virtual Private Cloud

Classic infrastructure

Multizone clusters only

 What’s happening 

When you run kubectl get pod -n ibm-system, the ibm-cloud-provider-ip pod that provides the external IP address for your Istio ingress gateway is stuck in the pending status.

Additionally, when you run kubectl describe pod <pod_name> -n ibm-system for the ibm-cloud-provider-ip pod, you notice a scheduling conflict error in the pod's events section of the output.

To identify the ibm-cloud-provider-ip pod for your gateway, you can run kubectl get service -n istio-system to find your gateway's load balancer service, note its EXTERNAL-IP, and look for the IP address in the ibm-cloud-provider-ip pod name.

 Why it’s happening 

When an istio-ingressgateway load balancer service is created, an ibm-cloud-provider-ip pod is created to provide an external IP address to the load balancer.

These ibm-cloud-provider-ip pods have a node affinity rule so that they are created in the same zone as the subnet from which the IP address is derived. However, when the ExternalTrafficPolicy setting for the istio-ingressgateway load balancer service is set to Local, then the ibm-cloud-provider-ip pod also has a pod affinity rule to be deployed to the same zone as the gateway load balancer pod. If the IP address and gateway load balancer exist in different zones in your cluster, the ibm-cloud-provider-ip pod can't properly deploy.

To verify that the ibm-cloud-provider-ip and istio-ingressgateway pods don't exist in the same zone:



1. Identify the NODE that your istio-ingressgateway pod is deployed to.

kubectl get pod -n istio-system -o wide
2. Get the EXTERNAL-IP address for the gateway's load balancer service.

kubectl get service -n istio-system
3.
Why does no Ingress subdomain exist after I create clusters of the same or similar name? 

Virtual Private Cloud

Classic infrastructure

  What’s happening 

You create and delete a cluster multiple times, such as for automation purposes.

Every time that you create the cluster, you use either the same name or a name that is very similar to previous names that you used. When you run ibmcloud ks cluster get --cluster <cluster>, your cluster is in a normal state but no Ingress Subdomain or Ingress Secret are available.

  Why it’s happening 

When you create and delete a cluster that uses the same name multiple times, the Ingress subdomain for that cluster in the format <cluster_name>.<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud is registered and unregistered each time.

The certificate for the subdomain is also generated and deleted each time. If you create and delete a cluster with the same name 5 times or more within 7 days, you might reach the Let's Encrypt [Duplicate Certificate rate limit](https://letsencrypt.org/docs/rate-limits/?origin_team=T4LT36D1N), because the same Ingress subdomain and certificate are registered every time that you create the cluster. Because very long cluster names are truncated to 24 characters in the Ingress subdomain for the cluster, you can also reach the rate limit if you use multiple cluster names that have the same first 24 characters.

  How to fix it 

If you need to continue testing, you can change the name of the cluster so that when you create the new cluster a new, different Ingress subdomain and secret are registered.
Why does no Ingress subdomain exist after I create clusters of the same or similar name? 

Virtual Private Cloud

Classic infrastructure

Satellite

  What’s happening 

You create and delete a cluster multiple times, such as for automation purposes.

Every time that you create the cluster, you use either the same name or a name that is very similar to previous names that you used. When you run ibmcloud oc cluster get --cluster <cluster>, your cluster is in a normal state but no Ingress Subdomain or Ingress Secret are available.

  Why it’s happening 

When you create and delete a cluster that uses the same name multiple times, the Ingress subdomain for that cluster in the format <cluster_name>.<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud is registered and unregistered each time.

The certificate for the subdomain is also generated and deleted each time. If you create and delete a cluster with the same name 5 times or more within 7 days, you might reach the Let's Encrypt [Duplicate Certificate rate limit](https://letsencrypt.org/docs/rate-limits/?origin_team=T4LT36D1N), because the same Ingress subdomain and certificate are registered every time that you create the cluster. Because very long cluster names are truncated to 24 characters in the Ingress subdomain for the cluster, you can also reach the rate limit if you use multiple cluster names that have the same first 24 characters.

  How to fix it 

If you need to continue testing, you can change the name of the cluster so that when you create the new cluster a new, different Ingress subdomain and secret are registered.
Classic clusters: Why are no ALBs deployed in a zone? 

Classic infrastructure

 What’s happening 

When you have a multizone classic cluster and run ibmcloud ks ingress alb ls --cluster <cluster>, no ALB is deployed in a zone. For example, if you have worker nodes in 3 zones, you might see an output similar to the following in which a public ALB did not deploy to the third zone.

ALB ID Enabled Status Type ALB IP Zone Build ALB VLAN ID NLB Version
private-cr96039a75fddb4ad1a09ced6699c88888-alb1 false disabled private - dal10 ingress:1.1.2_2507_iks 2294021 -
private-cr96039a75fddb4ad1a09ced6699c88888-alb2 false disabled private - dal12 ingress:1.1.2_2507_iks 2234947 -
private-cr96039a75fddb4ad1a09ced6699c88888-alb3 false disabled private - dal13 ingress:1.1.2_2507_iks 2234943 -
public-cr96039a75fddb4ad1a09ced6699c88888-alb1 true enabled public 169.xx.xxx.xxx dal10 ingress:1.1.2_2507_iks 2294019 -
public-cr96039a75fddb4ad1a09ced6699c88888-alb2 true enabled public 169.xx.xxx.xxx dal12 ingress:1.1.2_2507_iks 2234945 -

 Why it’s happening 

In standard clusters, the first time that you create a cluster in a zone, a public VLAN and a private VLAN in that zone are automatically provisioned for you in your IBM Cloud infrastructure account.

In that zone, 1 public portable subnet is requested on the public VLAN that you specify and 1 private portable subnet is requested on the private VLAN that you specify.