vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Next, click Add rule to create the new expiration rule. You can add up to five rules during bucket creation, and extra rules can be added later.

For an existing bucket, select Configuration from the navigation menu and click Add rule under the Expiration rule section.





 Using the API and SDKs 

You can programmatically manage expiration rules by using the REST API or the IBM COS SDKs. Select the format for the examples by selecting a category in the context switcher.



 Add an expiration rule to a bucket’s lifecycle configuration 

REST API reference

This implementation of the PUT operation uses the lifecycle query parameter to set lifecycle settings for the bucket. This operation allows for a single lifecycle policy definition for a bucket. The policy is defined as a set of rules consisting of the following parameters: ID, Status, Filter, and Expiration.

Cloud IAM users must have the Writer role to add a lifecycle policy from a bucket.

Classic Infrastructure Users must have Owner permissions on the bucket to add a lifecycle policy from a bucket.



 Header Type Description 

 Content-MD5 String Required: The base64 encoded 128-bit MD5 hash of the payload, which is used as an integrity check to ensure that the payload wasn't altered in transit. 



The body of the request must contain an XML block with the following schema:



 Element Type Children Ancestor Constraint 

 LifecycleConfiguration Container Rule None Limit 1. 
 Rule Container ID, Status, Filter, Expiration LifecycleConfiguration Limit 1000. 
 ID String None Rule Must consist of (a-z,A-Z0-9) and the following symbols:!_.*'()- 
 Filter String Prefix Rule Must contain a Prefix element 
 Prefix String None Filter The rule applies to any objects with keys that match this prefix. 
 Expiration Container Days or Date Rule Limit 1. 
 Days Non-negative integer None Expiration Must be a value greater than 0. 
 Date Date None Expiration Must be in ISO 8601 Format. 
 NoncurrentVersionExpiration Date NoncurrentDays Rule Limit 1. 
 NoncurrentDays Non-negative integer None NoncurrentVersionExpiration Must be a value greater than 0.
Open a browser and log into your [IBM Cloud® account](https://cloud.ibm.com/).
2. From your IBM Cloud dashboard, select the Discovery instance you previously created.
3. In the Automate the upload of content to the Discovery service section, click the appropriate link to download the Data Crawler for Linux in DEB, RPM, and ZIP formats.
4. Verify that you are running Java Runtime Environment version 8 or higher. Run the command java -version, and look for 1.8. If you are running something earlier than 1.8, you need to upgrade Java by installing the Java Developer Kit (JDK) 8 from your package management system, from the [IBM JDK](https://www.ibm.com/support/pages/java-sdk) website, or from the [Oracle website](https://www.oracle.com/java/technologies/downloads/).

Your JAVA_HOME environment variable must be set correctly, or not be set at all, to run the Crawler.
5. As an administrator, use the appropriate commands to install the archive file that you downloaded:



* On systems such as Red Hat and CentOS that use rpm packages, use a command such as the following: rpm -i /full/path/to/rpm/package/rpm-file-name
* On systems such as Ubuntu and Debian that use deb packages, use a command such as the following: dpkg -i /full/path/to/deb/package/deb-file-name
* The Crawler scripts are installed into {installation_directory}/bin; for example, /opt/ibm/crawler/bin. Ensure that {installation_directory}/bin is in your PATH environment variable for the Crawler commands to work correctly.



Crawler scripts are also installed to /usr/local/bin, so this can be added to your PATH environment variable as well.
6. Create your working directory by copying the contents of the {installation_directory}/share/examples/config directory to a working directory on your system, for example /home/config.

Do not modify the provided configuration example files directly.
sda 8:0 0 1.8T 0 disk
sr0 11:0 1 1.1G 0 rom. /run/media/iso

From this output, choose to install on the sda disk.
3. Run the following install command to start the ignition file. Replace <diskName> with the full path of the disk that you retrieved from lsblk and replace <filename> with the name of the file you downloaded from IBM Cloud Object Storage.

sudo coreos-installer install <diskName> --ignition-file <filename>

The following example shows the command to install on/dev/sda with an ignition file called ./ignition.ign.

sudo coreos-installer install /dev/sda --ignition-file ./ignition.ign

The installation process can take an hour or two to complete.
4. After the installation completes, unplug your RHCOS ISO file and reboot from your hard disk.



1. Enter exit to access BIOS log in.
2. Enter your Softlayer password at BIOS prompt.
3. Select Boot.
4. Select to boot from hard drive.
5. Click Save and Exit.
6. Click Save Changes and Reset.



5. Check your Satellite location to confirm that your bare metal server is attached.



Congratulations! Your Bare Metal Server is now attached to your location.





 Step 5: Assigning a Bare Metal Server host to your Red Hat OpenShift cluster 

After your Bare Metal Server is attached to your location, you can assign it to a Red Hat OpenShift cluster worker pool.



1. Find the hosts to add to your Red Hat OpenShift cluster worker pool.

ibmcloud sat hosts --location <locationID>
2. Assign the Bare Metal Server to the Red Hat OpenShift cluster worker pool

ibmcloud sat host assign --location <locationID> --cluster <clusterID> --host <hostID> --worker-pool default --zone <zone>



Repeat this tutorial to attach more Bare Metal Servers to your location and cluster.
Click the IBM Cloud for VMware Solutions instance under Deployed Instances.
3. From the Summary page, collect the vCenter and Active Directory information.
4. Click Infrastructure and select the cluster.
5. Under Network Interfaces, collect the Public and Private VLANs.







 Downloading and installing govc 

The govc command is used to upload the OVF and ISO to a datastore from the jump-server or remote device.

If your jump-host or remote device uses Windows®, then download from [Downloads](https://github.com/vmware/govmomi/releases).

If your remote device uses macOS, then use the following command: brew install govmomi/tap/govc

If you need to install Homebrew, see [Installing Homebrew on a Mac](https://treehouse.github.io/installation-guides/mac/homebrew).

If your jump-host or remote device uses Linux, complete the following steps:



1. Download govc and make it executable. Run curl -L https://github.com/vmware/govmomi/releases/download/v0.20.0/govc_linux_amd64.gz | gunzip > /usr/local/bin/govc.
2. Run chmod +x /usr/local/bin/govc.







 Validating Distributed PortGroup and Datastore names 

vCenter Server deployment uses deployment-specific naming for the datastores and distributed PortGroups. This runbook uses 'vsanDatastore', 'SDDC-DPortGroup-Mgmt' and 'SDDC-DPortGroup-External'. You need to use your vCenter Server deployment-specific network and storage names in your deployment configurations. For example, you might have datastore such as 'workload_share_YgkI8' (in case IBM Cloud File Storage is used for the datastore) or your private portgoup can be like 'fra04test-fra04-test01-dpg-mgmt'.
You can view all of the smart contracts that are instantiated on a channel by clicking the channel icon in the left navigation, selecting a channel from the table, and then clicking the Channel details tab.

Be aware that if you use a free Kubernetes cluster on IBM Cloud, instantiation can take significantly longer than in a paid cluster.Depending on the number of peers you have deployed in your cluster, the type of smart contract you are instantiating, and the platform you are running on, instantiation can take several minutes. If the instantiation fails with a timeout error, wait 5 minutes and then retry it again.

The combination of installation and instantiation is a powerful feature because it allows for a peer to use a single smart contract across many channels. Peers may want to join multiple channels that use the same smart contract, but with different sets of network members able to access the data. A peer can install the smart contract once and use it on any channel where it has been instantiated. This lightweight approach saves compute and storage space, and helps you scale your network.





 Step four: Send transactions by using your client applications 

After a smart contract has been instantiated on a channel, you can use a client application to transact with other members of your network. Applications can invoke the business logic that is contained in smart contracts to create, transfer, or update assets on the blockchain ledger.



 Connect with SDK 

After you create an organization MSP definition, you can download a connection profile that can be used by a client application to connect to your network via one or more gateway peers. The gateway peers are the peers that are specified in the connection profile, and they are used to perform service discovery to find all of the endorsing peers in the network that will endorse transactions.

Click the Organization MSP tile for the organization that your client application interacts with. Click Create connection profile to open a side panel where you can build and download your connection profile.

![Create connection profile panel](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/create-connx-profile.png)
10.17.139.46 e2e1270-priv

Add the last two lines on e2e1270, too.





 Installing NFS software 



1. Install NFS software nfs-utilson both servers.



[root@sdb192 ] yum install nfs-utils

Make sure you start and register the rpcbind and NFS service on the database server.

[root@sdb192 ] service rpcbind start
[root@sdb192 ] chkconfig nfs on
[root@sdb192 ] service nfs start





 Using NFS to export 



1. Use NFS to export /sapmnt and /usr/sap/trans from the database server to the application server by adding the required entry to /etc/exports of the database server.



/sapmnt/C10		10.17.139.46(rw,no_root_squash,sync,no_subtree_check)
/usr/sap/trans	10.17.139.46(rw,no_root_squash,sync,no_subtree_check)

The sample value C10 needs to be replaced with the SAP System ID for your SAP system. You must create the directory before you export it. Run the following commands from the command line of the database server:

[root@sdb192 ] mkdir /sapmnt/C10
[root@sdb192 ] mkdir -p /usr/sap/trans
[root@sdb192 ] exportfs -a





 Mounting the NFS share 



1. Mount the NFS share on the application server by adding the following entry to its /etc/fstab and mount it from the command line.



sdb192-priv:/sapmnt/C10 /sapmnt/C10 nfs defaults 0 0
sdb192-priv:/usr/sap/trans /usr/sap/trans nfs defaults 0 0



2. Create the target directories on the application server and mount them.
[Schematics SDKs](https://cloud.ibm.com/docs/schematics?topic=schematics-schematics-sdksschematics-sdks)





 Service locations and endpoints 

[Service locations and endpoints](https://cloud.ibm.com/docs/schematics?topic=schematics-locationslocations)



* [Where can I create and run Schematics Workspaces?](https://cloud.ibm.com/docs/schematics?topic=schematics-locationswhere-wks-created)
* [Where do my Schematics Actions run?](https://cloud.ibm.com/docs/schematics?topic=schematics-locationswhere-do-locations-run)
* [Where is my Schematics and template data stored?](https://cloud.ibm.com/docs/schematics?topic=schematics-locationswhere-is-data-stored)
* [Where are my IBM Cloud resources provisioned?](https://cloud.ibm.com/docs/schematics?topic=schematics-locationswhere-are-resources-provisioned)







 Service limitations 

[Service limitations](https://cloud.ibm.com/docs/schematics?topic=schematics-schematics-limitationsschematics-limitations)



* [Differences to native Terraform](https://cloud.ibm.com/docs/schematics?topic=schematics-schematics-limitationsterraform-vs-schematics)



* [Do I need to provide an IBM Cloud API key in the provider block?](https://cloud.ibm.com/docs/schematics?topic=schematics-schematics-limitationsprovider-block)
* [Can I use my local terraform.tfvars file?](https://cloud.ibm.com/docs/schematics?topic=schematics-schematics-limitationsterraformtfvars)
Node

If your smart contract was written in Node, then you might need to update it. By default, a Fabric v1.4 peer will create a Node v8 runtime, and a Fabric v2.x peer creates a Node v12 runtime. In order for a smart contract to work with Node v12 runtime, the fabric-contract-api and fabric-shim node modules must be at v1.4.5 or greater. If you are using a smart contract that was originally written to work with Fabric 1.4, update the Node modules by running the following command before deploying the smart contract on a Fabric v2.x peer. See [Support and compatibility for fabric-chaincode-node](https://github.com/hyperledger/fabric-chaincode-node/blob/main/COMPATIBILITY.md) for more information.

npm install --save fabric-contract-api@latest-1.4 fabric-shim@latest-1.4

Go

Because Fabric v2.x peers do not have a "shim" (the external dependencies that allowed smart contracts to run on earlier versions of Fabric), you need to vendor the shim and then repackage any smart contracts written in Golang (Go) that use the [Go SDK](https://github.com/hyperledger/fabric-sdk-go). "Vendoring the shim" effectively means that you are copying the dependencies into your project. Without this vendoring and repackaging, the Go smart contract cannot run on a peer using a Fabric 2.x image. If you are using the [IBM Developer Tools](https://cloud.ibm.com/docs/blockchain?topic=blockchain-develop-vscode) to develop and package your smart contract, the tooling performs the vendoring for you. This process is not required for smart contracts that are written in Java or Node.js, nor for Go smart contracts that use the [Go contract-api](https://github.com/hyperledger/fabric-contract-api-go).

Java
The build.gradle file for the smart contract must be updated:



1.
RX bytes:19137850 (18.2 MiB) TX bytes:3426015 (3.2 MiB)

[root@sdb192 ] ifconfig bond1
bond1	 Link encap:Ethernet HWaddr 0C:C4:7A:66:2D:A9
inet addr:208.43.211.118 Bcast:208.43.211.127 Mask:255.255.255.224
inet6 addr: fe80::ec4:7aff:fe66:2da9/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:289610 errors:0 dropped:0 overruns:0 frame:0
TX packets:109371 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:31216160 (29.7 MiB) TX bytes:18591947 (17.7 MiB)

In the three-tier example, 10.17.139.35 is the private IP address of the database server; it is from one of the IP address ranges from RFC 1597. You can determine the IP address of the application server, too, and add both IP addresses to both servers’ /etc/hosts.

[root@sdb192 ] cat /etc/hosts

127.0.0.1 localhost.localdomain localhost
208.43.211.118 e2e2690.saptest.com e2e2690

10.17.139.35 sdb192-priv
10.17.139.46 e2e1270-priv

Add the last two lines on e2e1270, too.





 Installing NFS software 



1. Install NFS software nfs-utilson both servers.



[root@sdb192 ] yum install nfs-utils

Make sure you start and register the rpcbind and NFS service on the database server.

[root@sdb192 ] service rpcbind start
* The alternate Liberty runtime GA version [19.0.0.1](https://openliberty.io/blog/2019/02/01/open-liberty-19001.html) was added.
* The monthly Liberty beta release has been removed.
* The IBM JRE version was updated to 8 SR5 FP27.
* The MQ client was updated to the 9.1.0.0 release.
* The auto-scaling agent was updated.







 23 January 2019 

Updated Node.js buildpack v3.25.1
: The SDK for Node.js buildpack v3.25.1 provides IBM SDK for Node.js versions 4.8.5, 4.8.7 and Node.js community versions 6.14.4, 6.16.0, 8.11.4, 8.15.0, 10.10.0 and 10.15.0. The default is latest 6.x, so it is currently 6.16.0. The versions 6.15.0, 8.14.0 and 10.14.0 that were included in the last buildpack had a regression. The regressions has been fixed in 6.16.0, 8.15.0 and 10.15.0 which are now included instead.





 7 January 2019 

Updated Node.js buildpack v3.25
: The SDK for Node.js buildpack v3.25 provides IBM SDK for Node.js versions 4.8.5, 4.8.7 and Node.js community versions 6.14.4, 6.15.0, 8.11.4, 8.14.0, 10.10.0 and 10.14.0. The default is latest 6.x, so it is currently 6.15.0. The buildpack also fixes a minor bug in the Dynatrace hook.





 14 December 2018 

Updated Liberty buildpack v3.27-20181130-1702
: The buildpack now includes Java Platform, Enterprise Edition 8.0. Java EE 8 no longer needs to be installed when an app is pushed.
If there are any issues found, while the --current-status was passed as success, the command closes those issues.

If --read-only is set, the command does not create new issues or amend existing ones. Results are processed, and existing issues are collected for results. The output contains the issue URL list that are supposed to be tracked in issues if the read-only mode is not activated.

Usage:

cocoa incident process-legacy <options>

Options:

--type (Required) Tool type
--subject (Required) Subject of scans (repo, or image name)
--drilldown-url (Required) URL to the point where the incident was found (can be a pipeline run, a commit hash or an image URL with digest)
--set-grace-period Should the created incidents have Grace period set
--git-provider Git service provider [github] Default is "github"
--org The incident issue repository org
--repo The incident issue repository name
--label Label(s) to add to the incident issue (optional) e.g: --label=foo --label=bar
--assignee (Optional) Assignee(s) for the incident issue (github username) e.g: --assignee=jane-doe --assignee=john-smith
--git-token-path (Optional) Github Token's path
--git-api-url (Optional) Github API url
--close-resolved-issues (Optional) Checking and closing resolved issues
--pipeline-run-url (Optional) The url to the pipeline run running the CLI command
--is-prod (Optional) Flag for whether or not the command was run in production environment. Default is false.
--read-only (Optional) Process result file in read-only mode (return found and existing issues, do not create new ones, set processed status to failure or success). Default is false
--custom-exempt-label (Optional) Defines the custom label with which the incident has been marked as exempted
For nonincident issues that are found during a CI run, a combination of the evidence_type and the app repo branch is used to construct the issue title so that a unit test failure found on branch master is dealt with separately from a unit test failure on branch dev. A similar combination is used for such issues that are found from the CC pipeline. Issues coming from CD pipeline have a different grouping criteria, where the combination of the evidence type id, target environment, and the pipeline namespace is used to construct the title of the issue. This different grouping criteria ensure that the issues found on CI and CC are not interfered by the CD run for similar tests like an acceptance test. The different criteria also ensure that issues found for a target environment prod is dealt separately from an issue that is found on target environment staging.

The [cocoa incident process-legacy](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-cliincident-process-legacy) command has two modes of action based on whether the current-status of the run was a success or failure:



* If the current-status is failure, the command looks for an open issue of a similar title coming from the same tool against the same subject. If the command finds such an issue, it updates the issue with an additional comment. However, if an existing issue matching the title-tool-subject is not found, the command creates an incident, attaches a default severity of High, however no due date is set.
* If the current-status is success, the command looks for an open issue that matches the title-tool-subject combination, and if such an issue is found, it is closed automatically. If such an issue is not found, then the issue is a no-op.



Currently, nonincident issue handling handles the following scenarios:



* Failing unit test
* Failing acceptance test
* Failing image signing
* Failing branch protection check
If the GHE_TOKENGH_URL and --git-token-path--git-api-url both pairs are both provided, --git-token-path and --git-api-url take precedence.

Return values:



* The command lists incident issue URLs found or created if the --current-status was passed in as failure. The comand also closes the incident issue URLs matching the same incident-tool-subject combination if the --current-status was passed in as failure.
* In --read-only mode the command lists details of found incidents if no issue is found for that incident.
* If there are no issues found, or all found issues has exempt label set, the command exits with zero status.
* If any of the issues found have no exempt label set, the command exits with a non-zero status.
* In --read-only mode if any new incident is found that has no issue, the command exits with a non-zero status.



Running the command:

$ cocoa incident process-legacy --type jest --subject us.icr.io/service-image --drilldown-url us.icr.io/service-image@sha256:digest --incident-id com.ibm.unit_tests_master --current-status success --close-resolved-issues







 cocoa locker commands 

The evidence locker is a Git repository on GitHub (Enterprise). The Git provider can be specified by using --git-provider (github by default). For both providers, authentication is required, for GitHub set the GHE_TOKEN environment variable or --git-token-path field. For GitHub, you must also specify where the GitHub instance is located, by using the GH_URL environment variable or --git-api-url field, but it defaults to https://github.ibm.com.

The name of the evidence locker repository can be set by using --org and --repo, or by using the EVIDENCE_LOCKER_REPO_OWNER and EVIDENCE_LOCKER_REPO_NAME environment variables.
See [DefaultQueryHandlerStrategies](https://hyperledger.github.io/fabric-sdk-node/release-2.2/module-fabric-network.html.DefaultQueryHandlerStrategies__anchor) in the Node SDK documentation for more information.







 Step five: Invoke the smart contract 

After you configure the gateway to connect to the network managed by your console, we will edit the portion of the issue.js file that connects to the commercial paper smart contract. You need to provide the gateway the contract name and the channel where the smart contract was deployed.

Edit the following line, and replace mychannel with your channel name.

const network = await gateway.getNetwork('mychannel');

Following a line of code that prints a message to your console, you can find a line that provides the gateway the smart contract name. Edit the following line to change the name papercontract to the name of the contract you installed.

const contract = await network.getContract('papercontract', 'org.papernet.commercialpaper');

The gateway now has all the information that it needs to submit a transaction. The following line invokes the issue function in the commercial paper contract, with the arguments defining the new commercial paper asset.

const issueResponse = await contract.submitTransaction('issue', 'MagnetoCorp', '00001', '2020-05-31', '2020-11-30', '5000000');

After it submits the transaction using the gateway, the issue.js file disconnects the gateway connection.

gateway.disconnect();

This command closes the gRPC connections opened by your gateway. Closing connections save network resources and improve performance.

After completing the edits from this step and Step four, save issue.js and close it. Submit the transaction that creates the new commercial paper by using the following command:

node issue.js

If the transaction is successful, you can see the following output in your terminal:

Transaction complete.
Disconnect from Fabric gateway.
Issue program complete.