vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Information about the network interface that is created for the new instance is not returned after the instance is created.

From the output that's returned, save the ID of the instance in a variable so you can use it later, for example:

instance="0738-21179496-964e-4c00-8210-cf23d75750b3"

The status of the instance is pending when it's first created. Before you can proceed, the instance needs to move to the running status, which takes a few minutes. To check the status of the instance, run this command:

ibmcloud is instance $instance

From the output that's returned, save the ID of the primary network interface (Primary Interface) in a variable so you can use it later, for example:

nic="0738-4d9b3a58-f796-4e6a-b5ac-84f4216e9b68-glhvl"





 Create a block storage data volume 

You can create a block storage volume and attach it to your virtual server instance if you want more storage. When you create a block storage volume, you select a profile to optimize the performance of your compute workloads. See [Profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-profilesblock-storage-profiles) for information about volume capacity and IOPS ranges based on the volume profile you select.

To see a list of volume profiles, run:

ibmcloud is volume-profiles

Run this command to create a block storage data volume. Specify a name for your volume, volume profile, and the zone where you are creating the volume. To attach a block storage data volume to an instance, the instance and the block storage data volume must be created in the same zone.

ibmcloud is volume-create my-volume custom us-south-2 --iops 1000

From the output that's returned, save the ID of the volume in a variable so you can use it later:
VPC clusters: Why can't my app connect via Ingress? 

Virtual Private Cloud

 What’s happening 

You exposed your app by creating an Ingress resource for your app in your VPC cluster. When you tried to connect to your app by using the Ingress subdomain, the connection failed or timed out.

 Why it’s happening 

When you create a VPC cluster, one public and one private VPC load balancer are automatically created outside of your cluster in your VPC.

The VPC load balancer routes requests to the apps that the ALBs expose. Requests can't be routed to your app in the following situations:



* A VPC security group is blocking incoming traffic to your worker nodes, including incoming requests to your app.
* The VPC load balancer is offline, such as due to load balancer provisioning errors or VSI connection errors.
* The VPC load balancer is deleted through the VPC console or the CLI.
* The VPC load balancer's DNS entry is still registering.



 How to fix it 

Verify that no VPC security groups are blocking traffic to your cluster and that the VPC load balancer is available.



1. Install the infrastructure-service plug-in. The prefix for running commands is ibmcloud is.

ibmcloud plugin install infrastructure-service
2. Verify that the VPC load balancer for your ALBs exists. In the output, look for the VPC load balancer Name that starts with kube-crtmgr-<cluster_ID>. If you did not install the infrastructure-service plug-in, install it by running ibmcloud plugin install infrastructure-service.

ibmcloud is load-balancers



* If the VPC load balancer is not listed, it was deleted through the VPC console or the CLI. To re-create the VPC load balancer for your ALBs, disable all the public or private ALBs that are assigned that VPC load balancer's hostname by running ibmcloud ks ingress alb disable vpc-gen2 --alb <ALB_ID> -c <cluster_name_or_ID> for each ALB.
Auditing events 

You can use IBM Cloud® Activity Tracker to track and audit how users and applications interact with IBM Cloud® Schematics.



 Schematics events 

IBM Cloud Activity Tracker records user-initiated activities that change the state of a service in IBM Cloud. You can use this service to investigate abnormal activity and critical actions and to comply with regulatory audit requirements. In addition, you can be alerted about actions as they happen. The events that are collected comply with the Cloud Auditing Data Federation (CADF) standard. For more information, see [Getting started tutorial for IBM Cloud Activity Tracker](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-getting-started).

The following lists of Schematics events are sent to IBM Cloud Activity Tracker.



 Workspace events 



Workspace events

 Action Description 

 schematics.workspace.read An event is generated for a request to view a Schematics Workspace by a user. 
 schematics.workspace.create An event is generated for a request to create a Schematics Workspace. 
 schematics.workspace.update An event is generated for a request to update a Schematics Workspace. 
 schematics.workspace.delete An event is generated for a request to delete a Schematics Workspace. 
 schematics.workspace-resources.create An event is generated when a Terraform execution apply is created for a workspace. 
 schematics.workspace-resources.plan An event is generated when a Terraform execution plan is created for a workspace. 
 schematics.workspace-resources.delete An event is generated for a request to delete the IBM Cloud resources that are provisioned through a Terraform plan and the workspace. 







 Action events 



Action events

 Action Description 

 schematics.action.create A Schematics action is created or failed to create. 
 schematics.action.delete A Schematics action was deleted or failed to delete. 
 schematics.action.read A Schematics action is viewed by a user. 
 schematics.action.update A Schematics action is updated successfully or failed to update. 







 Job events 



Job events
The date of finding is when the continuous compliance (CC) pipeline runs and finds the issue in the production environment. If the issue exists, CC updates it with the Due Date that is calculated from that moment.

<due date> = <date of finding the issue in prod> + <grace period in days (determined by severity)>





 Due date format 

Due date is in ISO 8601 format and shows as YYYY-MM-DD.

Example: Due Date: 2022-04-01





 Use cases 



* A vulnerability is found in one of the base images in production by the CC pipeline. The team is notified of an incident issue with a grace period set according to the severity of the vulnerability. The grace period is the number of days that the team have to deploy a fix.
* The team builds a new release with a new feature. The build finds a CVE associated with the base image that is used for the application. The team runs the CC pipeline manually, which scans artifacts already in production. The manual CC run detects the same CVE in the same application in production and adds the Grace Period to the Incident Issue. The team now can build and deploy without being blocked.







 Differences between issue processing in CI and CC pipelines 

Incident issues are created in both CI and CC pipelines:



* An issue that is created in CI means it was found during the build.
* An issue that is created in CC means it was found in the production environment.



A Due Date can be added automatically to issues only if they are related to problems found in the production environment. This means that only the CC pipeline is allowed to add the Due Date to an issue. If CI finds the issue and the Due Date is not available, the value of the Due Date is n/a.





 Processing results into issues 

Issues for problems that are found are created according to the results of specific tools. The collect-evidence script attempts to process the result files in the attachments and create a list of issues.

Issues are bound to assets, which can be commits in a repository or a docker image with a digest.

An issue is created for every issue ID - an issue ID is composed of the following components:



* Bound asset
They can be altered within the same design document without invalidating other unchanged indexes in the same document.

Zoom

![A database is created with 1000 documents. A design document is added which triggers the building of 2 views and 2 search indexes. The view builds asynchronously until it is complete. The arrival of a second version of the design document invalidates all MapReduce views and any changed search indexes in the document.](https://cloud.ibm.com/docs-content/v1/content/522c6f62358b063f921283400a601c3f9bc66f08/Cloudant/images/DesDocMan02.svg)

Figure 2. Design document version change





 Managing changes to a design document 

Imagine at some point in the future you decide to change the design of the view. Now, instead of returning the actual timestamp result, we're only interested in the count of how many documents match the criteria. To achieve this count, the map function stays the same, but you now use a reduce of _count.

See an example design document that uses a reduce function:

{
"_id": "_design/fetch",
"_rev": "2-a2324c9e74a76d2a16179c56f5315dba",
"views": {
"by_ts": {
"map": "function(doc) {
if (doc.ts) {
emit( doc.ts, null);
}
}
}",
"reduce": "_count"
},
"language": "javascript"
}

When this design document is saved, IBM Cloudant completely invalidates the old index and begins building the new index from scratch, iterating over every document in turn. As with the original build, the time that it takes depends on how many documents are in the database. The build also blocks incoming queries on that view until it's complete.

But there's a problem...
* PCI (Peripheral Component Interconnect) interface represents a physical network interface. It is possible to include up to 8 PCI interfaces on a bare metal server.
* VLAN (Virtual LAN) interface represents an interface that is associated with a PCI interface through the VLAN ID. The VLAN interface automatically tags traffic that is routed through it with the VLAN ID. Inbound traffic that is tagged with a VLAN ID is directed to the appropriate VLAN interface.



PCI interface in a IBM Cloud bare metal server is a physical PCI device that can be created or deleted only when the IBM Cloud bare metal server is stopped. PCI interface has an allowed_VLANs property, which controls the VLANs that permit to use the PCI interface. VLAN interface is a virtual device, which is used through a PCI device that has the VLAN in its array of allowed_VLANs.

The allowed VLANs list must be updated for all PCI interfaces hosts separately if you start using new VLAN IDs in your solution.

Every VLAN interface must use an IEEE 802.1q tag. It is important to understand that these VLAN tags have only local significance to the server. They can be used internally to isolate or separate the traffic, for example, in Distributed Virtual Switches. While each VLAN interface can attach to only one subnet, you can create multiple VLAN interfaces in a bare metal server. Each of these interfaces can be attached to a specific subnet.

VLAN interfaces are created for every virtual machine (VM) which needs to be attached to a VPC subnet. For example, VLAN interface that is created for vCenter can use VLAN tag 100 and this VLAN interface can be provisioned to a management subnet in VPC. When deploying a vCenter VM, it is attached to vSphere vSwitch and uses a port group that is defined with VLAN tag 100. When the vCenter uses the IP of the vLAN interface as provided by VPC, it is logically attached to a management subnet in VPC just like any other VPC Virtual Server.

You can set VLAN interfaces to be floatable.
The following chart illustrates how the master key register state changes during the master key rotation.

Zoom

![How master key register state changes during master key rotation](https://cloud.ibm.com/docs-content/v1/content/217f108cc44e2ce15fb692d4b57b4c628464e908/hs-crypto//images/rotate-master-key.svg)

Figure 1. How master key register state changes during master key rotation



 Rotating master keys by using smart cards and Management Utilities 

Master keys that are created with the Management Utilities can be rotated by using the smart cards, where master key parts are stored. Before you rotate the master key, you need to create the key parts that you are going to use.

You can create a new master key value using either 2 or 3 key parts. To be able to rotate the master key, the current master key registers must be in Valid state with the same verification pattern, and the new master key registers must be Empty.

You can rotate the master key using the Management Utilities regardless of whether your service instance has recovery crypto units assigned to it or not.

The following flow shows how master key rotation works in this mode:



1. Load the new master key register by clicking the Load button in the Trusted Key Entry application. The state of the new master key register is changed from Empty to Full uncommitted.
2. Commit the new master key value by clicking the Commit button in the Trusted Key Entry application. The new master key register state is changed to Full committed.
3. Reencrypt key storage and activate the new master key by clicking the Rotate button in the Trusted Key Entry application:



1. Encryption keys in key storage are decrypted by using the value in the current master key register and then reencrypted by using the value in the new master key register. The rewrapping takes place inside the hardware security module (HSM), so it's secure.
2. The new master key is activated and loaded to the current master key register in Valid state, and the new master key register is cleared and back to Empty state.
In addition to the vDS port group that is created for NFS storage traffic, a VMkernel port is created on each vSphere ESXi host during the deployment. The VMkernel port is assigned to the SDDC-DPG-NFS port group. The VMkernel port is also assigned an IP address from the private portable subnet that is associated with the attached storage VLAN (private VLAN B). The port MTU is set to 9000 to support jumbo frames.

Zoom

![Private vDS Port groups and uplinks](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/private_vds_portgroups_and_uplinks.svg)

Figure 1. Private vDS Port groups and uplinks



 vSphere host static routing 

Although the vDS is configured with a new port group and a VMkernel port is assigned to the port group, the solution creates a static route on each vSphere ESXi host in the deployment so that all NFS traffic traverses the VLAN and subnet for NFS. The static route is created in /etc/rc.local.d/local.sh so that it persists across host restarts.







 Related links 



* [Overview of VMware Solutions](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-solution_overview)
* [Build a network tutorial](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-build-networkibp-console-build-network) guides you through the process of hosting a network by creating an ordering service and a peer.
* Join a network tutorial (Current tutorial) Guides you through the process of joining an existing network by creating a peer and joining it to a channel.
* [Deploy a smart contract using Fabric v2.x](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-smart-contracts-v2ibp-console-smart-contracts-v2) provides information on how to write a smart contract and deploy it on your network.



You can use the steps in these tutorials to build a network with multiple organizations in one cluster for the purposes of development and testing. Use the Build a network tutorial if you want to form a blockchain consortium by creating an ordering service and adding organizations. Use the Join a network tutorial to connect a peer to the network. Following the tutorials with different consortium members allows you to create a truly distributed blockchain network.

Looking for a way to script the deployment of your nodes? If you are already familiar with the manual process to deploy the components with the console, you can check out the [Ansible playbooks](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ansible), a powerful tool for scripting the deployment of components in your blockchain network.

This tutorial is meant to show how to join a peer to an existing network. It presumes that an ordering service has already been created using another IBM Blockchain Platform console (it is possible to join peers created in the IBM Blockchain Platform to any network running Hyperledger Fabric based components using the Fabric APIs or the CLI, but we will not show that process here).
However, if it's February (January passed for this year), then the past January is returned also as an alternative date. An alternative date is also provided for weekdays when the weekday is specified without a modifier. For example, for the input Are you open Wednesday?, the future date is stored, but an alternative date with the date of the previous Wednesday is created also. Alternative dates are created for phrases that contain modifiers such as next, this, or last, which can have different meanings in different locales. The Watson Assistant service treats last and next dates as references to the most immediate last or next day that is referenced, which might be in either the same or a previous week. For some modifiers, an alternative date is created or not depending on the current day of the week. For example, maybe the input contains this Wednesday. If it's Monday, the future date is stored and no alternative date is created. However, if it's Wednesday, then the date is assumed to be the Wednesday of the coming week, but today's date is stored as an alternative date. Each alternative date is saved as an object that contains a value and confidence for each alternative date. The alternative date objects are stored in a JSON Array. To get an alternative value, use the syntax: @sys-date.alternative.
* .calendar_type: Specifies the calendar type for the timezone in use. GREGORIAN is the only supported type.
* .datetime_link: See [Date and time mentions](https://cloud.ibm.com/docs/assistant-data?topic=assistant-data-system-entitiessystem-entities-sys-date-time).
* .day: Helper method that returns the day in the date.
* .day_of_week: Returns the day of the week in the date as a lowercase string.
* .festival: Recognizes locale-specific holiday names and can return the date of the upcoming holiday, such as Thanksgiving, Christmas, and Halloween. Use all lowercase letters if you need to specify a holiday name, in a condition for example (@sys-date.festival == 'thanksgiving').
: The Monitoring access key that you want to use for your configuration. This value is optional. If you don't specify this option, the latest access key is used for your configuration.

--private-endpoint
: When you add this option to your command, the private cloud service endpoint is used to connect to IBM Cloud Monitoring. To use the private cloud service endpoint, your cluster must be enabled for using private cloud service endpoints.

Example command

ibmcloud ob monitoring config create --cluster mycluster --instance mymonitoringinstance





 ibmcloud ob monitoring config delete 

Virtual Private Cloud

Classic infrastructure

Delete a Monitoring configuration from your cluster.

To remove monitoring configurations that you manually set up without using the IBM Cloud Kubernetes Service observability plug-in, you must first make this configuration available to the plug-in by using the ibmcloud ob monitoring agent discover [command](https://cloud.ibm.com/docs/containers?topic=containers-observability_climonitoring_agent_discover).

When you delete the monitoring configuration, the components that are deleted depend on how you created the monitoring configuration. For monitoring configurations that were created with the ibmcloud ob monitoring config create command, the daemon set for the Monitoring agent, the ConfigMap, and secret are removed from your cluster, and metrics are no longer sent to your IBM Cloud Monitoring service instance. Monitoring configurations that you manually created and made visible to the plug-in by using the ibmcloud ob monitoring agent discover command, only the ConfigMap is removed. Your daemon set, secret, and the Monitoring agent are still deployed to your cluster and you must manually remove them. Because the ConfigMap is removed, metrics are no longer sent to your IBM Cloud Monitoring service instance. Independent of how you created the configuration, existing metrics are still available in IBM Cloud Monitoring until your selected retention period ends.

ibmcloud ob monitoring config delete --cluster CLUSTER --instance MONITORING_INSTANCE

Minimum required permissions:
If you find that a domain-specific term is being corrected that shouldn't be, you can prevent the correction from happening by adding the term or phrase to your training data. For more details, see [Autocorrection rules](https://cloud.ibm.com/docs/assistant-data?topic=assistant-data-dialog-runtime-spell-checkdialog-runtime-spell-check-rules).

To turn autocorrection on or off, complete the following steps:



1. Click the Skills icon ![Skills menu icon](https://cloud.ibm.com/docs-content/v1/content/a2b18c153837bce00a5b4de496e4b4ca64bbf56e/assistant-data/images/nav-skills-icon.png), and then open your skill.
2. From the Skills menu, click Options, and then click Autocorrection.
3. Click the toggle to enable or disable the feature.







 Testing autocorrection 



1. From the Try it out pane, submit an utterance that includes some misspelled words.

If words in your input are misspelled, they are corrected automatically, and an ![auto-correct](https://cloud.ibm.com/docs-content/v1/content/a2b18c153837bce00a5b4de496e4b4ca64bbf56e/assistant-data/images/auto-correct.png) icon is displayed. The corrected utterance is underlined.
2. Hover over the underlined utterance to see the original wording.



If there are misspelled terms that you expected your assistant to correct, but it did not, then review the rules that your assistant uses to decide whether to correct a word to see if the word falls into the category of words that your assistant intentionally does not change.





 Autocorrection rules 

To avoid overcorrection, your assistant does not correct the spelling of the following types of input:



* Capitalized words
* Emojis
* Location entities, such as states and street addresses
* Check whether user list visibility restrictions are configured in IAM settings for the account owner
* Check whether IAM roles are used to create IAM policies for IBM resources
* Check whether IAM users are attached to at least one access group
* Check whether Cloud Object Storage public access is disabled in IAM settings (not applicable to ACLs managed using S3 APIs)







 NIST supplemental guidance 

Organizations employ least privilege for specific duties and information systems. The principle of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions/business functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary, to achieve least privilege. Organizations also apply least privilege to the development, implementation, and operation of organizational information systems.