plugin is in use but not enabled

[ngourley]

Summary

I am developing a third party plugin, the problem is that when I start kong (using kong-vagrant) I get the message "plugin is in use but not enabled". If I hardcode the plugin in to custom_plugins in conf_loader.conf, it works no problem. If I set the value in a new config file called /etc/kong/kong.conf debugging shows that kong (kong start -c /etc/kong/kong.conf) essentially runs twice ( strange ) - once with a generated /usr/local/kong/kong.conf config file, and the other time with the my config file.

# log from kong start -c /etc/kong/kong.conf --vv
2016/12/09 23:07:53 [error] 3907#0: *2 [lua] conf_loader.lua:287: conf_loader(): /etc/kong/kong.conf, context: ngx.timer

# log from tailing /usr/local/kong/logs/error.log
2016/12/09 23:07:29 [error] 3886#0: [lua] conf_loader.lua:287: conf_loader(): /usr/local/kong/kong.conf

To be clear, if I add the plugin to the list of plugins in the constants file, it works. If I hardcode my plugin in to the custom_plugins list it works as well: https://github.com/Mashape/kong/blob/next/kong/conf_loader.lua#L369

Perhaps I should not be developing a plugin against the next branch? Or perhaps I am doing something wrong.

Steps To Reproduce

1. Create a new plugin, copy plugin to /kong/plugins/
2. Create /etc/kong/kong.conf with contents custom_plugins = <plugins-name>
3. Start kong

Additional Details & Logs

• Kong version ($ kong version)
• Kong debug-level startup logs ($ kong start --vv)
• Kong error logs (<KONG_PREFIX>/logs/error.log)
• Kong configuration (registered APIs/Plugins & configuration file)
• Operating System

[ngourley]

FYI - My temp workaround is hardcoding conf_loader.lua load path to use /etc/kong/kong.conf:

local function load(path, custom_conf)
  ------------------------
  -- Default configuration
  ------------------------
  path = '/etc/kong/kong.conf'

[thibaultcha]

Hi,

Please provide us with the Kong version you are using, as asked in the "Additional Details & Logs" section of the issue template.

A question for you: do you have a configuration file at one of the default paths (such as /etc/kong.conf or /etc/kong/kong.conf? Asking because of a known issue in recent versions, see #1681 and the linked issues.

[ngourley]

vagrant@precise64:/kong$ kong version
0.9.6

vagrant@precise64:/kong$ cat /etc/kong/kong.conf
custom_plugins = <plugin-name>

[ngourley]

vagrant@precise64:/kong$ git log | grep ac1f6f45c8e1171acf5d2adfdb61e9f8cdec55f4 -A 12
commit ac1f6f45c8e1171acf5d2adfdb61e9f8cdec55f4
Author: Thibault Charbonnier <thibaultcha@me.com>
Date:   Fri Sep 23 11:05:03 2016 -0700

    fix(cli) honor -c flag even if config exists at default location

    * fix a condition to prevent loading one of the default locations if a
    -c flag has been given
    * add a function to extend the default path, only used in tests
    * new test

    Fix #1675

[ngourley]

I believe this is related to #1817, its the same behavior. What I mean is that I can "add" my plugin using the api... then I would get an error when I restart.

To confirm, I checked out the 0.9.5 tag and no longer had the issue - instead I got some errors from differences in cache.get_or_set between 0.9.5 and 0.9.6. This is good to know at least.

[sje397]

It seems to be an issue related to rewriting the kong.conf file, when preparing the prefix folder. When the config is loaded, the custom_plugins value is converted to a map and merged with the constants.PLUGINS_AVAILABLE map, then added to the config as 'conf.plugins'. This value is then written out using table.concat - but the plugin names are the keys, not the values, in this table.

See lines 270-275 in cmd/utils/prefix_handler.lua

One solution would be to not remove the original value from the config on line 338 of conf_loader.lua.

[sje397]

@thibaultcha can you check the above?

[thibaultcha]

There was a fix written for this in #1910. The PR wasn't properly merged though so I don't think it is included in the recent 0.10rc1. I'll make sure to include it in a future release. Mind trying out the patch in the meanwhile?

[ngourley]

@thibaultcha I noticed that 0.9.8 had the change from #1910. I can confirm that it fixed the issue for my use case. I am good with this being close since it has been addressed.

[thibaultcha]

Good to know, thanks.