-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Standalone configuration #926
Conversation
0c98b8a
to
b7ab1e3
Compare
a98eaab
to
55cca73
Compare
bf29e2e
to
8c46a0f
Compare
8c46a0f
to
cea66a6
Compare
local config, err = self:load_configuration(self) | ||
|
||
if config then | ||
-- TODO: we need to run this because some policies are "internal" and not being |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we had a similar problem in Executor
and figured out a way to run every phase only once.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was a bit different problem I think.
Executor does the following:
- call
:init
and initialize all policies in the current chain - use
PolicyLoader:get_all()
to load "all" policies - call
:init
on the remaining policies
Now PolicyLoader:get_all()
does not return all the policies. Some don't have apicast-policy.json
file, so they are not discovered.
So the problem is that the Executor is going to call the :init
phase on all policies that it can find but does not expose the information if the phase was already executed. So standalone can't really know if it was already executed or not.
There are two options I see:
- expose information about what phase was executed on what policy in the Executor
- standalone policy should not trigger
:init
on policies that can be found byPolicyLoader
and assume it was done by the Executor module
Wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer the first one because I think it's more explicit, but I think that both options should be OK.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So after some digging, I realised the problem is a bit deeper.
Executor keeps track of what it executed, but it can't keep track of what nested policy chains executed. Let's say Executor has 3 policies and the 2nd is itself a policy chain with 3 more policies. The Executor would be aware only of the first level.
We would have to figure out how to collect all policies from the executor without calling them.
Maybe I'd rather postpone this until we get more information and see more places where it breaks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I didn't think about the nested chains scenario.
OK to postpone it 👍 No need to solve this for a first version.
I agree with the approach taken 👍 My comments are just about minor things. I also think that we need more unit and integration tests. As you mentioned in your original comment, this is just a first version, so no need to fix everything now. |
Offer an interator for just request phases skipping the init and init_worker.
3cdf672
to
e988156
Compare
e988156
to
ab6fb5e
Compare
Fixes #795
Implements "standalone" configuration, that does not depend on 3scale and can be human-authored YAML document describing internal services and routing between them.
Please note this is just first version and it will be refined as we start using it more.