vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For more information, see [Getting set up to sell software](https://cloud.ibm.com/docs/sell?topic=sell-sw-getting-started).





 Creating a private catalog 

Private catalogs provide a way for you to manage access to products for users in your account.



1. Go to Manage > Catalogs in the IBM Cloud console, and click Create a catalog.
2. Enter a name and description of your catalog.
3. Select to exclude or include all products in the IBM Cloud catalog in your private catalog. For more information about how this affects visibility in the catalog, see [Managing catalog settings](https://cloud.ibm.com/docs/account?topic=account-filter-account&interface=ui).
4. Click Create.







 Importing software to your private catalog 

Complete the following steps to import software to your private catalog:



1. From the Private products page, click Add.
2. Select your deployment method.
3. Select whether you are adding your product from a private or public repository. Or, if you're onboarding an Operator from a Red Hat registry, select your Red Hat repository type: Certified, Marketplace, Community.

If you're adding your product from a private repository, you can provide a personal access token or you can use a secret. Instead of giving users a personal access token, you can give them access to a secret, add the token to a secret, and centrally manage all tokens and access the secret allows.



* If you're using a personal access token, select No to indicate that you aren't using a secret and provide your personal access token.
* If you're using a secret, select Yes and click Select from Secrets Manager. Select your service instance, secret group, and secret. If you don't see your secret, make sure you're using the correct secret group and service instance.



The message No service instance available might be displayed if you haven't created a secret or if you don't have the correct access to use secrets, even if you have service instances that are created.
4. Enter your source URL.
1. Log in to the IBM Cloud CLI. Enter your IBM Cloud credentials when prompted. If you have a federated account, include the --sso option.

ibmcloud login [--sso]
2. If the cluster is in a resource group other than default, target that resource group. To see the resource group that each cluster belongs to, run ibmcloud oc cluster ls. Note: You must have at least the [Viewer role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms) for the resource group.

ibmcloud target -g <resource_group_name>
3. Get the name of your cluster.

ibmcloud oc cluster ls
4. Retrieve the service endpoint URLs for your cluster.



* If only the Private Service Endpoint URL is populated, get this URL. Your authorized cluster users can access the master through this endpoint on the private network.
* If both the Public Service Endpoint URL and Private Service Endpoint URL are populated, get both URLs. Your authorized cluster users can access the master through the public endpoint on the public network or the private endpoint on the private network.



ibmcloud oc cluster get --cluster <cluster_name_or_ID>

Example output

...
Public Service Endpoint URL: https://c3.<region>.containers.cloud.ibm.com:30426
Private Service Endpoint URL: https://c3-private.<region>.containers.cloud.ibm.com:31140
...
5. Allow access to the service endpoint URLs and ports that you got in the previous step. If your allowlist is IP-based, you can see which IP addresses are opened when you allow access to the service endpoint URLs by reviewing [this table](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallmaster_ips).
6. Verify your connection.
When a user accesses your app subdomain, the client accesses one of these IPs at random, and the request is sent to that NLB.

You currently can't create subdomains for private NLBs.

Health check monitor
: Enable health checks on the NLB IP addresses behind a single subdomain to determine whether they are available or not. When you enable a monitor for your subdomain, the monitor health checks each NLB IP and keeps the DNS lookup results updated based on these health checks. For example, if your NLBs have IP addresses 1.1.1.1, 2.2.2.2, and 3.3.3.3, a normal operation DNS lookup of your subdomain returns all 3 IPs, 1 of which the client accesses at random. If the NLB with IP address 3.3.3.3 becomes unavailable for any reason, such as due to zone failure, then the health check for that IP fails, the monitor removes the failed IP from the subdomain, and the DNS lookup returns only the healthy 1.1.1.1 and 2.2.2.2 IPs.

You can see all subdomains that are registered for NLB IPs in your cluster by running the following command.

ibmcloud ks nlb-dns ls --cluster <cluster_name_or_id>

DNS microservice updates are asynchronous and might take several minutes to apply. Note that if you run an ibmcloud ks nlb-dns command and receive a 200 confirmation message, you might still have to wait for your changes to be implemented. To check the status of your subdomain, run ibmcloud ks nlb-dns ls and find the Status column in the output.



 Registering NLB IPs with a DNS subdomain 

Expose your app to the public internet by creating a subdomain for the network load balancer (NLB) IP address.

Before you begin:



* Review the following limitations.



* You can't create subdomains for private NLBs.
* You can register up to 128 subdomains.
When a user accesses your app subdomain, the client accesses one of these IPs at random, and the request is sent to that NLB.

You currently can't create subdomains for private NLBs.

Health check monitor
: Enable health checks on the NLB IP addresses behind a single subdomain to determine whether they are available or not. When you enable a monitor for your subdomain, the monitor health checks each NLB IP and keeps the DNS lookup results updated based on these health checks. For example, if your NLBs have IP addresses 1.1.1.1, 2.2.2.2, and 3.3.3.3, a normal operation DNS lookup of your subdomain returns all 3 IPs, 1 of which the client accesses at random. If the NLB with IP address 3.3.3.3 becomes unavailable for any reason, such as due to zone failure, then the health check for that IP fails, the monitor removes the failed IP from the subdomain, and the DNS lookup returns only the healthy 1.1.1.1 and 2.2.2.2 IPs.

You can see all subdomains that are registered for NLB IPs in your cluster by running the following command.

ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>

DNS microservice updates are asynchronous and might take several minutes to apply. Note that if you run an ibmcloud oc nlb-dns command and receive a 200 confirmation message, you might still have to wait for your changes to be implemented. To check the status of your subdomain, run ibmcloud oc nlb-dns ls and find the Status column in the output.



 Registering NLB IPs with a DNS subdomain 

Expose your app to the public internet by creating a subdomain for the network load balancer (NLB) IP address.

Before you begin:



* Review the following limitations.



* You can't create subdomains for private NLBs.
* You can register up to 128 subdomains.
: Depending on [your account settings](https://cloud.ibm.com/docs/account?topic=account-service-endpoints-overview), you can use public or private endpoints to manage categories programmatically. For information about endpoints per region, see [API endpoints](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-endpointsendpoints_api).

KEY_ID
: ID value of the ingestion key for which you want to get details.

SERVICE_KEY
: Service key value. A service key is a unique code that is passed in an API request to identify the calling application or user. The service key is specific to a logging instance. For more information on how to generate a service key, see [Managing service keys](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-service_keys).

For example, to get information on an ingestion key that is available in an instance in US South, you can run the following request:

curl https://api.us-south.logging.cloud.ibm.com/v1/config/keys/123456789" -H "content-type: application/json" -H "servicekey: xxxxxxxxx"





 Create a key 

curl -X POST https://API_ENDPOINT/v1/config/keys/?type="ingestion"
-H 'content-type: application/json' -H 'servicekey: SERVICE_KEY' -d '{"name": "KEY_NAME"}'

Where:

API_ENDPOINT
: Depending on [your account settings](https://cloud.ibm.com/docs/account?topic=account-service-endpoints-overview), you can use public or private endpoints to manage categories programmatically. For information about endpoints per region, see [API endpoints](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-endpointsendpoints_api).

SERVICE_KEY
: Service key value.
For example, to create a new user for an "example-deployment", use the following command.

ibmcloud cdb user-create example-deployment <newusername> <newpassword>

Once the task is finished, you can retrieve the new user's connection strings with the ibmcloud cdb deployment-connections command.

ibmcloud cdb deployment-connections example-deployment -u <newusername> [--endpoint-type <endpoint type>]

Full connection information is returned by the ibmcloud cdb deployment-connections command with the --all flag. To retrieve all the connection information for a deployment named "example-deployment", use the following command.

ibmcloud cdb deployment-connections example-deployment -u <newusername> --all [--endpoint-type <endpoint type>]

If you don't specify a user, the deployment-connections commands return information for the admin user by default. If you don't specify an endpoint type, the connection string returns the public endpoint by default. If your deployment has only a private endpoint, you must specify --endpoint-type private or the commands return an error. The user and endpoint type is not enforced. You can use any user on your deployment with either endpoint (if both exist on your deployment).

To use the ibmcloud cdb CLI commands, you must [install the Cloud Databases plug-in](https://cloud.ibm.com/docs/databases-for-mongodb?topic=databases-cli-plugin-cdb-referenceinstalling-the-cloud-databases-cli-plug-in).





 From the API 

The Foundation Endpoint that is shown on the Overview panel of your service provides the base URL to access this deployment through the API. To create and manage users, use the base URL with the /users endpoint.

curl -X POST 'https://api.
To provide access group and assign your catalog to users, see [Setting up the access groups](https://cloud.ibm.com/docs/account?topic=account-groups).
10. Optional: From the [IBM Cloud Resource list](https://cloud.ibm.com/resources), remove the IBM Cloud Log Analysis, IBM Cloud Monitoring, and IBM Cloud Activity Tracker service instances that you created when you validated the product.





In this tutorial, you learned how to create a private catalog in IBM Cloud? and How to upload an IBM-provided Terraform template as a product to your catalog?





 What's next? 



* [Make your private catalog available to your users](https://cloud.ibm.com/docs/account?topic=account-restrict-by-userprereq-restrict).
* [Assign users access to your private catalog](https://cloud.ibm.com/docs/account?topic=account-catalog-access).
* [Explore other settings that you can apply to your private catalog](https://cloud.ibm.com/docs/account?topic=account-filter-account).
Git Repos and Issue Tracking is an IBM-hosted component of the Continuous Delivery service. All of the data that you provide to Git Repos and Issue Tracking, including but not limited to source files, issues, pull requests, and project configuration properties, is managed securely within Continuous Delivery. However, Git Repos and Issue Tracking supports various mechanisms for exporting, sending, or otherwise sharing data to users and third parties.

The ability of Git Repos and Issue Tracking to share information is typical of many social coding platforms. However, such sharing might conflict with regulatory controls that apply to your business. After you create a project in Git Repos and Issue Tracking, but before you entrust any files, issues, records, or other data with the project, review the project settings and change any settings that you deem necessary to protect your data. Settings to review include visibility levels, email notifications, integrations, web hooks, access tokens, deploy tokens, and deploy keys.



 Project visibility levels 

Git Repos and Issue Tracking projects can have one of the following visibility levels: private, internal, or public.



* Private projects are visible only to project members. This setting is the default visibility level for new projects, and is the most secure visibility level for your data.
* Internal projects are visible to all users that are logged in to IBM Cloud.
* Public projects are visible to anyone.



To limit project access to only project members, complete the following steps:



1. From the project sidebar, click Settings > General.
2. On the General Settings page, click Visibility > project features > permissions.
3. Locate the Project visibility setting.
4. Select Private, if it is not already selected.
5. Click Save changes.







 Project membership 

Git Repos and Issue Tracking is a cloud hosted social coding environment that is available to all Continuous Delivery users. If you are a Git Repos and Issue Tracking project Maintainer or Owner, you can invite any user and group members to the project. IBM Cloud places no restrictions on who you can invite to a project.
$priUplink = New-NsxEdgeInterfaceSpec -index 0 -Name "Private Uplink" -Type Uplink -ConnectedTo (Get-VDPortgroup SDDC-DPortGroup-Mgmt) -PrimaryAddress 10.208.242.130 -SubnetPrefixLength 26 -SecondaryAddresses 10.208.242.131,10.208.242.132,10.208.242.133
$pubUplink = New-NsxEdgeInterfaceSpec -index 1 -Name "Public Uplink" -Type Uplink -ConnectedTo (Get-VDPortgroup SDDC-DPortGroup-External) -PrimaryAddress 169.48.73.42 -SubnetPrefixLength 29 -SecondaryAddresses 169.48.73.43,169.48.73.44
$transit = New-NsxEdgeInterfaceSpec -index 2 -Name "Transit" -Type internal -ConnectedTo (Get-NsxLogicalSwitch OpenShift-Transit) -PrimaryAddress 192.168.100.1 -SubnetPrefixLength 24
New-NsxEdge -Name OpenShift-ESG -Cluster (Get-Cluster cluster1) -EnableHA -Datastore (Get-Datastore vsanDatastore) -Username admin -Password VMware12345! -FormFactor xlarge -Interface $priUplink,$pubUplink,$transit

 Set default gateway and add static routes to the ESG
Get-NsxEdge OpenShift-ESG | Get-NsxEdgeRouting | Set-NsxEdgeRouting -DefaultGatewayAddress 169.48.73.41 -DefaultGatewayVnic 1 -DefaultGatewayDescription "Public traffic"-confirm:$false
Get-NsxEdge OpenShift-ESG | Get-NsxEdgeRouting | New-NsxEdgeStaticRoute -Network 10.0.0.0/8 -NextHop 10.208.242.129 -Vnic 0 -Description "Private traffic" -confirm:$false
Valid values are public, private and project. Setting a visibility of public means that your app can receive requests from the public internet or from components within the Code Engine project. Setting a visibility of private means that your app is not accessible from the public internet and network access is only possible from other IBM Cloud using Virtual Private Endpoints (VPE) or Code Engine components that are running in the same project. Visibility can only be private if the project supports application private visibility. Setting a visibility of project means that your app is not accessible from the public internet and network access is only possible from other Code Engine components that are running in the same project. This value is optional.

--wait, -w
: Create the application and wait for the application to be ready. If you specify the --wait option, the application create waits for a maximum time in seconds, as set by the --wait-timeout option, for the application to become ready. If the application is not ready within the specified wait-timeout period, the application create fails. This value is optional. The default value is true.

--wait-timeout, --wto
: The length of time in seconds to wait for the application to be ready. This value is required if the --wait option is specified. This value is ignored if the --no-wait option is specified. The default value is 600.





 Example 

ibmcloud ce application create --name myapp --image icr.io/codeengine/hello





 Example output 

Creating application 'myapp'...
[...]
Run ibmcloud ce application get -n 'myapp' to check the application status.
OK

https://myapp.4svg40kna19.us-south.codeengine.appdomain.cloud

When you run ibmcloud ce application get -n 'myapp' to check the application status, the URL for your application is displayed.







 ibmcloud ce application delete 

Delete an application.
export HPCS_CRN=crn:v1:staging:public:xxx:yyy:zzz

export CERT=/Users/admin1/cert.pem

export ADMIN_PRIV_KEY=/Users/admin1/.hpcs-cert-mgr-cfg/44de77d2-599b-0089-2f0f-bad8d1c94a7c.priv

ibmcloud hpcs-cert-mgr cert set --crn ${HPCS_CRN} --admin-priv-key ${ADMIN_PRIV_KEY} --cert-id testcert --cert ${CERT}
* Output

The command returns the output similar to the following example:

connecting to server [cert-mgr.us-south.hs-crypto.cloud.ibm.com:443]...
command completed successfully.







 hpcs-cert-mgr cert list 

Use this command to list all the certificates that are managed by the administrator for your instance certificate manager server.

ibmcloud hpcs-cert-mgr cert list --crn HPCS_CRN [--private]



* Command options

--crn HPCS_CRN
: Required. The crn of your Hyper Protect Crypto Services instance. You can use the ibmcloud resource service-instances --long command to retrieve the crn.

--private
: Optional. If you use this option, the certificate manager server URL points to the private network. For example,: cert-mgr.private.<region>.hs-crypto.cloud.ibm.com:443. The region is the abbreviation of the geographic area where you log in to IBM Cloud. In this case, you need to use the private network to connect your service instance.
* Example

export HPCS_CRN=crn:v1:staging:public:xxx:yyy:zzz
Enter passphrase to use the private key '--admin-priv-key'>
OK

Starting to decrypt key '/Users/hexiaohu/.hpnet-cfg/hpnet-test1-a5-d8-9a-25.priv'....

Connecting to the server hpnet-test1 [52.117.54.147] ...

The connecting server's certificate is valid and already confirmed in the previous command
The certificate can be confirmed again by removing the HPVS instance from file /Users/hexiaohu/.hpnet-cfg/known_instances

Continue connecting to the server...

Deleting the public key of the admin...

OK
The public key of the admin was deleted.

Show more
* The hpnet node get command, to get the configuration on the VPN node

ibmcloud hpnet node get --instance "$HPVS_A"

Connecting to the server hpnet-test1 [52.117.54.147] ...

The connecting server's certificate is valid and already confirmed in the previous command
The certificate can be confirmed again by removing the HPVS instance from file /Users/hexiaohu/.hpnet-cfg/known_instances

Continue connecting to the server...

Querying detail of the node hpnet-test1 ...
+-----------------+----------------------------------------------+
 NODE_PROPERTIES VALUES 
+-----------------+----------------------------------------------+
 VPNPublicKey zHlHCJCV7ub7FJjAWOXGZU3BV/rQOLMwMCq2dqOKsW0=
You can update which products are included or excluded at any time by updating your private catalog's settings.





 Branding your private catalog with a custom banner 

You can enhance the look and feel of your private catalog to match your brand by adding a custom image to your private catalog's banner. All users who are given access to your private catalog can see the custom banner when they go to the private catalog to search for products, instead of the default IBM Cloud banner. To add a custom banner image, complete the following steps:



1. Go to Manage > Catalogs, then click Private catalogs.
2. Click the Overflow menu icon ![Actions icon](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/icons/action-menu-icon.svg) on the row of the private catalog that you want to add a banner for, then click Edit.
3. Add a URL to your custom banner in the Catalog banner field, or you can click Upload to add an image directly. The maximum recommended image size is 944 x 260 pixels.
4. Click Update.
5. Then, go to the [catalog](https://cloud.ibm.com/catalog), and select your private catalog from the list to view the updated look and feel of your private catalog.



You can also customize the provider name for private catalog products that you add to your catalogs. By default, they display with Community as the provider, which is a filter in the catalog, but you can customize this to be your company or organization's name. For more information, see [Providing catalog entry details](https://cloud.ibm.com/docs/account?topic=account-cm-catalog-detailscm-catalog-entry).





 Authorizing access to private catalogs by using the console
Replace <private_connection_details> with the base64 encoded output from the previous step.
{"overwrite": true,"path": "/etc/NetworkManager/system-connections/<private_interface>.nmconnection","mode": 256,"contents": {"source": "data:text/plain;base64,<private_connection_details>"}}

For example, to add the networking information from the previous step, enter the following code sample.

{ "overwrite": true,"path": "/etc/NetworkManager/system-connections/en01.nmconnection","mode": 256,"contents": { "source": "data:text/plain;base64,W2Nvbm5lY3Rpb25dCiAgICAgIGlkPWVubzEKICAgICAgdHlwZT1ldGhlcm5ldAogICAgICBpbnRlcmZhY2UtbmFtZT1lbm8xCiAgICAgIFtpcHY0XQogICAgICBuZXZlci1kZWZhdWx0PXRydWUKICAgICAgYWRkcmVzczE9MTAuMTkwLjE5Ni45LzI2LDEwLjE5MC4xOTYuMTI5CiAgICAgIGRucz0xMC4wLjgwLjExOzEwLjAuODAuMTI7CiAgICAgIHJvdXRlMT0xMC4wLjAuMC84LDEwLjE5MC45Ni4xMjkKICAgICAgcm91dGUyPTE2MS4yNi4wLjAvMTYsMTAuMTkwLjk2LjEyOQogICAgICByb3V0ZTM9MTY2LjguMC4wLzE0LDEwLjE5MC45Ni4xMjkKICAgICAgZG5zLXNlYXJjaD0KICAgICAgbWF5LWZhaWw9ZmFsc2UKICAgICAgbWV0aG9kPW1hbnVhbAo="}},
7. Convert your public networking information to base64 by running the following command. Replace <public_interface> with the name of your public interface name, for example, eno2. Replace <publicIPCIDR> and <gateway> with your public IP CIDR and public IP gateway. These values are what you used to set up your connection in the previous section.
echo 'connection]
id=<public_interface>
type=ethernet
interface-name=<public_interface>
ipv4]
address1=<publicIPCIDR>,<gateway>
dns=8.8.8.8;4.4.4.4;
dns-search=
may-fail=false
method=manual' |base64

Example command to base64 encode your public interface details.

echo 'connection]
id=eno2
type=ethernet
interface-name=eno2
ipv4]
address1=52.117.108.24/28,52.117.108.17
dns=8.8.8.8;4.4.4.4;
dns-search=
may-fail=false
method=manual' |base64
8. Add these connection details to your ignition file. Replace <public_interface> with your public interface name, for example eno2.