Released: 2019-10-30
You can now manage Recipe visibility with the new
API endpoint PATCH v2/:recipe_id/visibility
. This action is only available to
users with proper permissions, and can be applied to components visible to them.
Also, you can now use Recipe details page (replace variables with corresponding data):
app.elastic.io/c/:contract_id#/w/:workspace_id/recipes/:recipe_id
Recipe descriptions support markdown syntax, except for check-boxes. Images for the page are hosted by Recipe author.
Another page for Recipes UI is Recipe activation page (replace variables with corresponding data):
app.elastic.io/c/:contract_id#/w/:workspace_id/recipes/:recipe_id/activate
It contains Recipe variables fields and Component sections listed with Credentials. Here you can choose existing Credentials, create new or edit existing ones during Recipe activation. Some data will require manual configuration: Credentials, Fields, Flow Variables.
You can find the corresponding API doc here. POST v2/recipes
and PATCH v2/recipes/:id
do not have attributes.visibility
anymore. Instead, new Recipes are created with the default visibility set for the Workspace. See more details here.
Changing Recipe visibility requires certain permissions, depending on visibility level: Workspace, Contract, Tenant, Global.
You can now see monthly quota history and quota usage of a Contract on the corresponding page:
See details on quota history here.
You can now manage Snapshots via the API.
API endpoints for Snapshots:
GET /v2/flows/$flowId/snapshots
GET /v2/flows/$flowId/snapshots/$stepId
POST /v2/flows/$flowId/snapshots/
PATCH /v2/flows/$flowId/snapshosts/$stepId
DELETE /v2/flows/$flowId/snapshots/$stepId
You can find the corresponding API docs here.
Also, we have added reference by ID in Component metadata JSON Schema.
As for JSON Schema reference by ID:
{
“definitions”: {
“address”: {
“$id”: “#address”,
“type”: “object”,
“properties”: {
“street_address”: { “type”: “string” },
“city”: { “type”: “string” },
“state”: { “type”: “string” }
},
“required”: [“street_address”, “city”, “state”]
}
},
“type”: “object”,
“properties”: {
“billing_address”: { “$ref”: “#address” },
“shipping_address”: { “$ref”: “#address” }
}
}
Another IMPORTANT thing - Docker Registry service doesn’t run under the root user any more and requires migration. Please note that this is crucial, and without migration the Platform will fail.
The migration has to be run AFTER deploying the release, where the docker-registry
is being run as non-root. If the old version of the docker-registry
(with root)
was run, just to deploy the new version, remove the old migration job and run the
migration again.
The official registry (registry:2.7.1
or mirror elasticio/registry:2.7.1
)
is being run as a root
, elasticio/registry:2.7.1-non-root
is being run as
docker
. Our migration contains an update of ownership of files according to
changed user (root
->docker
), and is implemented as kubernetes job (i.e. it
has to be run only once).
Specify the YOUR_CONTEXT
below and execute:
cat << EOM | kubectl create --context YOUR_CONTEXT --namespace platform -f -
{
"apiVersion": "batch/v1",
"kind": "Job",
"metadata": {
"labels": {
"app": "docker-registry-migration-for-non-root"
},
"name": "docker-registry-migration-for-non-root",
"namespace": "platform"
},
"spec": {
"backoffLimit": 0,
"completions": 1,
"parallelism": 1,
"template": {
"metadata": {
"labels": {
"app": "docker-registry-migration-for-non-root",
"job-name": "docker-registry-migration-for-non-root"
},
"name": "docker-registry-migration-for-non-root"
},
"spec": {
"containers": [
{
"command": [
"sh",
"-c",
"chown -R docker:docker /var/lib/registry"
],
"image": "elasticio/registry:2.7.1-non-root",
"imagePullPolicy": "Always",
"name": "docker-registry-migration-for-non-root",
"securityContext": {
"runAsUser": 0
},
"terminationMessagePath": "/dev/termination-log",
"terminationMessagePolicy": "File",
"volumeMounts": [
{
"mountPath": "/var/lib/registry",
"name": "docker-storage",
"subPath": "docker"
}
]
}
],
"dnsPolicy": "ClusterFirst",
"imagePullSecrets": [
{
"name": "elasticiodevops"
}
],
"nodeSelector": {
"elasticio-role": "platform"
},
"restartPolicy": "Never",
"schedulerName": "default-scheduler",
"volumes": [
{
"name": "docker-storage",
"persistentVolumeClaim": {
"claimName": "platform-storage-slugs-volume-claim"
}
}
]
}
}
}
}
EOM
To check the success, create new build and publish it:
shell
kubectl --context YOUR_CONTEXT --namespace platform exec -it docker-registry-INSERT_CERTAIN_POD_POSTFIX -- sh -c "ls -la /var/lib/registry"
It must contain docker docker
:
drwxr-xr-x 3 docker docker 4096 Aug 7 19:01 .
drwxr-xr-x 1 root root 4096 Oct 4 15:18 ..
drwxr-xr-x 3 docker docker 4096 Aug 7 19:01 docker
GET Flows-Versions
and CRUD
with Flow draft are now available only to Workspace members.Includes
Lookup Objects
Execute custom query
Transaction Lock
error has been addedGet Rows Polling
Trigger has better datetime
field type supportError: write after end
message had been thrown in Write CSV attachment
action in runtime in some casesReleased : 2019-11-21
You can now download execution logs to a file by clicking the corresponding button for:
Also, you can now see the Workspace quota usage information per Flow. On this page a user comes from the Contract quota details page by clicking on one of the workspaces:
Includes
Lookup Object (at most 1)
Delete Object
Set tiered prices
Upsert customer/company
Create object
Delete Object
Lookup Object (at most 1)
Upsert object
Get New and Updated Objects
Webhook subscription
Released : 2019-12-19
NOTE: From this release we have adopted new release numbering format based on year and week of the release -
YY.WW
.YY
are the last two digits of the year, andWW
is the number of the week in that year. Following this template, our current release is19.51
.
You can now retry failed messages using the new feature called Retry. Any error emitted by a component can be retried if the flow is active. Error or success entry appears in the current Runlog execution. Feature details can be found here:
Also, now you can filter mapping view to see mandatory fields and hide optional fields:
You can now disable the passthrough for a selected flow step using an API call to the following endpoint:
PATCH /v2/flows/:id
NOTE When the passthrough is disabled for a step, the platform would reset all the data from the previous steps and start again collecting the data from the steps from that step only.
This feature is available via an API call only and here is the schema of the passthrough toggling request body:
{
"data": {
"type": "flow",
"id": "5de7d63a944b750013fb3f09",
"attributes": {
"nodes_config": {
"step_2": {
"passthrough": {
"disabled": true
}
}
}
}
}
}
Now you can configure the order of fields in component.json
using the new numeric key order
for:
For more details read the component descriptor ordering fields document.
Additionally, custom scripts for individual tenants can run on every page before authorization:
links.documentation
and tenant.links
in the tenant description body are no longer supported.Includes
Delete Object
Lookup Objects
Get New And Updated Objects Polling Trigger
for Material
entity type.Component failed to start
Error shown during flow run.The component has been refactored and created from scratch in an OIH-compatible way. The following actions/triggers have been introduced:
Delete File
Lookup File (At most 1) By Filename
Download files
Upload File From URL
Get new and updated files polling
Key-based auth
mechanismUpload files
-> Upload files From Attachments Header
Lookup file by name
-> Download file by name
Get new and updated files
-> Poll files
Get new and updated
trigger beforeThe component has been fully reworked and refactored. So it’s become more effective and reliable.
Rename File
A new component which can be used to convert from different tables that parsed as a CSV.