Skip to content
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

Merged
merged 8 commits into from
Feb 14, 2019
Merged

Standalone configuration #926

merged 8 commits into from
Feb 14, 2019

Conversation

mikz
Copy link
Contributor

@mikz mikz commented Oct 5, 2018

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.

@mikz mikz requested a review from a team as a code owner October 5, 2018 11:21
gateway/config/development.lua Show resolved Hide resolved
gateway/config/standalone.lua Outdated Show resolved Hide resolved
gateway/src/apicast/policy/standalone/configuration.lua Outdated Show resolved Hide resolved
gateway/src/apicast/cli/command/start.lua Outdated Show resolved Hide resolved
gateway/src/apicast/policy/standalone/configuration.lua Outdated Show resolved Hide resolved
@mikz mikz force-pushed the standalone-configuration branch from 0c98b8a to b7ab1e3 Compare November 30, 2018 08:42
gateway/config/standalone.lua Outdated Show resolved Hide resolved
gateway/src/apicast/cli/filesystem.lua Outdated Show resolved Hide resolved
gateway/src/apicast/cli/filesystem.lua Outdated Show resolved Hide resolved
gateway/src/apicast/cli/filesystem.lua Outdated Show resolved Hide resolved
@mikz mikz force-pushed the standalone-configuration branch 5 times, most recently from a98eaab to 55cca73 Compare December 5, 2018 14:12
@mikz mikz force-pushed the standalone-configuration branch 2 times, most recently from bf29e2e to 8c46a0f Compare February 6, 2019 12:18
@mikz mikz changed the title [wip] Standalone configuration Standalone configuration Feb 6, 2019
@mikz mikz changed the title [wip] Standalone configuration Standalone configuration Feb 6, 2019
@mikz mikz force-pushed the standalone-configuration branch from 8c46a0f to cea66a6 Compare February 6, 2019 15:04
local config, err = self:load_configuration(self)

if config then
-- TODO: we need to run this because some policies are "internal" and not being
Copy link
Contributor

@davidor davidor Feb 7, 2019

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.

Copy link
Contributor Author

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 by PolicyLoader and assume it was done by the Executor module

Wdyt?

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@davidor
Copy link
Contributor

davidor commented Feb 7, 2019

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.

@mikz mikz force-pushed the standalone-configuration branch 4 times, most recently from 3cdf672 to e988156 Compare February 13, 2019 11:22
@mikz mikz force-pushed the standalone-configuration branch from e988156 to ab6fb5e Compare February 13, 2019 12:33
@mikz mikz requested a review from davidor February 14, 2019 08:46
@mikz mikz merged commit 28b9159 into master Feb 14, 2019
@mikz mikz deleted the standalone-configuration branch February 14, 2019 11:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants