Projects Workflows

The HERE platform allows you to create and manage projects. As an admin of a project, you can grant other users, apps, and groups access to the project. Users with project access rights can create and manage project resources - catalogs, schemas, templates, and pipelines. Through project policies, more granular control can be achieved for project resources. The compute, storage, and transfer usage associated with any project resource is automatically tracked based on project ID.

The OLP CLI provides tools for:

The following steps show how to manage projects, including resources and access to those resources:

  1. Prepare:
  2. Create and list a project catalog:
  3. Create and list a project pipeline:
  4. Add an application to the project and list the application:
  5. Set up granular access to the project resources through project policies:
  6. Make resources available to be linked to other projects:
  7. Link project resources:
  8. Unlink project resources:
  9. Make resource unavailable to be linked to other projects:
  10. Clean up project resources:

For more details, see Project Commands, Catalog Commands, and Pipeline Commands.

Note:

For more information on migrating resources created outside of a project into a project, see the migration guide.

Create a Project

First, to manage any project resource, you need to create a project. For this, use the project create command:

Example:

olp project create <project-id> <project-name>

Note

Use unique values for the <project-id> and <project-name> placeholders. <project-id> must contain from 4 to 16 lowercase alphanumeric characters including hyphens. <project-id> cannot start or end with a hyphen.

The command creates the project and displays the project HRN. Note this HRN down as you'll need it later in the workflow.


Project hrn:here:authorization::myrealm:project/<project-id> has been created.

Create a Catalog in a Project

Follow the steps below to create a new catalog in a project.

Note

Use a unique value for the <catalog-id> placeholder.

Use the catalog create command and specify the catalog ID, name, summary, description, and project scope:

Example:

Linux
Windows
olp catalog create <catalog-id> scoped-catalog-name \
    --summary "A new scoped catalog" \
    --description "A new scoped catalog" \
    --scope hrn:here:authorization::myrealm:project/<project-id>
olp catalog create <catalog-id> scoped-catalog-name ^
    --summary "A new scoped catalog" ^
    --description "A new scoped catalog" ^
    --scope hrn:here:authorization::myrealm:project/<project-id>

The command creates the catalog with the specified project scope and displays the catalog HRN. Note this HRN down as you'll need it later in the workflow.

The command displays the following results:


Catalog hrn:here:data:::<catalog-id> has been created.

List the Project Catalog

To verify that the catalog has been created in the scope of the project, use the catalog list command:

Example:


olp catalog list --scope hrn:here:authorization::myrealm:project/<project-id>

The command displays the following results:


hrn:here:data:::<catalog-id>

Use olp catalog show <catalog HRN> to display more information about a catalog.

Create a Pipeline in a Project

Follow the steps below to create a new pipeline in a project. Note that <pipeline-name> must be unique.

Use the pipeline create command and specify the pipeline ID, name, description, and project scope:

Example:

Linux
Windows
olp pipeline create <pipeline-name> \
   --description "This pipeline analyzes data" \
   --scope hrn:here:authorization::myrealm:project/<project-id>
olp pipeline create <pipeline-name> ^
   --description "This pipeline analyzes data" ^
   --scope hrn:here:authorization::myrealm:project/<project-id>

The command creates the pipeline with the specified project scope and displays the unique <pipeline UUID>. Note this UUID down as you'll need it later in the workflow to delete the pipeline.

The command displays the following results:


Pipeline has been created.
ID: <pipeline UUID>

List the Project Pipeline

To verify that the pipeline has been created in the scope of the project, use the pipeline list command:

Example:


olp pipeline list --scope hrn:here:authorization::myrealm:project/<project-id>

The command displays the following results:


Available pipelines:

name                                    id                                      description
<pipeline-name>                         <pipeline UUID>                         This pipeline analyzes data

Note that the --scope <project HRN> parameter is also applicable to all pipeline template and pipeline version commands. For more details, see Pipeline Template Commands and Pipeline Version Commands.

For more information about pipeline workflows, see Pipeline Workflows.

Create a Template in a Project

Follow the steps below to create a new pipeline template in a project.

Use the template create command and specify the template name, runtime environment (stream or batch), package, main class, the project scope that the pipeline template belongs to, and input catalog IDs that are expected in the pipeline version configuration:

Example:

Linux
Windows
olp pipeline template create <name> <cluster type> <JAR file> \
   <class name> 
    --scope <project HRN> 
    --input-catalog-ids catalogExample1 [command options]
olp pipeline template create <name> <cluster type> <JAR file> \
   <class name> 
    --scope <project HRN> 
    --input-catalog-ids catalogExample1 [command options]

The command creates the pipeline template with the specified project scope and displays the unique <template UUID>. Note this UUID down as you'll need it later in the workflow to delete the pipeline template.

The command displays the following results:


Pipeline template has been created.
ID: <template UUID>

List the Project Template

To verify that the pipeline has been created in the scope of the project, use the template list command:

Example:


olp pipeline template list 
    --scope hrn:here:authorization::myrealm:project/<template-id>

The command displays the following results:


Available pipelines:

name                                    id                                      description
<template-name>                         <template UUID>                         

Add an App to the Project

Follow the steps below to share the project with an app.

Use the project access grant command and specify the <App ID>, name, description, and project scope:

Example:

Linux
Windows
olp project access grant hrn:here:authorization::myrealm:project/<project-id> \
   --app <App ID>
olp project access grant hrn:here:authorization::myrealm:project/<project-id> ^
   --app <App ID>

Note

Use the olp credentials list command to get an <App ID>. For more information on how to create a new app and retrieve its app ID, see Credentials Setup and Credentials Commands.

The command displays the following results:


App <App ID> has been granted access to the project hrn:here:authorization::myrealm:project/<project-id>

Note that the OLP CLI not only supports granting project access to apps, users, and groups, but also adding apps or users as project administrators. For more details, see Project Access Commands and Project Admin Commands.

List the Project App

To verify that the app has been added to the project, use the project access list command:

Example:


olp project access list hrn:here:authorization::myrealm:project/<project-id>

The command displays the following results:


Available members with project access:

type           HRN                                                                       id                       name
app            hrn:here:account::myrealm-test:app/<App ID>                               <App ID>                 My App

List Platform Policies

The HERE platform provides predefined policies that can be attached to an entity (user, group, or app) that has been granted access to a project. These policies restrict access to resources in the project based on the resource type, for example catalog, and associated permissions. You can also create custom policies (more on these below).

To get a list of available platform policies, use the project policy list command with --type here-platform parameter:

Example:


olp project policy list hrn:here:authorization::myrealm:project/<project-id> --type here-platform

The command displays the following results:


HRN                                                                                         TYPE
hrn:here:authorization::HERE:platform:policy/artifacts-read-all                         here-platform
hrn:here:authorization::HERE:platform:policy/schemas-read-and-modify-all                here-platform
hrn:here:authorization::HERE:platform:policy/all-access-all-project-resources           here-platform
hrn:here:authorization::HERE:platform:policy/catalogs-read-and-write-and-manage-all     here-platform
hrn:here:authorization::HERE:platform:policy/catalogs-read-and-write-all                here-platform
hrn:here:authorization::HERE:platform:policy/schemas-read-all                           here-platform
hrn:here:authorization::HERE:platform:policy/pipelines-all-access                       here-platform
hrn:here:authorization::HERE:platform:policy/artifacts-read-and-modify-all              here-platform
hrn:here:authorization::HERE:platform:policy/pipeline-templates-all-access              here-platform
hrn:here:authorization::HERE:platform:policy/catalogs-read-all                          here-platform

Use olp project policy show <project HRN> <policy HRN> to display more information about a project policy.

As suggested in the output above, we can run olp project policy show to display more information about any of the project policies.

Note

If --type here-platform parameter is not specified, the command lists all custom as well as here-platform policies. However, since at this point we haven't created any custom policy, the output is the same.

Show Details of a Project Policy

We can get the details of any project policy by running the project policy show command:

Example:


olp project policy show hrn:here:authorization::myrealm:project/<project-id> \ 
hrn:here:authorization::HERE:platform:policy/all-access-all-project-resources

The command displays the following results:


Details of the project policy:
id                       all-access-all-project-resources
hrn                      hrn:here:authorization::HERE:platform:policy/all-access-all-project-resources
name                     AllAccessAllProjectResources
description              A policy that indicates a Project Member has access to all project resources in the project.
type                     here-platform

Permissions
RESOURCE     TYPE                  ALLOWED ACTIONS
-            catalog               readResource, writeResource, manageResource
-            pipeline              all
-            pipeline-template     all

When an entity is added to the project, by default it will have all access to all resources. HERE platform attaches all-access-all-project-resources policy to an entity on being granted access to a project by default.

We can see the attached policies to an entity by running the olp project access show command:

Example:


olp project access show hrn:here:authorization::myrealm:project/<project-id> \ 
--app <app id>

The command displays the following results:


HRN                                                                                   TYPE
hrn:here-dev:authorization::HERE:platform:policy/all-access-all-project-resources     here-platform

Use olp project policy show <project HRN> <policy HRN> to display more information about a project policy.

Attach a Platform Policy

We can attach any platform policy in the list shown as above. It is also possible to attach more than one policy at a time. For this workflow and to keep it simple, we will attach only one platform policy.

To attach the policy, use the project access grant command:

Example:

Linux
Windows
olp project access grant hrn:here:authorization::myrealm:project/<project-id> \
--app <App ID> --policy hrn:here:authorization::HERE:platform:policy/catalogs-read-all
olp project access grant hrn:here:authorization::myrealm:project/<project-id> ^
--app <App ID> --policy hrn:here:authorization::HERE:platform:policy/catalogs-read-all

Output:


Application <App ID> has been granted access to the project hrn:here:authorization::myrealm:project/<project-id> with attached policy hrn:here:authorization::HERE:platform:policy/catalogs-read-all.

Show Attached Policies

Let's see the policies attached to this app by running the olp project access show command:

Example:


olp project access show hrn:here:authorization::myrealm:project/<project-id> \
--app <app id>

The command displays the following results:


HRN                                                                                   TYPE
hrn:here:authorization::HERE:platform:policy/catalogs-read-all     here-platform

Use olp project policy show <project HRN> <policy HRN> to display more information about a project policy.

As we can see, the policy attached to the app with the <app id> ID is now the catalogs-read-all platform policy.

Validate Access to the Resources Based on the Attached Platform Policy

The policy that has been attached to the member allows read only access to the catalogs within the project.

We will first try to get the details of the catalog within the project and then will try to do an update to the catalog using the credentials of the member to which the policy has been attached. Since the policy allows only read access to the catalog, while we would be able to fetch the details of the catalog, an attempt to update the catalog will result in failure.

To get the details of a catalog, use the olp catalog show command:

Example:

Linux
olp catalog show hrn:here:data:::<catalog-id> \
--scope hrn:here:authorization::myrealm:project/<project-id> \
--credentials path/to/credentials.properties

The command displays the following results:


Details of the hrn:here:data:::<catalog-id> catalog:

id                       <catalog-id>
name                     scoped-catalog-name
hrn                      hrn:here:data:::<catalog-id>
summary                  A new scoped catalog
description              A new scoped catalog
notifications enabled?   false
tags                     <empty>
billing tags             <empty>
created                  <creation date>
owner                    <owner app id>, <realm>
config version           0
metadata version         -1
metadata minimum version -1
marketplace ready        false

However, if we try to update the catalog, it will result in an exception.

Linux
olp catalog update hrn:here:data:::<catalog-id> \
--description "Updated description" \
--scope hrn:here:authorization::myrealm:project/<project-id> \
--credentials path/to/credentials.properties

The command displays the following results:

{"error":"Forbidden","error_description":"These credentials do not authorize access"}

Platform policies provide configurations covering many common scenarios. If you have a specific use case not covered by platform polices, you can create a custom policy. In the next few steps, we will demonstrate how a custom policy can be created and attached to an entity. Later on, we will validate the access to the resources as defined in the policy.

Before we go ahead and create a custom policy and grant the application access to resources within the project based on the policy configuration, let's validate that the application indeed has access to all the resources.

We will create another catalog within the project for this purpose.

Create Another Catalog in the Project

Follow the steps below to create a new catalog in a project.

Note

Use a unique value for the <catalog2-id> placeholder.

Use the catalog create command and specify the catalog ID, name, summary, description, and project scope:

Example:

Linux
Windows
olp catalog create <catalog2-id> scoped-catalog2-name \
--summary "Second scoped catalog" \
-- description "Second scoped catalog" \
--scope hrn:here:authorization::myrealm:project/<project-id>
olp catalog create <catalog2-id> scoped-catalog2-name ^
--summary "Second scoped catalog" ^
-- description "Second scoped catalog" ^
--scope hrn:here:authorization::myrealm:project/<project-id>

The command creates the catalog with the specified project scope and displays the catalog HRN. Note this HRN down as you'll need it later in the workflow.

The command displays the following results:


Catalog hrn:here:data:::<catalog2-id> has been created.

Now that we have two catalogs within the same project, if using the credentials of the application that has been granted access to the project, we run olp catalog show, we will be able to see the details of these catalogs.

Example:

Linux
olp catalog show hrn:here:data:::<catalog-id> \
--scope hrn:here:authorization::myrealm:project/<project-id> 
--credentials path/to/credentials.properties

The command displays the following results:


Details of the hrn:here:data:::<catalog-id> catalog:

id                       <catalog-id>
name                     scoped-catalog-name
hrn                      hrn:here:data:::<catalog-id>
summary                  A new scoped catalog
description              A new scoped catalog
notifications enabled?   false
tags                     <empty>
billing tags             <empty>
created                  <creation date>
owner                    <owner app id>, <realm>
config version           0
metadata version         -1
metadata minimum version -1
marketplace ready        false

Linux
olp catalog show hrn:here:data:::<catalog2-id> \
--scope hrn:here:authorization::myrealm:project/<project-id>
--credentials path/to/credentials.properties

The command displays the following results:


Details of the hrn:here:data:::<catalog2-id> catalog:

id                       <catalog2-id>
name                     scoped-catalog2-name
hrn                      hrn:here:data:::<catalog2-id>
summary                  Second scoped catalog
description              Second scoped catalog
notifications enabled?   false
tags                     <empty>
billing tags             <empty>
created                  <creation date>
owner                    <owner app id>, <realm>
config version           0
metadata version         -1
metadata minimum version -1
marketplace ready        false

Create a Custom Policy

We can create a custom policy and attach it to a member of the project.

As we have admin rights to the project, we will create a custom policy to allow access to the catalog with the <catalog-id> ID that was created within the project in previous steps.

To create the custom policy, use the project policy create command:

We will first create a file that contains all the required details. We will use the first catalog created in the previous steps and define a custom policy for it.


{
  "id": "full-access-<catalog-id>-catalog",
  "name": "Access to <catalog-id> catalog",
  "description": "Full access to <catalog-id> catalog",
  "permissions": [
    {
      "resource": "hrn:here:data:::<catalog-id>",
      "allowedActions": [
        "readResource",
        "manageResource",
        "writeResource"
      ]
    }
  ]
}

Save the config file as config.json.

To create the custom policy, execute the following command:

Example:

Linux
Windows
olp project policy create hrn:here:authorization::myrealm:project/<project-id> \
--config path/to/config.json
olp project policy create hrn:here:authorization::myrealm:project/<project-id> ^
--config path/to/config.json

Output:


Policy hrn:here:authorization::myrealm:project/<project-id>:policy/full-access-<catalog-id>-catalog has been created in project hrn:here:authorization::myrealm:project/<project-id>.

List Custom Policies

To get a list of available custom policies, use the project policy list command with the --type custom parameter:

Example:


olp project policy list hrn:here:authorization::myrealm:project/<project-id> --type custom

The command displays the following results:


HRN                                                                                         TYPE
hrn:here:authorization::myrealm:project/<project-id>:policy/full-access-<catalog-id>-catalog     custom
Use olp project policy show <project HRN> <policy HRN> to display more information about a project policy.

As suggested in the output above, we can run olp project policy show to display more information about the custom policy listed in the output.

Attach a Custom Policy

Once we have the custom policy created, we can then attach the policy to a member of the project.

To attach the policy, use the project access grant command:

Example:

Linux
Windows
olp project access grant hrn:here:authorization::myrealm:project/<project-id> \ 
--app <App ID> --policy hrn:here:authorization::myrealm:project/<project-id>:policy/full-access-<catalog-id>-catalog
olp project access grant hrn:here:authorization::myrealm:project/<project-id> ^
--app <App ID> --policy hrn:here:authorization::myrealm:project/<project-id>:policy/full-access-<catalog-id>-catalog

Output:


Application <App ID> has been granted access to the project hrn:here:authorization::myrealm:project/<project-id> with attached policy hrn:here:authorization::myrealm:project/<project-id>:policy/full-access-<catalog-id>-catalog.

Validate Access to the Resources Based on the Attached Custom Policy

Now that the policy has been attached to the application, the application will have access to the resources within the project as per the defined policy. In this case, the custom policy that we created allows access to just the first catalog with the <catalog-id> ID.

Using the credentials of the application that's a member of the project, we run olp catalog show and we will be able to see the details of the catalog with the <catalog-id> ID.

Example:

Linux
olp catalog show hrn:here:data:::<catalog-id> \
--scope hrn:here:authorization::myrealm:project/<project-id>
--credentials path/to/credentials.properties

The command displays the following results:


Details of the hrn:here:data:::<catalog-id> catalog:

id                       <catalog-id>
name                     scoped-catalog-name
hrn                      hrn:here:data:::<catalog-id>
summary                  A new scoped catalog
description              A new scoped catalog
notifications enabled?   false
tags                     <empty>
billing tags             <empty>
created                  <creation date>
owner                    <owner app id>, <realm>
config version           0
metadata version         -1
metadata minimum version -1
marketplace ready        false

However, trying to get the details of catalog with id <catalog2-id> will result in an exception.

Linux
catalog show hrn:here:data:::<catalog2-id> \
--scope hrn:here:authorization::myrealm:project/<project-id>
--credentials path/to/credentials.properties

The command displays the following results:

{"error":"Forbidden","error_description":"These credentials do not authorize access"}

As we can see, with the project policy enforced, the application now is restricted in its access to the project resources.

Detach a Custom Policy

To detach the custom policy, run the project access revoke command:

Example:

Linux
Windows
olp project access revoke hrn:here:authorization::myrealm:project/<project-id> \
--app <App ID> --policy hrn:here:authorization::myrealm:project/<project-id>:policy/full-access-<catalog-id>-catalog
olp project access revoke hrn:here:authorization::myrealm:project/<project-id> ^
--app <App ID> --policy hrn:here:authorization::myrealm:project/<project-id>:policy/full-access-<catalog-id>-catalog

Output:


Application <App ID> has been revoked access to the policy hrn:here:authorization::myrealm:project/<project-id>:policy/full-access-<catalog-id>-catalog in the project hrn:here:authorization::myrealm:project/<project-id>.

Get a List of Actions Available for Linking

We are now at the step in the workflow where a resource from a project can be linked to a different project within the same organization. This is a two-step process where the resource from the home project will first be made available to link to the other project and then, once available for linking, the resource will be linked to the other project.

We are going to use the resource (catalog) created earlier for this. We will be creating a destination project to which we will first make the resource available for linking and later link this available resource.

Let's create the destination project first:

The instructions are similar to the way the first project was created. For this, use the project create command:

Example:

olp project create <destination-project-id> <destination-project-name>

Note

Use unique values for the <destination-project-id> and <destination-project-name> placeholders. <destination-project-id> must contain from 4 to 16 lowercase alphanumeric characters including hyphens. <destination-project-id> cannot start or end with a hyphen.

The command creates the project and displays the project HRN. Note this HRN down as you'll need it later in the workflow.


Project hrn:here:authorization::myrealm:project/<destionation-project-id> has been created.

Now that we have the destination project created, the next step in the process is to determine what the supported actions are for a given resource type (in this case a catalog) since specifying action is mandatory while executing the command to make a resource available to link to this destination project.

To get a list of actions available for a resource type for linking, use the resource action list command:

Example:


olp resource action list catalog available-to-link --json

The command displays the following results:


{
  "allowedActions": [
    "readResource",
    "writeResource"
 ]
}

Make a note of the list of actions in this step as we will need it while specifying --actions in the next step.

As we have admin rights to the project, we can make a resource available for linking to other projects in the same organization. A project resource can be made available to be linked to a specific project or all projects in the same organization.

We also need to specify the list of allowed actions on this resource while executing the command. As we noted down in the previous step, the supported actions are readResource and writeResource for catalog resource type. We, for this workflow, will be specifying just the readResource action. It's absolutely fine to specify any of these or both but for the workflow purpose and to keep it simple, we are going ahead just with one action.

To make a project resource available to link, use the resource link availability create command:

Example:

Linux
Windows
olp resource link availability create hrn:here:data:::<catalog-id> \
    --actions readResource \
    --available-to hrn:here:authorization::myrealm:project/<destination-project-id> \
    --scope hrn:here:authorization::myrealm:project/<project-id> \
    --json
olp resource link availability create hrn:here:data:::<catalog-id> ^
    --actions readResource ^
    --available-to hrn:here:authorization::myrealm:project/<destination-project-id> ^
    --scope hrn:here:authorization::myrealm:project/<project-id> ^
    --json

The command displays the following results:


{
     "resource": "hrn:here:data:::<catalog-id>",
     "allowedActions": [
         "readResource"
     ],
     "projectHrn": "hrn:here:authorization::myrealm:project/<destination-project-id>"
}

Show a Project Resource's Availability to be Linked to a Project

As we have manage access to the project resources, we can view the link availability details of the resource. To show the availability of a resource to be linked, use the resource link availability show command:

Example:

Linux
Windows
olp resource link availability show hrn:here:data:::<catalog-id> \
    --available-to hrn:here:authorization::myrealm:project/<destination-project-id> \
    --scope hrn:here:authorization::myrealm:project/<project-id> \
    --json
olp resource link availability show hrn:here:data:::<catalog-id> ^
    --available-to hrn:here:authorization::myrealm:project/<destination-project-id> ^
    --scope hrn:here:authorization::myrealm:project/<project-id> ^
    --json

The command displays the following results:


{
     "resource": "hrn:here:data:::<catalog-id>",
     "allowedActions": ["readResource"],
     "projectHrn": "hrn:here:authorization::myrealm:project/<destination-project-id>"
}

List a Project Resource's Availability to be Linked

As we have manage access to the project resources, we can list the availability details of a resource. To list the availability of a resource to link, use the resource link availability list command:

Example:

Linux
Windows
olp resource link availability list hrn:here:data:::<catalog-id> \
    --scope hrn:here:authorization::myrealm:project/<project-id> \
    --json
olp resource link availability list hrn:here:data:::<catalog-id> ^
    --scope hrn:here:authorization::myrealm:project/<project-id> ^
    --json

The command displays the following results:


{"resources": [
    {
        "resource": "hrn:here:data:::<catalog-id>",
        "allowedActions": [
            "readResource"
        ],
        "projectName": "",
        "projectId": "",
        "projectHrn": "hrn:here:authorization::myrealm:project/<destination-project-id>"
    }
]}

All identities that have access to the project can link an available resource to the project. To get a list of all the resources available to be linked to the project, use the resource link availability list command:

Example:

Linux
Windows
olp project resource link availability list hrn:here:authorization::myrealm:project/<destination-project-id> \
    --type catalog --json
olp project resource link availability list hrn:here:authorization::myrealm:project/<destination-project-id> ^
    --type catalog --json

The command displays the following results:


{"resources":[
    {
        "hrn": "hrn:here:data:::<catalog-id>",
        "allowedActions": [
            "readResource"
        ],
        "type": "catalog"
    }
]}

All identities that have access to the project can link any available resource to the project. To link a resource to a project, use the project resources link command:

Example:

Linux
Windows
olp project resources link hrn:here:authorization::myrealm:project/<destination-project-id> \
   hrn:here:data:::<catalog-id> \
   --actions readResource writeResource --json
olp project resources link hrn:here:authorization::myrealm:project/<destination-project-id> ^
   hrn:here:data:::<catalog-id> ^
   --actions readResource writeResource --json

The command displays the following results:


{
  "resource": "hrn:here:data:::<catalog-id>",
  "project": "hrn:here:authorization::myrealm:project/<destination-project-id>",
  "type": "catalog",
  "relation": "reference",
  "allowedActions": [
     "readResource"
  ]
}

List Resources in a Project

All identities that have access to the project can list all of its resources. To list all resources in a project, use the project resources list command:

Example:


olp project resources list hrn:here:authorization::myrealm:project/<destination-project-id> --json

The command displays the following results:


{
  "resources": [
    {
      "resource": "hrn:here:data:::<catalog-id>",
      "project": "hrn:here:authorization::myrealm:project/<destination-project-id>",
      "type": "catalog",
      "relation": "reference",
      "allowedActions": [
        "readResource"
      ]
    }
  ]
}

All identities that have access to the project and managers of the resource can unlink any resource from the project.

Now that we have seen how a resource can be linked to the destination project, let's unlink the resource from the destination project.

To unlink the resource from the project, use the project resources unlink command:

Example:

Linux
Windows
olp project resources unlink hrn:here:authorization::myrealm:project/<destination-project-id> \
   hrn:here:data:::<catalog-id>
olp project resources unlink hrn:here:authorization::myrealm:project/<destination-project-id> ^
   hrn:here:data:::<catalog-id>

The command displays the following results:


Resource hrn:here:data:::<catalog-id> 
 has been unlinked from project hrn:here:authorization::myrealm:project/<destination-project-id>.

We will now make the resource unavailable for linking.

To make a resource unavailable for linking to the destination project, use the resource link availability delete command:

Example:

Linux
Windows
olp resource link availability delete hrn:here:data:::<catalog-id> \
    --available-to hrn:here:authorization::myrealm:project/<destination-project-id> \
    --scope hrn:here:authorization::myrealm:project/<project-id>
olp resource link availability delete hrn:here:data:::<catalog-id> ^
    --actions readResource ^
    --available-to hrn:here:authorization::myrealm:project/<destination-project-id> ^
    --scope hrn:here:authorization::myrealm:project/<project-id>

The command displays the following results:


Resource hrn:here:data:::<catalog-id> 
 has been made unavailable for linking to the project hrn:here:authorization::myrealm:project/<destination-project-id>.

Delete the Destination Project

To delete the destination project, use the project delete command:

Example:


olp project delete hrn:here:authorization::myrealm:project/<destination-project-id>

The command displays the following results:


Project hrn:here:authorization::myrealm:project/<destination-project-id> has been deleted.

Delete the Second Catalog from the Project

To delete the project-scoped catalog, use the catalog delete command:

Example:

Linux
Windows
olp catalog delete hrn:here:data:::<catalog2-id> \
--scope hrn:here:authorization::myrealm:project/<project-id>
olp catalog delete hrn:here:data:::<catalog2-id> ^
--scope hrn:here:authorization::myrealm:project/<project-id>

The command displays the following results:


Catalog hrn:here:data:::<catalog2-id> has been removed.

Delete the Custom Policy

To delete the custom policy, use the project policy delete command:

Example:

Linux
Windows
olp project policy delete hrn:here:authorization::myrealm:project/<project-id> \
hrn:here:authorization::myrealm:project/<project-id>:policy/full-access-<catalog-id>-catalog
olp project policy delete hrn:here:authorization::myrealm:project/<project-id> ^
hrn:here:authorization::myrealm:project/<project-id>:policy/full-access-<catalog-id>-catalog

The command displays the following results:


Policy hrn:here:authorization::myrealm:project/<project-id>:policy/full-access-<catalog-id>-catalog has been deleted from project hrn:here:authorization::myrealm:project/<project-id>.

Delete a Catalog from a Project

To delete the project-scoped catalog, use the catalog delete command:

Example:

Linux
Windows
olp catalog delete hrn:here:data:::<catalog-id> \
    --scope hrn:here:authorization::myrealm:project/<project-id>
olp catalog delete hrn:here:data:::<catalog-id> ^
    --scope hrn:here:authorization::myrealm:project/<project-id>

The command displays the following results:


Catalog hrn:here:data:::<catalog-id> has been removed.

Delete a Project Pipeline

To delete the project-scoped pipeline, use the pipeline delete command:

Example:

Linux
Windows
olp pipeline delete <pipeline UUID> \
    --scope hrn:here:authorization::myrealm:project/<project-id>
olp pipeline delete <pipeline UUID> ^
    --scope hrn:here:authorization::myrealm:project/<project-id>

The command displays the following results:


Pipeline <pipeline UUID> has been deleted.

Remove the Application from the Project

To revoke the app's access to the project, use the project access revoke command:

Example:

Linux
Windows
olp project access revoke hrn:here:authorization::myrealm:project/<project-id> \
   --app <App ID>
olp project access revoke hrn:here:authorization::myrealm:project/<project-id> ^
   --app <App ID>

The command displays the following results:


App  has been revoked access to the project hrn:here:authorization::myrealm:project/<project-id>

Delete the Project

To delete the project, use the project delete command:

Example:


olp project delete hrn:here:authorization::myrealm:project/<project-id>

The command displays the following results:


Project hrn:here:authorization::myrealm:project/<project-id> has been deleted.

Note

Identities in this context refers to apps or users in the organization.

results matching ""

    No results matching ""