vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Either the application consumes the variables, or a script, that runs before the actual application, configures the application. Before you can set environment variables, the registration definition must allow them. You can provide environment variables by way of the e or --environment option (cannot contain “,”). The environment variables are written to /.runqenv.

You can allow environment variables by name to envs_whitelist array within the registration definition.

The following variables cannot be set: “RUNQ_ROOTDISK”, “RUNQ_RUNQENV”, “RUNQ_SYSTEMD”, “IMAGE_TAG”, “REGION”, “PHASE”, “LPAR_NAME”, “CPC”, “RUNQ_CPU”, “RUNQ_MEM”, “POD”.

Variable names can have up to 64 characters and can consist of numbers, chars, and underscore. Variable values can have up to 4096 characters and can consist of base64 character set characters (uppercase letters, lowercase letters, and +, /).

An example with one environment variable:

ibmcloud hpvs instance-create myServerName lite-s <location> --rd-path “C:MyRegistrationDefinitionsregistration.json.asc ” -i latest -e name=value

An Example with multiple environment variables:

ibmcloud hpvs instance-create myServerName lite-s <location> --rd-path “C:MyRegistrationDefinitionsregistration.json.asc ” -i latest -e name1=value1 -e name2=value2

The initial user has the corresponding environment variable set within the container.
Enter the path to your payload file. For a sample payload file, see [Using the payload file](https://cloud.ibm.com/docs/schematics?topic=schematics-schematics-cli-referencerq-create-payload). Then, press the return key.
4. Review the details of the resource query that was created for you.









 ibmcloud schematics resource query delete 

Delete the resource resource query definition by using the resource query ID from the IBM Cloud Schematics service. Note you can delete the location and region, resource group from where your inventory was created. Also, make sure your IP addresses are in the [allowlist](https://cloud.ibm.com/docs/schematics?topic=schematics-allowed-ipaddresses).

Syntax

ibmcloud schematics resource-query delete --id ID [--force] [--no-prompt]

Command options



Schematics resource query delete flags

 Flag Required / Optional Description 

 --id or -i Required The ID of a resource query that you want to delete. 
 --force or -f Optional Force the deletion without user confirmation. 
 --no-prompt Optional Set this flag to run the command without user prompts. 



Example

ibmcloud schematics resource-query delete --id us-east.INVENTORY.inventoryid12342





 ibmcloud schematics resource query get 

Retrieve the information of an existing IBM Cloud Schematics resource query by using a resource query ID.

Syntax

ibmcloud schematics resource-query get --id ID [--profile PROFILE] [--output OUTPUT] [--no-prompt]

Command options



Schematics resource query get flags

 Flag Required / Optional Description 

 --id or -i Required The ID of the resource query that you want to retrieve. 
 --profile or -p Optional The depth of information that you want to retrieve. Supported values are detailed and summary. The default value is summary. 
 --output or -o Optional Specify the output format. Only JSON format is supported.
ln -s /data/.ssh/authorized_keys /home/root/.ssh/authorized_keys
8. Important: Do not disconnect unless you verified that you can connect with the new setup.
9. Open a new terminal and verify that you can connect with your private key (close the new terminal afterward and continue in the old one).
10. Optionally delete /home/root/.ssh/authorized_keys.backup.









 Updating your own server 

If you use a self-provided server, you generally don't have access to the virtual server itself (thru SSH). When you update the server you can update the installed packages. The update resets everything to the state of a new server except for the content within /data. Before you update your server, copy any data that you want to be available after the update to /data. To update a self-provided server, run the following command and include the image tag (-i mytag).

ibmcloud hpvs instance-update (NAME | CRN) -i mytag

You can also update the registration definition:

ibmcloud hpvs instance-update (NAME | CRN) -i mytag --rd-path my-rd

An update the registration definition does not allow you to update repository_name.

For information about the update command options, see [hpvs-update-instance](https://cloud.ibm.com/docs/hpvs-cli-plugindetails_iu).



 Setting environment variables 

Use this description for configurations that are not considered credentials or personal data only.

When you update an image, you must provide all environment variables (including the variables that you set previously).

In this description "environment variables" are not set as environment variables, instead they provided within /.runqenv. For information about environment variables, see [Configuring your server](https://cloud.ibm.com/docs/hp-virtual-servers?topic=hp-virtual-servers-byoibyoi_config).

Example with one environment variable:
If, after creating the proposal you realize that changes are required to the definition, you need to create a new proposal. However, you are permitted to update the package on the proposal.
9. When you are satisfied with the proposal, click Propose to install the smart contract on the selected peers and send an approval notification to the channel members. When the proposal is successful, it is visible in the Channels tab under Smart contract definitions with a status of Proposed on the tile. It is also visible to members of the channel lifecycle endorsement policy under the console Notifications (bell) icon.



If other organizations will run the package on their peers, you need to share the name of the package with them out of band, so they can select it and install it on their peers when they approve the smart contract definition. The smart contract package name is included on the proposal Summary panel.





 Step three: Approve smart contract definition 

The decentralized governance of the smart contract lifecycle requires that the specified number of organizations in the channel lifecycle endorsement policy approve the smart contract definition before it can be committed to a channel. All organizations listed in the channel lifecycle endorsement policy receive a notification when a proposal definition is submitted to the channel. They can access the proposal from the Notification (bell) icon in the console or simply open the Channels tab where they can find the smart contract definition tile in the Proposed state. Clicking the tile or the notification opens the same approval panel.

Zoom

![smart contract approval](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/lifecycle-approve.png)

Figure 2. Smart contract approval panel

Proposal originators can view the proposal using the same mechanisms. However, by virtue of submitting the proposal, their approval is automatic.

Channel members approve the smart contract definition, not the smart contract package, which contains the business logic that runs on a peer. A smart contract proposal contains the following information:



* Smart contract definition name
* Version
* Smart contract endorsement policy
* Private data collection JSON (optional)
Since you are proposing the smart contract, it must be installed on at least one peer.
6. On the Smart contract endorsement policy panel, you can designate how many organizations need to endorse a smart contract transaction before it can be committed to the ledger. The default smart contract endorsement policy is inherited from the application endorsement policy of the channel, but can be overridden here by selecting specific organizations and the required number, or by pasting in your own policy JSON. Remember, this smart contract endorsement policy becomes part of the proposal that must be agreed to by the other channel members before the smart contract can be committed to the channel. The endorsement policy must follow the format that is specified in the Fabric documentation [endorsement policy syntax](https://hyperledger-fabric.readthedocs.io/en/release-2.2/endorsement-policies.htmlendorsement-policy-syntax).
7. If your smart contract includes Fabric private data collections, you need to upload the associated collection configuration JSON file on the Additional private data collection panel. Otherwise, you can skip this step. For more information, see [private data](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-smart-contracts-v2ibp-console-smart-contracts-v2-private-data).
8. Your smart contract proposal definition is listed on the Summary panel. Everything that you selected on the previous panels become part of the proposal definition. It also includes the list of organization members that will receive the proposal notification. Once a proposal is created, the definition cannot be modified. Proposal definitions cannot be modified after they are created. If, after creating the proposal you realize that changes are required to the definition, you need to create a new proposal. However, you are permitted to update the package on the proposal.
9. When you are satisfied with the proposal, click Propose to install the smart contract on the selected peers and send an approval notification to the channel members. When the proposal is successful, it is visible in the Channels tab under Smart contract definitions with a status of Proposed on the tile.
* [Editing dimensions](https://www.ibm.com/docs/planning-analytics/2.0.0?topic=mipaw-dimensions)
* [Managing hierarchies](https://www.ibm.com/docs/planning-analytics/2.0.0?topic=d-hierarchies)
* [Creating attributes](https://www.ibm.com/docs/planning-analytics/2.0.0?topic=ma-create-member-attributes)
* [Managing security](https://www.ibm.com/docs/planning-analytics/2.0.0?topic=mipaw-object-security)



To understand why you should use the Planning Analytics with Watson tools to model your data, consider the following benefits.



 Query performance 

You can create more manageable dimensions by creating more than one hierarchy in a dimension.

For example, you can create a single time dimension. A year dimension must be the same for every year to compare data between two years. This approach gives you the ability to create a new year easily, and query performance is faster because you have only one dimension in the cube.

You can create a time dimension with multiple hierarchies that represent years and months to do yearly comparisons per month.

If you create two dimensions, one for year and one for months, you gain the ability to split the years and months across two axes and you can compare data between years.





 RAM savings 

If you model with dimensions, you can put the dimensions on the cube axes. Dimensions describe the data, and you can query against them. But dimensions cost RAM memory. Therefore, you can use hierarchies to model your data instead of dimensions.

If you model with attributes, it keeps your cube structure simple but it describes the dimension members only, not the data itself. You can't use attributes to query data. Creating a dimension for attributes that you want to query on creates complexity.

You can use hierarchies to model your data and get the same granularity that attributes give you with the benefit of being able to query on the data. You can query directly with hierarchies on the axes or with set filtering.
* Approve the definition but select an existing package from another peer in their organization. When an organization prefers to run their own version of the smart contract package on the channel, provided that the read/write set logic is the same, and that package is already installed on another peer in their organization, they can select the existing smart contract package during the approval.
* If a member wants to reject the smart contract proposal, they should simply abstain from approving the definition. Instead, they can create a new smart contract proposal with the definition they prefer and either upload a new smart contract package or use the existing one from the original proposal. Note: The new proposal must use a new smart contract definition name.





After you approve a smart contract proposal and while it is waiting for approvals from other members, you can still update the package for your organization, or install it on additional peers if needed. Simply, reopen the proposal tile on the Channels tab and click Update package details next to your organization to upload a new package. If you do upload a new package, when you create the updated package, we recommend incrementing the third digit of the version on the package name to help you differentiate the packages. For example, if the existing package is named MySmartContract@1.0.0.tar.gz, the new package is named MySmartContract@1.0.1.tar.gz.

The Begin approval process or Update package details buttons are not visible on the panel when the console user does not have an identity in their wallet for a listed organization.





 Step four: Commit smart contract definition 

If you are familiar with the process that Fabric v1.4 used for deploying a smart contract, the commit step is similar to instantiation, which makes the smart contract active on the channel so that peers can begin endorsing transactions.

When enough organizations have approved the smart contract definition according to the channel lifecycle endorsement policy, the status of the definition on the tile changes to Ready to commit.

Zoom

!
This type of pipeline provides a dashboard that you can use to view the output of Tekton pipeline runs on a defined Kubernetes cluster, with support for configuring the pipeline definitions repos, the pipeline triggers, where the pipeline runs, and simple secrets.
6. If you plan to use your pipeline to deploy a user interface, select the Show apps in the View app menu checkbox. All of the apps that your pipeline creates are shown in the View App list on the toolchain's Overview page.
7. Click Create Integration to add the Delivery Pipeline to your toolchain.





 Configuring a Delivery Pipeline for Tekton by using the console 



1. From your toolchain's Overview page, on the Delivery pipelines card, click the Delivery Pipeline to open the Tekton Delivery Pipeline dashboard.
2. In the Definitions section, complete the following tasks:

a. Specify the Git repo and URL that contains the Tekton pipeline definition and related artifacts. If your repo is not available, return to the toolchain Overview page and add your repo.

b. Select the branch within your Git repo that you want to use, or type a tag.

c. Specify the path to your pipeline definition within the Git repo. You can reference a specific definition within the same repo. You can also add multiple definition repos, if they are integrated with the toolchain.

d. Save your changes.

The pipeline definition is updated automatically.

The computed pipeline definition size limit is 1 MB. If you encounter errors when you save or run your pipeline, you might need to reduce the size of your pipeline definition, or split it into multiple pipelines.
3. In the Worker section, select the IBM Managed shared worker or the private worker that you want to use to run your Tekton pipeline. For more information about private workers, see [Working with Delivery Pipeline Private Workers](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-private-workers).

The private worker must be defined in the same toolchain as your Tekton pipeline.
4.
Smart contract approval panel

Proposal originators can view the proposal using the same mechanisms. However, by virtue of submitting the proposal, their approval is automatic.

Channel members approve the smart contract definition, not the smart contract package, which contains the business logic that runs on a peer. A smart contract proposal contains the following information:



* Smart contract definition name
* Version
* Smart contract endorsement policy
* Private data collection JSON (optional)



The members, including the originator, cannot change the definition. They can simply approve it or choose not to approve it. If the required approvals based on the channel lifecycle endorsement policy are not met, the smart contract cannot be committed to the channel.



1. Click Begin approval process to get started.
2. Before you can approve a smart proposal, you are required to select your organization and the associated peer admin identity that you want to use to approve or endorse the proposal.
3. Channel members can choose among these options:



* Approve the definition, but do not install the package on any of their peers. Useful when the smart contract can run on the channel but is not required for your organization.
* Approve the definition and install the package on one or more peers in their organization. The proposal originator needs to share the package file out of band with the channel members so they can upload it and install it on their peers. Smart contract packages cannot be shared from the console.
* Approve the definition but upload their own package and install it on one or more peers in their organization. When an organization prefers to run their own version of the smart contract package on the channel (provided the read/write set logic is the same), they can upload their own smart contract package file during the approval.
* Approve the definition but select an existing package from another peer in their organization. When an organization prefers to run their own version of the smart contract package on the channel, provided that the read/write set logic is the same, and that package is already installed on another peer in their organization, they can select the existing smart contract package during the approval.
* If a member wants to reject the smart contract proposal, they should simply abstain from approving the definition.
Prerequisite: Before you can take advantage of Node OU support, ensure that your CAs are at Fabric v1.4.3 or higher. Open the CA tile to view the Fabric version. If the CA is not at v1.4.3 or higher, you should [upgrade](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-manage-consoleibp-console-manage-patch) it now.

Zoom

![View CA Fabric version](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/ca-fabric-version.png)

Figure 2. View CA Fabric version

Enabling Node OU support for an MSP definition is a two-part process. First, you have to update the MSP definition itself, then you have to update the same MSP definition on the channel.



 Part one: Enable Node OU support for an MSP definition 



1. Open the Organizations tab to view the Node OU status for each MSP:

Zoom

![View Node OU status on MSP tile](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/msp-nodeou.png)

Figure 3. View Node OU status on MSP tile
2. Click the Settings icon for the MSP. The checkbox to add Node OU is selected by default. You do not have to add a new JSON file, you can simply click Update MSP definition to enable Node OU support for the MSP.

Zoom

!
Navigate to the Channels tab, open the channel, and click Propose smart contract definition. This single action actually performs two tasks. It installs a smart contract on one or more of your peers and proposes the smart contract definition to the channel.
2. Because the console allows you to act as multiple organizations from a single console, you must first select the organization that is proposing this smart contract definition and the associated peer admin identity. A peer admin identity is required to install a smart contract. Not sure? Open the peer CA and verify that the identity associated with the peer has the type admin in the list of CA users.
3. On the next panel, browse to your smart contract package and click Add file. You can install a new package or browse to an existing package that was installed on another peer in your organization. Smart contract packages can also be installed on a peer node directly by using the Install smart contract button. If you used that option, instead of clicking Add file, click the Existing package tab and select the package that you installed on your peer.
4. On the Smart contract details panel you can specify a unique name and version to use for this smart contract definition. The console extracts these values from the package name itself but you can override them and specify any values that your organization prefers. Be careful how you name your proposal. If a proposal with the same name already exists on the channel, this proposal replaces it.
5. On the Install smart contract panel, you can install the smart contract on all your peers on the channel or just a subset. In a production network, for redundancy reasons, you should install the smart contract on at least two peers, or three when you want to maintain redundancy but still allow for one peer to go down for maintenance. Since you are proposing the smart contract, it must be installed on at least one peer.
6. On the Smart contract endorsement policy panel, you can designate how many organizations need to endorse a smart contract transaction before it can be committed to the ledger. The default smart contract endorsement policy is inherited from the application endorsement policy of the channel, but can be overridden here by selecting specific organizations and the required number, or by pasting in your own policy JSON.
The other two objects are empty and don't contain any data. It is important not to delete any of the objects if you want to use the result set for subsequent queries. By default, the object names include the job ID. For example, if you specify mydir/out or mydir/out/ as the target directory, the result objects are written under mydir/out/jobid=<job_id>. So, when a query is run multiple times, the result set is not overwritten. You can change this behavior with the [JOBPREFIX](https://cloud.ibm.com/docs/sql-query?topic=sql-query-sql-referencecosResultClause) option of the INTO clause.

You can use the result set from one query as input data for further SQL queries. If you want to specify a result of a single query execution as input in your SQL query, specify the first (<target>/jobid=<job_id>) or the third one (<target>/jobid=<job_id>/<part-number>). You can also use the [partitioning clause](https://cloud.ibm.com/docs/sql-query?topic=sql-query-sql-referencepartitionedClause) to split the result set into multiple objects. Either the entire result set or individual objects can then serve as input for further queries.

A query can even process the output of multiple previous query executions by omitting the jobid=<job_id> part in the object name. For example, you can run some setup queries writing to cos://us-geo/my-bucket/tempstore, where each query creates new objects inside that prefix with a distinct jobid=<job_id> name. You can then run an aggregate query over all of the setup results by using cos://us-geo/my-bucket/tempstore as a [composite input table](https://cloud.ibm.com/docs/sql-query?topic=sql-query-readingcompositeInput).