Kong 1.0rc2 available for testing

Announcements
#1

Hi everyone,

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

:package: 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 :fireworks:

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 :arrow_up:

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):

  1. Download 1.0rc2, and configure it to point to the same datastore as your 0.14 cluster. Run kong migrations up.
  2. 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.
  3. 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.
  4. When your traffic is fully migrated to the 1.0rc2 cluster, decommission your 0.14 nodes.
  5. 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 :arrow_down:

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 :rocket:

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!

7 Likes
Kong 1.0 (rc3) available for testing
#2
#3

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 :slight_smile: . Our plugins I don’t think use any of the deprecated resources from 0.14.x(Thinking like API resources) .

-Jeremy

1 Like
#4

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:

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).

2 Likes
#5

Kong 1.0rc2 is now available on Docker Hub!

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

:whale:

2 Likes
Kong 1.0 (rc4) available for testing
Kong 1.0 is now Generally Available! (1.0.0 released)
#6

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

:egg: Try Kong 1.0rc2 on Heroku

2 Likes