TykTechnologies / tyk

Tyk Open Source API Gateway written in Go, supporting REST, GraphQL, TCP and gRPC protocols
Other
9.73k stars 1.09k forks source link

policies.policy_path vs policies.policy_record_name #5485

Closed jakub-bochenski closed 1 year ago

jakub-bochenski commented 1 year ago

Those 2 settings seem to cover the same thing. I've been using the policies.policy_record_name successfully.

What is the other setting supposed to do?

policies.policy_record_name

EV: TYK_GW_POLICIES_POLICYRECORDNAME Type: string

This option is required if policies.policy_source is set to file. Specifies the path of your JSON file containing the available policies.

policies.policy_path

EV: TYK_GW_POLICIES_POLICYPATH Type: string

This option is used for storing a policies if policies.policy_source is set to file. it should be some existing file path on hard drive

Another mystery is why the official helm chart is setting TYK_GW_POLICIES_POLICYPATH to be a directory and not a file

          - name: TYK_GW_POLICIES_POLICYPATH
            value: "/mnt/tyk-gateway/policies"

When TYK_GW_POLICIES_POLICYPATH is set to point to a directory Tyk loads a single unnamed empty policy.

zalbiraw commented 1 year ago

Hello @jakub-bochenski,

There is a slight difference between the options.

If you use the TYK_GW_POLICIES_POLICYPATH option then you are asking the gateway to load a list of policies from a directory. This also allows you to manage those policies via the gateway REST API. That is why the operator uses it.

The TYK_GW_POLICIES_POLICYRECORDNAME will allow you to specify a single file that contains all your policy definitions and will only be used if the TYK_GW_POLICIES_POLICYPATH is empty.

Here is the code reference. I hope this answer helps :)

jakub-bochenski commented 1 year ago

Well then the docs quotde above are wrong. I now know the difference but maybe you would want to update them?

it should be some existing file path on hard drive

zalbiraw commented 1 year ago

I will put in a PR shortly and link it here :) Thank you @jakub-bochenski!