When we introduced support for newest SSH versions
for the user SSH keys used to deploy components, we deprecated the old ssh-dss
types. If users enter an unsupported or incorrect SSH the user interface now
displays an informative error message instead of simply disabling the ‘Save’ button.
This capability will provide an alternative to Git push deployment of user developed components and is of interest to enterprise clients wishing to condense entire integration flows into single custom components and maintain control at the docker level.
At this earliest stages we lay our groundwork by updating the component
commons
and api
to support components pull from external docker registries.
The following new attributes were added:
docker_registry
object into the HTTP POST
call to /v2/teams/
attributes.docker_registry.uri
- Docker Registry URIattributes.docker_registry.credentials
- Docker Registry credentialsdocker_repo_name
and docker_target_tag
in the POST
HTTP call to /v2/components
(can be set if its team has docker_registry
object)
attributes.docker_repo_name
- String representing component’s name in docker registry. Available only if team supports docker registryattributes.docker_target_tag
- String representing component’s tag in docker registry. Available only if team supports docker registryPlease note, as of this stage these attributes have no functionality attached to them.
We constantly improve different aspects of HELM3 deployments in collaboration with our partners. This section lists updates and improvements included in this release.
The flow execution statistics presented on the Dashboard Runlog are stored in the platform Mongo Database. This is in contrast to the flow execution threads, shown on the Executions pages, which are stored separately in Clickhouse.
When you access the Dashboard Runlog, the platform queries the MongoDB to get these records. These database calls can delay display of the runlog for users with many active flows. To enable users to manage such circumstances we have added an environment variable which defines the retention period of runlogs in the database.
Previously you could only control the retention period by enforcing the expireAfterSeconds
option in the Database index holding the execution records. In this release we
introduce a new TASK_STAT_START_INDEX_TTL
environment variable to the HELM3 charts,
which you can use to set retention suitable for your environment. It is mandatory
that a value is set for TASK_STAT_START_INDEX_TTL
and the
default value is set at 432000 seconds (5 days). Which means the platform
will store the Dashboard Runlog records for 5 days in the Database.
Setting the TASK_STAT_START_INDEX_TTL
environment variable to control the retention
period of the Dashboard Runlog is recommended for the new installations of the platform.
If your platform installation already has the retention period set in the Database prior to your installation of the platform 22.34 version then your environment variable will not be applied. If you need to change the value you must change the Database index setup prior to the deployment of the current release.
If you need to change the retention period of Dashboard runlogs in the future, remove
the expireAfterSeconds
option of the Database index containing the Dashboard Runlog records,
set the value of TASK_STAT_START_INDEX_TTL
environment variable and then deploy
the platform version again.
Our platform is now compatible with the Kubernetes version 1.22
. Check out the
new features enabled here.
You can now enforce MongoDB TLS verification in all platform services by using newly introduced HELM3 chart configurations:
.Values.global.secrets.mongodbTlsCertificateKey
- secret name with the TLS certificate and key. If specified, will be mounted to the services and specified in the tlsCertificateKeyFile
connection option..Values.global.secrets.mongodbTlsCA
- secret name with CA certificate to validate MongoDB server certificate on the client side. If specified, will be mounted to the services and specified in the tlsCAFile
connection option.Information in this section is intended for our customers who use the OEM version of the elastic.io platform.
Here we present further improvements to the recently introduced White-label credential management feature. Now you can use HTML inline frame or iFrame to embed the credentials.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Embedded Credentials Demo</title>
<style>html, body, iframe { height: 85%; width: 90%; margin: 0;}</style>
</head>
<body>
<iframe src="https://[eio_platform_domain]/embedded-credentials/[repoId]?workspaceId=[workspaceId]&ssoProviderType=[ssoProviderType]&ssoProviderId=[ssoProviderId]" />
</body>
</html>
The embed URL construction scheme is the same. Refer to the 22.20 release for details.
Pleass Note: End Users must enable pop-ups in their browser settings in order to use the embedded credential management.
POST
to /v2/workspaces/:id/secrets/:id/refresh
endpoint would return outdated access_token
instead of the newly refreshed value.1.0.0
Get New and Updated Objects
polling triggerMake Raw Request
actionUpsert Object
actionGenerate Custom Distribution Link
actionGetting Survey Responses
actionLookup Object (at most one)
action1.0.1
429
status code. Now it will retry the messages with an exponential backoff.5xx
errors. The messages will be retried with an exponential backoff as well.1.5.1
component-commons-library
to the version 3.0.1
1.1.6
email1
and email2
fields for metadata of Contacts module in the Upsert Action
elasticio-sailor-nodejs
to v2.6.29
1.0.0
Make Raw Request
Action1.2.5
maester-client
library version to 4.0.2
component-commons-library
to the version 3.0.1
2.0.0
OAuth 2.0
and migrated to the Secrets service2.6.29