GuidesChangelogData Inspector Library API Reference
Guides
  1. Command Line Interface
  2. OLP CLI Workflows

Project workflows

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:
    1. Create and list a project template:
  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 olp 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::org: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 olp catalog create command and specify the catalog ID, name, summary, description, and project scope:

Example:

olp catalog create <catalog-id> scoped-catalog-name \
    --summary "A new scoped catalog" \
    --description "A new scoped catalog" \
    --scope hrn:here:authorization::org: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::org: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::org:<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 olp catalog list command:

Example:

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

The command displays the following results:

hrn:here:data::org:<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 olp pipeline create command and specify the pipeline ID, name, description, and project scope:

Example:

olp pipeline create <pipeline-name> \
   --description "This pipeline analyzes data" \
   --scope hrn:here:authorization::org:project/<project-id>
olp pipeline create <pipeline-name> ^
   --description "This pipeline analyzes data" ^
   --scope hrn:here:authorization::org: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 olp pipeline list command:

Example:

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

The command displays the following results:

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

Use olp pipeline show <pipeline ID> to display more information about a pipeline

Note that the --scope <project HRN> parameter is also applicable to all olp pipeline template and olp 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 olp pipeline 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:

olp pipeline template create <name> <runtime environment> <JAR file> \
   <class name> 
    --scope <project HRN> 
    --input-catalog-ids catalogExample1 [command options]
olp pipeline template create <name> <runtime environment> <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 olp pipeline template list command:

Example:

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

The command displays the following results:

name                    ID                      description
<template-name>         <template UUID>                         

Use olp pipeline template show <template ID> to display more information about a pipeline template

Add an app to the project

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

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

Example:

olp project access grant hrn:here:authorization::org:project/<project-id> \
   --app <App ID>
olp project access grant hrn:here:authorization::org: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::org: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 olp project access list command:

Example:

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

The command displays the following results:

type           HRN                                        ID            name
app            hrn:here:account::org:app/<App ID>         <App ID>      My App

Use olp project access show <project HRN> to display more information about the access details of an identity in a project

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 olp project policy list command with --type here-platform parameter:

Example:

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

The command displays the following results:

HRN                                                                                            type
hrn:here:authorization::org:platform:policy/artifacts-read-all                                 here-platform
hrn:here:authorization::org:platform:policy/schemas-read-and-modify-all                        here-platform
hrn:here:authorization::org:platform:policy/all-access-all-project-resources                   here-platform
hrn:here:authorization::org:platform:policy/catalogs-read-and-write-and-manage-all             here-platform
hrn:here:authorization::org:platform:policy/catalogs-read-and-write-all                        here-platform
hrn:here:authorization::org:platform:policy/schemas-read-all                                   here-platform
hrn:here:authorization::org:platform:policy/resource-creation-access-all-project-resources     here-platform
hrn:here:authorization::org:platform:policy/pipelines-all-access                               here-platform
hrn:here:authorization::org:platform:policy/artifacts-read-and-modify-all                      here-platform
hrn:here:authorization::org:platform:policy/pipeline-templates-all-access                      here-platform
hrn:here:authorization::org: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::org:project/<project-id> \
hrn:here:authorization::org: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::org: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 and access to create all project resources in the project. HERE platform attaches all-access-all-project-resources and resource-creation-access-all-project-resources policies 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::org:project/<project-id> \
--app <app id>

The command displays the following results:

HRN                                                                                            type
hrn:here:authorization::org:platform:policy/all-access-all-project-resources                   here-platform
hrn:here:authorization::org:platform:policy/resource-creation-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 olp project access grant command:

Example:

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

Output:

Application <App ID> has been granted access to the project hrn:here:authorization::org:project/<project-id> with attached policy hrn:here:authorization::org: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::org:project/<project-id> \
--app <app id>

The command displays the following results:

HRN                                                               type
hrn:here:authorization::org: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:

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

The command displays the following results:

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

ID                       <catalog-id>
name                     scoped-catalog-name
HRN                      hrn:here:data::org:<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

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

olp catalog update hrn:here:data::org:<catalog-id> \
--description "Updated description" \
--scope hrn:here:authorization::org:project/<project-id> \
--credentials path/to/credentials.properties
olp catalog update hrn:here:data::org:<catalog-id> ^
--description "Updated description" ^
--scope hrn:here:authorization::org: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 olp catalog create command and specify the catalog ID, name, summary, description, and project scope:

olp catalog create <catalog2-id> scoped-catalog2-name \
--summary "Second scoped catalog" \
--description "Second scoped catalog" \
--scope hrn:here:authorization::org:project/<project-id>
olp catalog create <catalog2-id> scoped-catalog2-name ^
--summary "Second scoped catalog" ^
--description "Second scoped catalog" ^
--scope hrn:here:authorization::org: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::org:<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.

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

The command displays the following results:

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

ID                       <catalog-id>
name                     scoped-catalog-name
HRN                      hrn:here:data::org:<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
olp catalog show hrn:here:data::org:<catalog2-id> \
--scope hrn:here:authorization::org:project/<project-id>
--credentials path/to/credentials.properties
olp catalog show hrn:here:data::org:<catalog2-id> ^
--scope hrn:here:authorization::org:project/<project-id>
--credentials path/to/credentials.properties

The command displays the following results:

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

ID                       <catalog2-id>
name                     scoped-catalog2-name
HRN                      hrn:here:data::org:<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

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 olp 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::org:<catalog-id>",
      "allowedActions": [
        "readResource",
        "manageResource",
        "writeResource"
      ]
    }
  ]
}

Save the config file as config.json.

To create the custom policy, execute the following command:

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

Output:

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

Note

This command allows you to construct policies without validation to check if the resources you’re including in the policy already exist in the project. This allows you to construct policies in advance of resource creation, which may be useful for some CI/CD flows. However, it also allows you to construct policies that include resources that are not accessible in the project, for example, resources that are in another project and have not been shared and linked to the project for which you are creating policies. When such a policy is applied to a project member, they still will not have access to such resources contained in the policy.

List custom policies

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

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

The command displays the following results:

HRN                                                                                          type
hrn:here:authorization::org: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 olp project access grant command:

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

Output:

Application <App ID> has been granted access to the project hrn:here:authorization::org: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:

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

The command displays the following results:

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

ID                       <catalog-id>
name                     scoped-catalog-name
HRN                      hrn:here:data::org:<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

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

catalog show hrn:here:data::org:<catalog2-id> \
--scope hrn:here:authorization::org:project/<project-id>
--credentials path/to/credentials.properties
catalog show hrn:here:data::org:<catalog2-id> ^
--scope hrn:here:authorization::org: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.

Update a custom policy

Once you have the custom policy created, you can also update it to add or remove resources, or change permissions to resources.

As an example of a policy update, we are going to change access to the catalog with the <catalog-id> ID, so that it is read-only, and we are going to add full access to the catalog with the <catalog2-id> ID. Let's create the following configuration file:

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

Save the config file as config.json.

The configuration file contains a policy providing read access to the catalog with the <catalog-id> ID and full access to the catalog with the <catalog2-id> ID. Full access includes readResource, writeResource and writeResource actions.

To update the custom policy, execute the olp project policy update command:

olp project policy update hrn:here:authorization::org:project/<project-id> \
hrn:here:authorization::org:project/<project-id>:policy/full-access-<catalog-id>-catalog
--config path/to/config.json
olp project policy update hrn:here:authorization::org:project/<project-id> ^
hrn:here:authorization::org:project/<project-id>:policy/full-access-<catalog-id>-catalog
--config path/to/config.json

The above command provides read access to the catalog with the <catalog-id> ID and full access to the catalog with the <catalog2-id> ID and outputs the following result:

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

As a result, the app, to which this policy is applied, now has access to the second catalog we didn't have access to before. Also, the app's access permissions on the catalog already linked to the policy have changed.

Validate access to the resources based on the updated custom policy

Now that the policy has been updated, the application has access to the resources within the project as per the updated policy. In this case, the custom policy we have updated above allows access to both catalogs with read access to the catalog with the <catalog-id> ID and full access to the catalog with the <catalog2-id> ID. Let's execute the below commands to show that we now have access to the catalog with the <catalog2-id> ID, as well as only read access to the catalog with the <catalog-id> ID.

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

The command displays the following results, demonstrating we still have read access to the first catalog after updating the policy:

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

ID                       <catalog-id>
name                     scoped-catalog-name
HRN                      hrn:here:data::org:<catalog-id>
summary                  First scoped catalog
description              First 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

Let's execute the below command to make sure we are no longer allowed to update the catalog with the <catalog-id> ID to which we have the read permission. To update the catalog, execute the olp catalog update command:

olp catalog update hrn:here:data::org:<catalog-id> \
--summary "Updated summary"
--description "Updated description"
--scope hrn:here:authorization::org:project/<project-id>
--credentials path/to/credentials.properties
olp catalog update hrn:here:data::org:<catalog-id> ^
--summary "Updated summary"
--description "Updated description"
--scope hrn:here:authorization::org: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, the application is now restricted to access the above catalog.

Let's execute the below command to make sure we are now allowed to update the catalog with the <catalog2-id> ID to which we have full access:

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

The command displays the following results, demonstrating we were able to update the second catalog with the permissions granted in the policy update:

Catalog hrn:here:data::org:<catalog2-id> has been updated

Detach a custom policy

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

Example:

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

Output:

Application <App ID> has been revoked access to the policy hrn:here:authorization::org: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 olp 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::org:project/<destination-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 olp 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.

Make a project resource available to be linked

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 olp resource link availability create command:

Example:

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

The command displays the following results:

{
     "resource": "hrn:here:data::org:<catalog-id>",
     "allowedActions": [
         "readResource"
     ],
     "projectHrn": "hrn:here:authorization::org: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 olp resource link availability show command:

Example:

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

The command displays the following results:

{
     "resource": "hrn:here:data::org:<catalog-id>",
     "allowedActions": ["readResource"],
     "projectHrn": "hrn:here:authorization::org: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 olp resource link availability list command:

Example:

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

The command displays the following results:

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

List resources available to be linked to project

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 olp project resource availability list command:

Example:

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

The command displays the following results:

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

Link a resource to a project

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 olp project resource link command:

Example:

olp project resource link hrn:here:authorization::org:project/<destination-project-id> \
   hrn:here:data::org:<catalog-id> \
   --actions readResource writeResource --json
olp project resource link hrn:here:authorization::org:project/<destination-project-id> ^
   hrn:here:data::org:<catalog-id> ^
   --actions readResource writeResource --json

The command displays the following results:

{
  "resource": "hrn:here:data::org:<catalog-id>",
  "project": "hrn:here:authorization::org: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 olp project resource list command:

Example:

olp project resource list hrn:here:authorization::org:project/<destination-project-id> --json

The command displays the following results:

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

Unlink a resource from a project

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 olp project resource unlink command:

Example:

olp project resource unlink hrn:here:authorization::org:project/<destination-project-id> \
   hrn:here:data::org:<catalog-id>
olp project resource unlink hrn:here:authorization::org:project/<destination-project-id> ^
   hrn:here:data::org:<catalog-id>

The command displays the following results:

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

Make a project resource unavailable to link

We will now make the resource unavailable for linking.

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

Example:

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

The command displays the following results:

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

Delete the destination project

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

Example:

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

The command displays the following results:

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

Delete the second catalog from the project

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

Example:

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

The command displays the following results:

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

Delete the custom policy

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

Example:

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

The command displays the following results:

Policy hrn:here:authorization::org: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 olp catalog delete command:

Example:

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

The command displays the following results:

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

Delete a project pipeline

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

Example:

olp pipeline delete <pipeline UUID> \
    --scope hrn:here:authorization::org:project/<project-id>
olp pipeline delete <pipeline UUID> ^
    --scope hrn:here:authorization::org: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 olp project access revoke command:

Example:

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

The command displays the following results:

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

Delete the project

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

Example:

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

The command displays the following results:

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

Note

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

For more information, see Manage projects.

Updated 21 days ago