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

feat(fault-injection): support conditional fault injection using nginx variables #3363

Merged
merged 8 commits into from
Jan 25, 2021

Conversation

Firstsawyou
Copy link
Contributor

@Firstsawyou Firstsawyou commented Jan 20, 2021

What this PR does / why we need it:

We can add new features to the fault-injection plugin for the following reasons:
Currently, the fault-injection plugin does not support custom conditions to implement the mock function. I think we can add the request header as a conditional judgment in the request (there may be a better way) to realize the mock function.
E.g:

"vars": [
     [[ "http_mock01", "==", " api01" ]],
     [[ "http_mock02", "==", " api02" ]]
]

If vars passes the verification, fault injection is performed on the request. Otherwise, no processing is done on the request. In order to maintain backward compatibility, the fault injection operation is still performed when the vars condition is not configured.

close #2511

Pre-submission checklist:

  • Did you explain what problem does this PR solve? Or what new features have been added?
  • Have you added corresponding test cases?
  • Have you modified the corresponding document?
  • Is this PR backward compatible? If it is not backward compatible, please discuss on the mailing list first

@membphis
Copy link
Member

ci failed

@Firstsawyou
Copy link
Contributor Author

ci failed

I need to adjust the code logic and I will solve the ci problem later.

@Firstsawyou Firstsawyou marked this pull request as ready for review January 23, 2021 12:28

local plugin_name = "fault-injection"


local vars_schema = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to remove the vars_schema.

  1. we can do the check better with expr.new when checking the schema.
  2. when not/or is supported directly in the expr, this schema is outdated.
  3. this schema contains many incorrect hardcoded limitations, like the maxLength of operator is 2 (not enough for has), and an expression may contain 4 elements if ! is used, etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, you don't remove it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think just keep:

local vars_schema = {
    type = "array",
    maxItems = 20
}

is enough. The remain can be validated via expr.new.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, let me try it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated.

for _, var in ipairs(vars) do
local expr, err = expr.new(var)
if err then
core.log.error("vars expression does not match: ", err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be failed to create vars expression, we haven't matched it yet.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated.

doc/plugins/fault-injection.md Outdated Show resolved Hide resolved
doc/plugins/fault-injection.md Outdated Show resolved Hide resolved
doc/plugins/fault-injection.md Outdated Show resolved Hide resolved
doc/plugins/fault-injection.md Outdated Show resolved Hide resolved
apisix/plugins/fault-injection.lua Outdated Show resolved Hide resolved
apisix/plugins/fault-injection.lua Outdated Show resolved Hide resolved
return match_result, nil
end


function _M.check_schema(conf)
local ok, err = core.schema.check(schema, conf)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better to check the expression here and add a test for it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I mean checking the expression via:

        local expr, err = expr.new(var)
        if err then
            core.log.error("failed to create vars expression: ", err)
            return nil, err
        end

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added.

@membphis membphis merged commit fb9123d into apache:master Jan 25, 2021
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.

[discuss]: use fault-injection plugin to implement mock function
3 participants