diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 00000000..e69de29b diff --git a/404.html b/404.html new file mode 100644 index 00000000..714c3ad0 --- /dev/null +++ b/404.html @@ -0,0 +1,1664 @@ + + + +
+ + + + + + + + + + + + + + +Puhuri Core exposes REST API for all of its operations. Below are examples of typical operations performed against APIs. +To run the examples, we are using a HTTPie.
+Almost all of the operations with API require an authentication token. Below we list two methods on how to get it.
+If your account is allowed to use username/password and the method is enabled (e.g. in dev environment), you can get a new token by submitting a username/password as JSON to a specific endpoint.
+ + +1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +30 +31 +32 |
|
You are also able to get token from the Puhuri Core web interface. +Select the user profile in the top-right corner and select Credentials +and then API token:
+ +Click on the 'eye' icon in the API token field to display the token. You can also select the token lifetime on this page.
+ + + + + + + + + + + + + + +Generic API usage
+All responses from Puhuri Core / Portal APIs are paginated. By default, 10 responses are returned.
+You can request more by passing page_size=XXX
as query attribute. XXX can go up to 200.
Pagination information is provided in Link headers.
+Check example of getting the full listing.
+In order to get a specific field from the response, you can use field=field_name
selector in the query parameters.
To list the created associations between users and resources, the service provider should use list_remote_offering_users
method. It receives an optional filters
argument, a dictionary containing filters for the associations. The possible items are:
user_uuid
- UUID of a user associated with resources belonging to SPoffering
- SP resource URLoffering_uuid
- UUID of a resourcecreated
- date after what the association was created; the format is YYYY-MM-DD
, e.g. 2022-01-30
modified
- date after what the association was modified; the format is the same as for the created
fieldIn case if SDK usage is not possible, HTTP request can be sent:
+1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 |
|
Example:
+1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +30 +31 +32 +33 +34 +35 +36 +37 +38 +39 +40 +41 +42 +43 +44 +45 +46 |
|
To get Puhuri Core User UUID mapping from Puhuri AAI CUID, service providers should pass CUID as a parameter to the endpoint below.
+1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 |
|
Example of error message if user information could not have been retrieved.
+1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 |
|
The calls to the mapping endpoint are only allowed to users with identity manager role!
+1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 |
|
User creates a role for a user in a project.
+1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +30 +31 +32 +33 +34 +35 +36 +37 +38 |
|
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +30 +31 +32 +33 +34 +35 +36 +37 +38 +39 +40 +41 +42 +43 +44 +45 +46 +47 +48 |
|
User can remove the permissions calling DELETE verb on permission's URL.
+1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +30 +31 +32 +33 |
|
In most cases integration user can see only one allocating organization (or Puhuri Core "customer"), however it is +possible that the same account is used for allocating different shares, e.g. national share and community specific. +Projects are always created in the context of a specific customer, so as a first thing you need to lookup a specific +customer you want to use. Customer is a stable entity, so it's URL / UUID can be cached.
+1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +30 +31 +32 +33 +34 +35 +36 +37 +38 +39 +40 +41 +42 +43 +44 +45 +46 +47 +48 +49 +50 +51 +52 +53 +54 +55 +56 +57 +58 +59 +60 +61 +62 +63 +64 +65 +66 +67 +68 +69 +70 |
|
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +30 +31 +32 +33 +34 +35 +36 +37 +38 +39 +40 +41 +42 +43 +44 +45 +46 +47 +48 +49 +50 +51 +52 +53 +54 +55 +56 +57 +58 +59 +60 |
|
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +30 +31 +32 +33 +34 +35 +36 +37 +38 +39 +40 +41 +42 +43 +44 +45 +46 +47 +48 +49 +50 +51 +52 +53 +54 +55 |
|
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18 + 19 + 20 + 21 + 22 + 23 + 24 + 25 + 26 + 27 + 28 + 29 + 30 + 31 + 32 + 33 + 34 + 35 + 36 + 37 + 38 + 39 + 40 + 41 + 42 + 43 + 44 + 45 + 46 + 47 + 48 + 49 + 50 + 51 + 52 + 53 + 54 + 55 + 56 + 57 + 58 + 59 + 60 + 61 + 62 + 63 + 64 + 65 + 66 + 67 + 68 + 69 + 70 + 71 + 72 + 73 + 74 + 75 + 76 + 77 + 78 + 79 + 80 + 81 + 82 + 83 + 84 + 85 + 86 + 87 + 88 + 89 + 90 + 91 + 92 + 93 + 94 + 95 + 96 + 97 + 98 + 99 +100 +101 +102 +103 +104 +105 +106 +107 +108 +109 +110 +111 +112 +113 +114 +115 +116 +117 +118 +119 +120 +121 +122 +123 +124 +125 +126 +127 +128 +129 +130 +131 +132 +133 +134 +135 +136 +137 +138 +139 +140 +141 +142 +143 +144 +145 +146 +147 +148 +149 +150 +151 +152 +153 +154 +155 +156 +157 +158 +159 +160 +161 +162 +163 +164 +165 +166 +167 +168 +169 +170 +171 +172 +173 +174 +175 +176 +177 +178 +179 +180 +181 +182 +183 +184 +185 +186 +187 +188 +189 +190 +191 +192 +193 +194 +195 +196 +197 +198 +199 +200 +201 +202 +203 +204 +205 +206 +207 +208 +209 +210 +211 +212 +213 +214 +215 +216 +217 +218 +219 +220 +221 +222 +223 +224 +225 +226 +227 +228 +229 +230 +231 +232 +233 +234 +235 +236 +237 +238 +239 +240 +241 +242 +243 +244 |
|
User can fetch offerings and filter them by the following fields:
+name
- offering's namename_exact
- offering's exact namecustomer
- organization's URLcustomer_uuid
- organization's UUIDallowed_customer_uuid
- allowed organization's UUIDservice_manager_uuid
- service manager's UUIDattributes
- a set of attributes (key-value pairs) identifying the allocation. Check below for LUMI specific attributes.state
- offering's state (Active
, Draft
, Paused
, Archived
), should be Active
category_uuid
- category's UUIDbillable
- signalizing if an offering is billable or not, should be true
shared
- signalizing if an offering is public or not, should be true
type
- offering's type1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18 + 19 + 20 + 21 + 22 + 23 + 24 + 25 + 26 + 27 + 28 + 29 + 30 + 31 + 32 + 33 + 34 + 35 + 36 + 37 + 38 + 39 + 40 + 41 + 42 + 43 + 44 + 45 + 46 + 47 + 48 + 49 + 50 + 51 + 52 + 53 + 54 + 55 + 56 + 57 + 58 + 59 + 60 + 61 + 62 + 63 + 64 + 65 + 66 + 67 + 68 + 69 + 70 + 71 + 72 + 73 + 74 + 75 + 76 + 77 + 78 + 79 + 80 + 81 + 82 + 83 + 84 + 85 + 86 + 87 + 88 + 89 + 90 + 91 + 92 + 93 + 94 + 95 + 96 + 97 + 98 + 99 +100 +101 +102 +103 +104 +105 +106 +107 +108 +109 +110 +111 +112 +113 +114 +115 +116 +117 +118 +119 +120 +121 +122 +123 +124 +125 +126 +127 +128 +129 +130 +131 +132 +133 +134 +135 +136 +137 +138 +139 +140 +141 +142 +143 +144 +145 +146 +147 +148 +149 +150 +151 +152 +153 +154 +155 |
|
User can create an order providing requested allocation parameters.
+project
- project's UUIDoffering
- respectful offering's URLattributes
- specific attributes for the offeringplan
- plan's URL (if offering is billable)limits
- a set of resource limits for an allocation1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18 + 19 + 20 + 21 + 22 + 23 + 24 + 25 + 26 + 27 + 28 + 29 + 30 + 31 + 32 + 33 + 34 + 35 + 36 + 37 + 38 + 39 + 40 + 41 + 42 + 43 + 44 + 45 + 46 + 47 + 48 + 49 + 50 + 51 + 52 + 53 + 54 + 55 + 56 + 57 + 58 + 59 + 60 + 61 + 62 + 63 + 64 + 65 + 66 + 67 + 68 + 69 + 70 + 71 + 72 + 73 + 74 + 75 + 76 + 77 + 78 + 79 + 80 + 81 + 82 + 83 + 84 + 85 + 86 + 87 + 88 + 89 + 90 + 91 + 92 + 93 + 94 + 95 + 96 + 97 + 98 + 99 +100 +101 +102 +103 +104 +105 +106 +107 +108 +109 +110 +111 +112 +113 +114 +115 +116 +117 +118 +119 +120 +121 +122 +123 +124 +125 +126 +127 +128 +129 +130 |
|
If a token belongs to a staff user, the order can be approved automatically. +Otherwise, there is additional need for manual approval.
+After that, order should be pulled until resource UUID is present (marketplace_resource_uuid
field).
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +30 +31 +32 +33 +34 +35 +36 +37 +38 +39 +40 +41 +42 +43 +44 +45 +46 +47 +48 +49 +50 +51 +52 +53 +54 +55 +56 +57 +58 +59 +60 +61 +62 +63 +64 +65 +66 +67 +68 +69 +70 +71 +72 +73 +74 +75 +76 +77 +78 +79 +80 +81 +82 +83 +84 +85 +86 +87 +88 +89 +90 +91 +92 +93 +94 |
|
In order to approve order by consumer, you shall issue POST request against /api/marketplace-orders/{UUID}/approve_by_consumer/
endpoint. Similarly in order to approve order by provider, you shall issue POST request against /api/marketplace-orders/{UUID}/approve_by_provider/
endpoint. Otherwise, you shall issue POST request against /api/marketplace-orders/{UUID}/reject_by_consumer/
or /api/marketplace-orders/{UUID}/reject_by_provider/
endpoint.
Of course, these endpoints are available only if you have service provider or service consumer permission against corresponding offerings.
+1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +30 +31 +32 +33 +34 +35 +36 +37 +38 +39 |
|
As an RA, you can update options of an allocations. Update happens through a special endpoint on a resource. +Check below for LUMI specific attributes.
+1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +30 +31 +32 +33 +34 +35 +36 +37 +38 +39 +40 +41 +42 +43 +44 +45 +46 +47 +48 +49 +50 +51 +52 +53 +54 |
|
Termination uses a special short-cut action /terminate
and returns UUID of a generated order.
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +30 +31 +32 +33 +34 |
|
LUMI has agreed on the following schema for the resource options. The attributes can be passed during creation of +the resource or by updating existing resources.
+is_industry
, possible values: true/false; true if the PI or a member of a project is from a company;is_training
, possible values: true/false; true if aimed at training of the users;used_ai_tech
, (AI methods used in the calculations), choices:is_commercial
, possible values: true/false; true if aimed at commercial usage (commercial projects are pay-per-use industrial projects).This page describes operations to be performed by service provider.
+Please, read initial setup for Puhuri Core SDK and +please reach out to support email to get credentials for Puhuri Core.
+list_users
method is used to fetch all users in Puhuri Core.
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +30 +31 +32 +33 |
|
list_ssh_keys
method is used to fetch all SSH keys in Puhuri Core.
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 |
|
list_marketplace_resources
method is used to fetch resources related to offerings, which belong to user's service provider.
Possible filter options for allocations (each one is optional):
+provider_uuid
- UUID of a service provider organization;state
- current state of a resource allocation; valid values: Creating
, OK
, Erred
, Updating
, Terminating
, Terminated
;offering_uuid
- UUID of a related resource;fields
- list of fields to return.1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 |
|
The service provider can either approve or reject order using
+marketplace_order_approve_by_provider
and marketplace_order_reject_by_provider
correspondingly.
+Both of these methods expect as its only argument UUID of an order for the allocation.
For example, a consumer requested an allocation using Order
with CREATE
type. After that, an empty allocation with CREATING
state has appeared.
+A service provider can change the state to ok
(created successfully) using marketplace_order_approve_by_provider
or
+rejected
(creation rejected) using marketplace_order_reject_by_provider
.
+In order to get a proper order, SP owner can use list_orders
method. This action is for order listing and supports filtering by state and allocation.
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 |
|
A consumer can also cancel created order and subsequently interrupt the requested operation over allocation.
+For example, this option is suitable if the customer wants to cancel allocation deletion.
+For this, marketplace_order_cancel
method should be used.
+It changes the state of the order to canceled
.
+NB: this transition is possible only if the order's state is equal to pending-consumer
or pending-provider
and offering type is basic or support.
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 |
|
backend_id
field)Each allocation can have a link to a service provider's internal reference using backend_id
field. Only users with service provider owner and manager roles can set this value using marketplace_resource_set_backend_id
method of the client. It requires the following arguments:
resource_uuid
- UUID of a resource allocation;backend_id
- id of an external entity.1 +2 +3 +4 +5 +6 +7 +8 |
|
In case if SDK usage is not possible, HTTP request can be sent:
+1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 |
|
For additional details related to allocation access, report
field is used.
+In order to provide this information, owners and managers can use marketplace_resource_submit_report
method. It requires the following arguments:
resource_uuid
- UUID of a resource allocation;report
- list of ResourceReportRecord
instances.1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 |
|
Service provider owners and managers can list project members using a resource allocation with marketplace_resource_get_team
method.
+It requires the following arguments:
resource_uuid
- UUID of a resource allocation.1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 |
|
A usage of a resource allocation can be submitted by a corresponding service provider. +For this, the following methods are used:
+get_marketplace_offering
- getting offering with components info. Arguments:
offering_uuid
- UUID of an offeringmarketplace_resource_get_plan_periods
- getting current plan periods for resource allocation. Arguments:
resource_uuid
- UUID of a resourcecreate_component_usages
- creating or updating components usage for the current plan. Arguments:
usages
- list of ComponentUsage
instancesresource
- UUID of a resource1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +30 +31 +32 +33 +34 +35 +36 |
|
An access to a resource can be granted by service provider for a particular user with specification of username.
+A result is represented by triplet [user, resource, username].
+For this purpose, create_remote_offering_user
should be invoked. This method requires the following arguments:
offering
- UUID or URL of a target offering;user
- UUID or URL of a target user;username
- username for the user.1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 |
|
In case if SDK usage is not possible, HTTP request can be sent:
+1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 |
|
A service provider can grant access mentioned in the previous section to all resources used in projects including a target user.
+For such access creation or update, set_offerings_username
is used.
+The method requires the following arguments:
1 +2 +3 +4 +5 +6 +7 +8 +9 |
|
A user can get service provider details
+using list_service_providers
with corresponding filter.
+This method is guaranteed to return a list with at most one service provider record.
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 |
|
A service provider owner can list users currently using its resources.
+For this, list_service_provider_users
should be used. It accepts service_provider_uuid,
+which can be fetched using list_service_providers.
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 |
|
A service provider owner can list ssh keys of users currently using its resources.
+For this, list_service_provider_ssh_keys
should be used. It accepts service_provider_uuid,
+which can be fetched using list_service_providers.
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 |
|
A service provider owner can list all projects, which have its resources.
+For this, list_service_provider_projects
should be used. It accepts service_provider_uuid,
+which can be fetched using list_service_providers.
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 |
|
A service provider owner can also list all active projects permissions in projects, which have its resources.
+For this, list_service_provider_project_permissions
should be used. It accepts service_provider_uuid,
+which can be fetched using list_service_providers.
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 |
|
Puhuri Core is based on Waldur, which exposes REST API. Puhuri Core SDK is a python wrapper for typical REST operations.
+It is packaged as a Python module and published in PyPI, so you can install it with standard tools like:
+1 |
|
In order to perform operations, a user needs to create an instance of WaldurClient
class:
1 +2 +3 |
|
This instance provides interface for further interaction with Puhuri Core and will be used across examples in related documentation.
+If the client fails to perform an operation, it raises WaldurClientException
. This can be handles using try...except
block.
+Example:
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 |
|
In December 2023 a change affecting order management API will be released. The exact date will be announced once +integrations with service providers are validated.
+marketplace_order_approve_by_provider
, marketplace_order_reject_by_provider
list_order_items
/marketplace-orders/order_uuid/approve_by_consumer/
/marketplace-orders/order_uuid/reject_by_provider/
This page introduces the Puhuri components and high level architecture.
+The diagram above shows a high level architecture of Puhuri. Puhuri links together Users with strong digital identity +with Resources in a seamless way.
+Puhuri is using MyAccessID AAI for user registration that can be started from National Portal of Resource Allocators +or from Puhuri Portal, which is provided as a reference solution. The registration process creates a unique identifier +(Community Unique Identifier, CUID) for the user, which is used for referencing and linking user identity across the +different components.
+The identity provider releases the attributes about User’s identity and affiliation, which is important for the +resource providers to know. User can also register SSH public keys for easier access to the Linux-based systems that +are accessible in Puhuri.
+Puhuri Core is an API service for Resource Allocators that allows to manage Projects, Members (using CUID of Puhuri users) +as well as Resource Allocations. A Resource provider (in Figure above - LUMI) then imports the allocation and project +membership information from the Puhuri Core and sets up the services for access using MyAccessID user account. Resource +provider also reports on the usage of resource allocations as well as provides additional data, like Linux usernames, that +user might need in order to access the Resource.
+Puhuri Core has an offline access to MyAccessID user registry and uses it for keeping user information up to date.
+Puhuri believes in transparency and sharing, as such all of the technical components we rely upon are open-source.
+User applies for a Resource Allocation and then manage the Members of the Project using a Puhuri Portal, hosted by University of Tartu, or via a National Portal, depending which solution is available for User.
+The Resource application review process happens outside of Puhuri. The national portals are expected to push approved projects and resources to Puhuri Core. The Principal Investigator (PI) creates project in the Puhuri Portal or National Portal. The submission is then accepted by the Resource Allocator, which is responsible for the particular application’s resource granting. Then the project information is propagated to Puhuri Core and from there synchronised to the Resource Provider. In addition to Project description and members, also the Resource-specific resource allocation attributes are included.
+A national portal may implement identity linking of local accounts with Puhuri AAI account. The recommended way for that is to use OIDC registration flow, which can be triggered from the national portal and lead to redirection back with a created Puhuri User CUID
+Information model of Puhuri. Please note that the terminology used in this documentation differs occasionally of this planned information model.
+ + + + + + + + + + + + + +