# Kong 1.1.0rc2 available for testing **URL:** \ **Category:** General\ **Created:** [March 14, 2019, 3:56pm UTC](https://discuss.konghq.com/t/kong-1-1-0rc2-available-for-testing/3016 "2019-03-14T15:56:00Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![hisham](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/hisham/32/14_2.png) [@hisham](https://discuss.konghq.com/u/hisham)\ **Post date:** [March 14, 2019, 3:56pm UTC](https://discuss.konghq.com/t/kong-1-1-0rc2-available-for-testing/3016/1 "2019-03-14T15:56:00Z")
Hello again, Kong people! We are excited to announce the second release candidate for our next release, **Kong 1.1.0rc2**! This comes with a bunch of stability fixes based on the feedback we got from 1.1.0rc1, plus one extra goodie we sneaked in as it almost made it to rc1: **transparent proxying** mode! 📦[Download Kong 1.1.0rc2](https://bintray.com/kong) today — we are eager for feedback! ### What’s new since Kong 1.1.0rc1: 🎆 #### Improvements - **Transparent proxying** - the `service` attribute on Routes is now optional; a Route without an assigned Service will proxy transparently (#4286) #### Fixes - Core - Resolve hostnames in Cassandra contact points (#4378) - Fix health checks for Targets that need two-level DNS resolution (e.g. SRV → A → IP) (#4386) - Fix serialization of map types in the Cassandra backend (#4368) - Admin API - Fix Admin API inferencing of map types using form-encoded (#4368) - PDK - PDK version identifier was bumped to 1.1.0 - `kong.client.get_subsystem` was moved to `kong.nginx.get_subsystem` (#4358) - DB-less / Declarative config - fix the behavior of the `/tags` endpoint and `?tags=` query string from the Admin API when using `database=off` (#4380) - fix initial load of the declarative config file (#4342) - reloading the declarative config via `/config` refreshes the Upstream balancers (#4372) #### Dependencies - Bump OpenSSL to 1.1.0b - Bump lua-resty-dns-client to 3.0.2 ### And a recap of all the new stuff in the 1.1.0 series 🎆 - Kong can now run **without a database** , using in-memory storage only: - New option in `kong.conf`: `database=off` to start Kong without a database - New option in `kong.conf`: `declarative_config=kong.yml` to load a YAML file using Kong’s new [declarative config format](https://discuss.konghq.com/t/rfc-kong-native-declarative-config-format/2719) - New command: `kong config init` to generate a template `kong.yml` file to get you started - New command: `kong config parse kong.yml` to verify the syntax of the `kong.yml` file before using it - New Admin API endpoint: `/config` to replace the configuration of Kong entities entirely, replacing it with the contents of a new declarative config file - **Bulk database import** , using the same declarative configuration format as the in-memory mode - New command: `kong config db_import kong.yml` to upsert all entities specified in the `kong.yml` file in bulk - Support for **tags** in entities: - Every core entity now adds a `tags` field - Admin API endpoints now support searching by tag (for example, `/consumers?tags=example_tag`) - You can search by multiple tags: - `/services?tags=serv1,mobile` to search for services matching tags `serv1` and `mobile` - `/services?tags=serv1/serv2` to search for services matching tags `serv1` or `serv2` - New Admin API endpoint `/tags/` for listing entities by tag: `/tags/example_tag` - Improvements for **orchestration** scenarios: - The Kubernetes Sidecar Injection plugin is now bundled into Kong for a smoother K8s experience - New option `--wait` in `kong quit` to ease graceful termination when using orchestration tools - Improvements for **stream** handling: - The `stream_realip_module` is now bundled - The stream subsystem now supports Nginx directive injections - New PDK functions: `kong.client.get_protocol` (returning “http”, “https”, “tcp” or “tls”) and `kong.client.get_subsystem` (returning “http” or “stream”) - Support for ACL **authenticated groups** - Various bugfixes ### Quick start for using Kong without a database 1. To do a test run of Kong using database-less mode, start Kong as usual, adding the `KONG_DATABASE=off` environment variable (you can also set `database=off` in `kong.conf` instead if you want to make the changes permanent): ```bash $ export KONG_DATABASE=off $ kong start -c kong.conf ``` 1. You can generate an example `kong.yml` file in the current directory: ```bash $ kong config init -c kong.conf ``` 1. Edit the `kong.yml` and add entities there — the generated file has instructions. 2. Now you can load your declarative config using the `/config` endpoint and all entities in that file will be populated in Kong’s memory: ```bash $ http :8001/config config=@kong.yml ``` ### Upgrade Path ⬆ You can upgrade from 0.14.1 or any release in the 1.0 series (Note: upgrading from a pre-0.14 cluster is **not** supported). You can use a Blue/Green deployment method to update: “Blue” means your current version (0.14.1 or 1.0), “Green” means the new version 1.1.0rc2: 1. Download 1.1.0rc2, and configure it to point to the same datastore as your Blue cluster. Run `kong migrations up`. 2. Both Blue and Green nodes can now run simultaneously on the same datastore. Start provisioning 1.1.0rc2 nodes, but do not use their Admin API yet. Prefer making Admin API requests to your Blue cluster instead. 3. Gradually divert traffic away from your Blue nodes, and into your 1.1.0rc2 cluster. Monitor your traffic to make sure everything is going smoothly. 4. When your traffic is fully migrated to the Green 1.1.0rc2 cluster, decommission your Blue nodes. 5. From your 1.1.0rc2 cluster, run: `kong migrations finish`. From this point on, it will not be possible to start Blue 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.1.0rc2 nodes. ### Install 1.1.0rc2 on a fresh datastore ⬇ Since version 1.0, Kong uses a new, improved migrations framework. The following commands can be run to prepare a new 1.1 cluster from a fresh datastore: ```auto $ kong migrations bootstrap [-c kong.conf] $ kong start [-c kong.conf] ``` ### What’s next 🚀 Again, depending on the community feedback, we are going to either tag and release 1.1.0 final or make a new release candidate 1.1.0rc3. As always, consider yourself encouraged to reach out to us here or via [GitHub issues](https://github.com/Kong/kong/issues) if you have any questions or feedback about this release! Your feedback is essential to make Kong better! ---
**Author:** ![Daniel\_Liberman](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/daniel_liberman/32/809_2.png) [@Daniel\_Liberman](https://discuss.konghq.com/u/Daniel_Liberman)\ **Post date:** [March 20, 2019, 7:50pm UTC](https://discuss.konghq.com/t/kong-1-1-0rc2-available-for-testing/3016/2 "2019-03-20T19:50:50Z")
Hello there! We’re excited to try the new RC specially after fixes for DNS Balancer (for Healthchecks). Is there an ETA for official 1.1.0 to be released? Does it look like we’ll have 1.1.0 rc2 promoted or should we have a candidate 3? Thanks! ---
**Author:** ![thibaultcha](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/thibaultcha/32/340_2.png) [@thibaultcha](https://discuss.konghq.com/u/thibaultcha)\ **Post date:** [March 21, 2019, 3:29am UTC](https://discuss.konghq.com/t/kong-1-1-0rc2-available-for-testing/3016/3 "2019-03-21T03:29:53Z")
@Daniel_Liberman Hi, and welcome! So far, we are looking at promoting rc2 to being the formal 1.1.0 release by the end of this week or early next week, if nothing comes up. If you have some spare cycles, please go ahead and test it, and report issues (or lack of it!). Hearing feedback about our release candidates always increase our confidence in publishing formal releases 🙂 Cheers! ---
**Author:** ![jeremyjpj0916](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/jeremyjpj0916/32/1388_2.png) [@jeremyjpj0916](https://discuss.konghq.com/u/jeremyjpj0916)\ **Post date:** [March 21, 2019, 5:18am UTC](https://discuss.konghq.com/t/kong-1-1-0rc2-available-for-testing/3016/4 "2019-03-21T05:18:01Z")
I won’t be using the dbless config stuff personally but let me give 1.1.0 rc2 a go tomorrow in our dev just so I can help yah verify nothing was broken for existing db users in the process. I will need to diff the main handler and init files from some some custom bungle pr’s I leverage and bring them up to 1.1.0 rc2 speed(hopefully those files are not massive different at this point xD ). Still glad to see the dbless feature come out as I am sure it will help with adoption to teams that prefer a simpler architecture if anything else (less dependencies less problems I always say 🙂 ). ---
**Author:** ![hisham](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/hisham/32/14_2.png) [@hisham](https://discuss.konghq.com/u/hisham)\ **Post date:** [March 21, 2019, 2:31pm UTC](https://discuss.konghq.com/t/kong-1-1-0rc2-available-for-testing/3016/5 "2019-03-21T14:31:31Z")
@jeremyjpj0916 great to hear that, your feedback is always welcome! Looking forward to tag 1.1 final, lift the feature freeze in `next` and start working on merging @bungle’s PRs 🙂 ---
**Author:** ![mars](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/mars/32/491_2.png) [@mars](https://discuss.konghq.com/u/mars)\ **Post date:** [March 21, 2019, 5:52pm UTC](https://discuss.konghq.com/t/kong-1-1-0rc2-available-for-testing/3016/6 "2019-03-21T17:52:21Z")
1.1.0rc2 is looking good on Heroku ✅ > **[heroku/heroku-kong](https://github.com/heroku/heroku-kong/releases/tag/v8.0.0-rc2)** > > 🐒 Kong API gateway as a Heroku app. Contribute to heroku/heroku-kong development by creating an account on GitHub. ---
**Author:** ![jeremyjpj0916](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/jeremyjpj0916/32/1388_2.png) [@jeremyjpj0916](https://discuss.konghq.com/u/jeremyjpj0916)\ **Post date:** [March 22, 2019, 7:48am UTC](https://discuss.konghq.com/t/kong-1-1-0rc2-available-for-testing/3016/7 "2019-03-22T07:48:42Z")
4am here so getting late, can’t dig any further today but maybe something gets discovered/fixed in the migrations process around what I am seeing: [https://github.com/Kong/kong/issues/4420](https://github.com/Kong/kong/issues/4420) , am a man of my word though did try to test 1.1.0rc2 today 😆 , at first glance it seems like somehow a migration never occurred and fell through the cracks in kong’s major version 2 version upgrade and the commands today on 1.0.3 are not detecting that one chilling there non-null. As for @bungle patches on the kong/init.lua and the kong/runloop/handler.lua files there were big enough changes I did not try to patch his polling techniques for the plugins / router builds (that have provided me fantastic Kong stability on 1.0.3) into my 1.1.0rc2 testing, hopefully he gets a moment to bring those up to speed so yall can evaluate and consider if they belong in core Kong still 🙂 . ---
**Author:** ![thibaultcha](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/thibaultcha/32/340_2.png) [@thibaultcha](https://discuss.konghq.com/u/thibaultcha)\ **Post date:** [March 22, 2019, 5:57pm UTC](https://discuss.konghq.com/t/kong-1-1-0rc2-available-for-testing/3016/8 "2019-03-22T17:57:19Z")
@jeremyjpj0916 Thanks for the feedback! We are currently in the process of testing our migration upgrade paths between Kong 0.14 -\> 1.1 and 1.0 -\> 1.1, sorry for the delay, we may have let something slip through. Hopefully, we’ll be able to replicate this behavior in our upgrade test suite and fix it. As always, thanks for giving our release candidates a try, it really helps! ---
**Author:** ![jeremyjpj0916](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/jeremyjpj0916/32/1388_2.png) [@jeremyjpj0916](https://discuss.konghq.com/u/jeremyjpj0916)\ **Post date:** [March 22, 2019, 6:38pm UTC](https://discuss.konghq.com/t/kong-1-1-0rc2-available-for-testing/3016/9 "2019-03-22T18:38:35Z")
@thibaultcha awesome stuff, yeah seems like an edge case where maybe if you set KONG\_PLUGINS and don’t include bundled and hand pick your plugins(and leave some bundled plugins out that migrations might pop up for at some point) that potentially one of the “bundled” plugins migrations gets left unran in that table I referenced in the issue perhaps was my first thoughts. Let me know if I can offer any other outside help, every bug captured and squashed ='s a better application for all. -Jeremy