Kong 1.0rc2 available for testing

thibaultcha · October 23, 2018, 8:59pm

Hi everyone,

We are happy to have made progress in our release candidate cycle for Kong 1.0, and announce the availability of RC2!

Download Kong 1.0.0rc2 today and give us your feedback!

This second release candidate contains numerous improvements and bug fixes reported or contributed by the community, but also allows for migrations from a 0.14 cluster, which was one of the limitations of RC1. We thus hope to receive even more feedback from you about this release candidate!

What’s new in RC2

RC2 contains the following improvements over RC1:

Support for upgrading 0.14 nodes to 1.0.0rc2
Support for OpenSSL 1.1.1 (bundled by default)
Support for HTTPS active healthchecks
Significant runloop performance improvements
New pg_timeout configuration option to configure a PostgreSQL timeout value
Various bug fixes and usability improvements
Plugins:
- All bundled plugins have been updated to use the Plugin Development Kit and new Admin API endpoint semantics (first introduced with /services and /routes in 0.14)
- AWS Lambda: Support for Lambda Proxy Integration
- Various performance improvements and bug fixes

You can browse the complete list of changes for this release on GitHub. Additionally, Kong 1.0rc2 contains all changes introduced by 1.0rc1, and listed here.

Upgrade Path from 0.14

We have made sure that the following upgrade path from 0.14 is supported, including “cold” nodes (Note: upgrading from a pre-0.14 cluster is not supported):

Download 1.0rc2, and configure it to point to the same datastore as your 0.14 cluster. Run kong migrations up.
Both 0.14 and 1.0rc2 nodes can now run simultaneously on the same datastore. Start provisioning 1.0rc2 nodes, but do not use their Admin API yet. Prefer making Admin API requests to your 0.14 nodes instead.
Gradually divert traffic away from your 0.14 nodes, and into your 1.0rc2 cluster. Monitor your traffic to make sure everything is going smoothly.
When your traffic is fully migrated to the 1.0rc2 cluster, decommission your 0.14 nodes.
From your 1.0rc2 cluster, run: kong migrations finish. From this point on, it will not be possible to start 0.14 nodes pointing to the same datastore anymore. Only run this command when you are confident that your migration was successful. From now on, you can safely make Admin API requests to your 1.0rc2 nodes.

Install 1.0rc2 on a fresh datastore

1.0 introduces a new, improved migrations framework. The following commands can be run to prepare a new 1.0 cluster from a fresh datastore:

$ kong migrations bootstrap [-c config]
$ kong start [-c config]

What’s next

Our next release candidate, 1.0RC3, will include the necessary capabilities to deploy Kong as a Service Mesh. Stay tuned for more updates!

As always, feel free to reach out to us here or via GitHub issues if you have any questions or feedback about this upgrade path, or the contents of this release in general! We appreciate the feedback we receive from our release candidates testers and thank them in advance!

jeremyjpj0916 · October 23, 2018, 9:42pm

Great! Looking forward to testing out rc2 on our dev cluster!

Any reason for the change from naming in kong migrations up to kong migrations bootstrap going forward? My only concern about trying the “kong migrations finish” is once our pod is deployed and live, the user we get access to via OpenShift terminal has crazy reduced rights, but if that CLI command just does some final DB changes and not local file system modifications we should be good.

Any documentation out yet for how to take a Kong plugin that runs on 0.14.x and preparing it to be compatible with Kong 1.0? Does 1.0 have backwards compatibility with plugins? I know the schema.lua format will change going forward but would be great if existing plugins could run on 1.0 too while we work towards giving them the revamped schema and such . Our plugins I don’t think use any of the deprecated resources from 0.14.x(Thinking like API resources) .

-Jeremy

thibaultcha · October 24, 2018, 5:56pm

Any reason for the change from naming in kong migrations up to kong migrations bootstrap

The new migrations provide those 3 commands: bootstrap, up, and finish (along with list and reset). The first two are separate commands because they achieve separate things (bootstrapping the database from scratch, or upgrading an existing database). Separating them makes the process more obvious to users so they can realize if the underlying database is fresh or not, and can hopefully prevent some mistakes.

More info on the new migrations here for now, until we write the documentation for it:

github.com/Kong/kong

feat(db) new migrations framework

Kong:next ← Kong:feat/new-migrations

opened 11:02PM - 24 Sep 18 UTC

thibaultcha

+4137 -331

Implements a new migrations framework with several goals in mind. Among the impr…ovements in this new framework: - First and foremost, support for the new DAO (`kong.db` module). - Ability to run migrations concurrently from any number of nodes, thanks to leader-election through the [cluster_mutex()](https://github.com/Kong/kong/pull/3685) utility. - Ability to implement 2 step migrations (non-breaking, then destructive steps). This allows for smoother upgrades between major versions, as it grants a period of time for a database schema to be compatible with both running versions (e.g. "blue" and "green"). Currently, "translation functions" are implemented as a PoC, but the nature of 1.0 (non breaking) does not require us to complete this work at the current time. Locking writes to tables has also been discussed and is NYI as well. - PostgreSQL migrations are executed within transactions. - Scaling up and down the Cassandra cluster at runtime does not prevent starting new Kong nodes anymore. - Made Cassandra migrations more resilient and re-entrant in case of unexpected failures/retries. - Implemented a `kong migrations list` command. This command also returns separate exit codes for various states, allowing for better script-ability. - Ability to customize database timeouts for migrations with CLI arguments. - Improved CLI logging during migrations. - Migrations do not expose the underlying DAO anymore, but only the connector object, therefore, avoiding issues related to schema validations in migrations. - Migrations are consolidated (squashed) into a single one for each subsystem, as per the state of the schema in 0.14. #### Subsequent work In a subsequent PR, the following additions should be contributed: - A migration from 0.14 (and the old migrations framework) to the new framework. - Any missing migrations that was contributed between the release of 0.14 and the present day, in the `next` branch. Additionally, documentation will be updated with the new CLI commands and new recommended upgrade path. #### New workflow: Starting a fresh node: ``` $ kong migrations bootstrap $ kong start ``` Listing the state of the schema and its migrations: ``` $ kong migrations list ... ``` Upgrading from a previous version: ``` $ kong migrations up # Start new nodes nodes $ kong start # Decommission previous version nodes # Finish pending migrations $ kong migrations finish ``` Or: ``` # Run migrations *and* start new nodes once done; # can be called from any number of nodes $ kong start --run-migrations # Decommission previous version nodes # Finish pending migrations $ kong migrations finish ```

Does 1.0 have backwards compatibility with plugins?

Some level of backwards-compatibility, but not entirely. Since 1.0 introduces the new DAO for database access, plugins using singletons.dao will need to be updated to use kong.db (although 1.0rc2 still has the old DAO for now). We might be able to provide a translation layer between a plugin’s current schema.lua table and the new schema library of 1.0. Again, for now, 1.0rc2 still has both.
Otherwise, all code written for pre 1.0 does not have to be updated, low-level OpenResty APIs are still available. Plugin authors may update their code to use the PDK for reasons highlighted here (standardization, usability, isolation, forward-compatibility).

thibaultcha · October 25, 2018, 6:00pm

Kong 1.0rc2 is now available on Docker Hub!

https://hub.docker.com/_/kong/

mars · November 15, 2018, 7:45pm

I just released this release candidate for the Heroku Kong app.

Try Kong 1.0rc2 on Heroku

Topic		Replies	Views
Kong 1.1.0rc2 available for testing Announcements	8	1158	March 22, 2019
Kong 1.0 (rc1) available for download Announcements	3	1628	September 28, 2018
Kong 1.2.0rc2 available for testing! Announcements	0	931	May 31, 2019
Kong 1.2.0rc1 available for testing! Announcements	3	1148	May 29, 2019
Kong 1.0 (rc3) available for testing Announcements	5	1957	November 27, 2018

Kong 1.0rc2 available for testing

What’s new in RC2

Upgrade Path from 0.14

Install 1.0rc2 on a fresh datastore

What’s next

Related Topics