Release Date: June 4th, 2021
We are pleased to present Shipa 1.3.0 release.
This release brings several improvements and new functionalities related to the following components:
Users trying Shipa in an air-gapped environment can now use the NodePort service in addition to LoadBalancer.
Users can now determine which container registries can be used by developers when deploying their applications through framework policies.
Users can now implement network policies that are automatically applied to applications during deployment at the framework level.
Users are now able to load a config file to a deployed application through Shipa's dashboard.
Shipa CLI now exposes server and CLI versions.
Users can now define public plans that all teams can leverage.
Shipa architecture has been simplified on the monitoring side for faster install and lighter maintenance.
Shipa CLI now accepts a YAML file when binding or updating clusters to Shipa.
When deploying Shipa in a self-hosted environment, users can connect Shipa to their existing MongoDB instances for Shipa to leverage as a database.
A new framework creation workflow has been introduced to guide users through policy definitions better.
Users can now manage resource plans directly from the dashboard, in addition to the CLI management capabilities previously available.
SAML integration is now available so users can leverage their compatible SAML identity providers for authentication on Shipa.
Application deployed on a shipa node does not honor the port specified by the application.
Application deploy fails when using minimal Docker images.
Application creation fails when logged in as an org user at Shipa Cloud. The platform drop-down shows an empty list but it's a required field.
Use organization level while applying network policies.
Adding a user as a super admin to root org would give an error. Root org should have an unlimited user limit.
Shipa was treating emails as case-sensitive; therefore, a single user could register with the same email multiple times just by changing the uppercase/lowercase letters in the address. Then, users cannot log in if a cap letter is used in the wrong place
On the Shipa dashboard, when a new user is added, if the email already exists in shipa, it reports the error:
"There was an error creating a new user."
We now adjusted it to show a more detailed message:
This email is already registered
A user can't be deleted using Shipa's dashboard when the user's email has a character that needs URL encoding/escaping, e.g., [email protected]
The user can be added, but deletion fails. Removing such a user works fine using shipa CLI.
Force deleting a cluster was unstable.
Now, forcing the operation will make Shipa remove the cluster and all its related applications no matter their state. Therefore, the resources will be no longer listed when running 'shipa cluster list' or 'shipa app list'.
However, the actual applications running on the cluster and the cluster itself will not be touched.*
When trying to cancel a cluster add event would result in an error.
Docker image deployment to Azure AKS was not stable and would fail in certain scenarios.
Adding clusters from different providers would delete the Provider tag from previously added ones.
If a cluster was removed outside shipa, users were not able to remove it from shipa.
EKS cluster is shown as OTHER and wouldn't appear in geo distro map
Cluster addition using YAML didn't work as expected
Framework config update through CLI wouldn't work as expected.
Docker node was created without org metadata.