Support to expose disableInlining via Compile API

[srlk]

Hello!

Following up the discussion on open-policy-agent/community#121

What part of OPA would you like to see improved?

It would be nice to expose disableInlining option via Compile API. That would mean

• Complex functions can be implemented in REGO as now and they can be used for full evaluation
• For partial evaluation scenario, evaluation response would not inline the functions inside the packages specified by disableInlining option.
• Services calling partial evaluation may read/parse/generate predicates from support package based on the REGO implementation. Or they can decide to generate a service optimised query for functions inside the packages specified by disableInlining option.

Describe the ideal solution

disableInlining options is exposed via HTTP Compile API and command line as opa eval --disable-inlining

Additional Context

To explain with further details, for an example policy as below

# main.rego
package pkg

import data.func

allow {
    func.complex_func(input.unknownAttribute, input.knownAttribute)
}

# func.rego
package func

complex_func(collection1, collection2) {
    lhs := { x |
        x := collection1[_].value
        x.important
    }
    count(lhs) == 0
}

complex_func(collection1, collection2) {
    lhs := { x |
        x := collection1[_].value
        x.important
    }
    rhs := { x | x := collection2[_].value}
    count(lhs) == count(lhs & rhs)
}

With input

{
  "knownAttribute": [
    { "value": "a" }
  ]
}

Running partial evaluation via cli with the new flag --disable-inlining as below

 opa eval --partial -f source -d /.policy/func_test --unknowns input.unknownAttribute --input input.json --disable-inlining "data.func" "data.pkg.allow==true"

It would be expected to generate below partial evaluation output. One important thing to notice is that in the Query part of the response, function data.partial.func.complex_func is not inlined to conditions those make up the function.

# Query 1
data.partial.func.complex_func(input.unknownAttribute, [{"value": "a"}])

# Module 1
package partial.func

complex_func(__local0__2, __local1__2) {
        __local3__2 = {__local2__2 |
                __local2__2 = __local0__2[_].value
                __local2__2.important
        }

        count(__local3__2, __local10__2)
        __local10__2 = 0
}

complex_func(__local4__3, __local5__3) {
        __local7__3 = {__local6__3 |
                __local6__3 = __local4__3[_].value
                __local6__3.important
        }

        __local9__3 = {__local8__3 |
                __local8__3 = __local5__3[_].value
        }

        count(__local7__3, __local11__3)
        __local12__3 = __local7__3 & __local9__3
        count(__local12__3, __local13__3)
        __local11__3 = __local13__3
}

To expose this option via Compile API, we might have below options. But I am not very familiar with the code base and there could be a better way.

1. To pass the disableInlining option as a query parameter i.e. http://opa/v1/compile?disableInlining=data.func similar to how explain parameter is passed on

   opa/server/server.go

   Line 1209 in 268ab09

   explainMode := getExplain(r.URL.Query()[types.ParamExplainV1], types.ExplainOffV1)

2. The second option could be to enhance the partial evaluation request body with an additional field:

{
    "query": "data.pkg.allow == true",
    "options": {
        "disableInlining": ["data.func"]
    }
    "unknowns": [
        "input.resource.labels",
        "input.resource.id"
    ],
    "input": {
        "knownAttribute": [{
            "value": "a"
        }]
    }
}

opa/server/types/types.go

Line 351 in 268ab09

type CompileRequestV1 struct {

[srenatus]

👍 Adding options to CompileRequestV1 looks like a good idea. Thanks for digging into this!