Properties renaming

[thibaultcha]

0.5.0 was decided to introduce many breaking changes because we want to correct a few mistakes made along the way. So far, it will introduce those breaking changes:

• Plugins migrations ([feat/migrations] split plugins migrations #443) introducing heavy database migration
• Plugins renaming (Plugins renaming #480) introducing heavy database migration + configuration file changes

The database migration is taken care of by the migration script written for the occasion, but the configuration file changes will need to be done manually by users. Everything is explained in UPDATE.yml.

First, it would really help if all those (code, script and documentation) were reviewed since this will be a very important steps for users. @thefosk @Tieske @ahmadnassri

---

The question now is that we had decided on more things to rename, should we do it now or not?

• The hosts property in the configuration file to contact_points, as generally used for Cassandra clusters.
• An API's public_dns to inbound_dns.
• An API's path to inbound_path.
• An API's strip_path to strip_inboud_path.
• An API's target_url property to upstream_url or outbound_url.
• plugins_configurations (the table and name of the entity itself (in docs etc) to plugins (even those they are indeed configurations of the said plugins.

Please consider each of them individually, and wether or not it is worth renaming it. Some are easy, some will require heavy work on the migration script. The thing is now is a really good time to proceed to those changes to avoid having other painful updates for users in the future.

@thefosk @Tieske @ahmadnassri

[sonicaghi]

contact_points
inbound_dns
upstream_url
plugins

[thibaultcha]

Also in plugins_configurations (or plugins now), renaming value to config seems like a priority. All those updates will require huge work on the documentation, yet alone the code itself and the migration script.

[sonicaghi]

better sooner rather than later.

[thibaultcha]

What about inboud_host instead of inboud_dns? Since we are talking about the Host header with this resolver?

[sonicaghi]

most of the users get confused only on dns and target url. i would prioritize those.

[thibaultcha]

Yeah hence why I suggest inboud_host instead of inboud_dns, but I'm not sure about it. Would like some other opinions.

[sonicaghi]

not sure. good to have other point of view. @ahmadnassri @Tieske @thefosk

[subnetmarco]

+1 for inbound_dns and upstream_url

All of this changes will delay 0.5.0 - but as @thibaultcha we have to do them sooner or later, so let's do them now.

All those updates will require huge work on the documentation

Massive changes indeed.

[thibaultcha]

So far all those updated have been done in the code and documented in CHANGELOG.md and UPDATE.md in #518. The update instructions allow users to migrate and update to 0.5.0 without downtime. Developers (@thefosk @Tieske) will have to run a few commands as describe in the PR.

Reviews and testing is highly appreciated, especially the migration script but also the state of Kong once migrated.

A typical use case would be:

• Kong in 0.4.2 with a some APIs and a few plugins that were renamed (eg: rate-limiting + key-auth)
• Follow the UPDATE.yml instructions, making sure there is no downtime between steps
• Run Kong in 0.5.0 and make sure it has the same behaviour as 0.4.2

The only work left is udpating the website now (and drop the support for the old rate-limiting schema @thefosk).