A function shared between bundles should not generate an error, or documentation should explain that it will occur

[dsoguet]

Expected Behavior

Should be possible to share data, rules and functions between bundles, or at least explain that in case of function it could generate an error, or add a feature allowing to define in which order the bundles must be loaded

Actual Behavior

Currently:

• for data or rules shared between bundles, no error is generated at load, independently of bundles load order
• for functions shared between bundles, an error is generated during the load of a bundle A which uses a function coming from a bundle B, if A is loaded by OPA before B. If B is loaded before A then no error is raised

Into the documentation https://www.openpolicyagent.org/docs/v0.32.1/management-bundles/#bundle-file-format it is written

roots - If you expect to load additional data into OPA from outside the bundle (e.g., via OPA’s HTTP API) you should include a top-level roots field containing of path prefixes that declare the scope of the bundle. See the section below on managing data from multiple sources. If the roots field is not included in the manifest it defaults to [""] which means that ALL data and policy must come from the bundle.

Maybe the documentation should clarify the behavior for functions sharing

Ideally I would prefer code enhancement to have the same behavior for functions than for variables and rules. It would enable to create "lib" bundles of functions. Or at worst the possibility to define in which order the bundles must be loaded.

Steps to Reproduce the Problem

• OPA version : 0.31.0
• Following two bundles files and configuration file are necessary to reproduce the problem:
  • opa_bundle_lib.tar.gz
  • opa_main_project.tar.gz
  • config.txt

opa_bundle_lib.tar.gz contains:

• some data
• a function
• a rule

opa_main_project.tar.gz uses opa_bundle_lib.tar.gz:

• to create a rule based on opa_bundle_lib.tar.gz data
• to create a rule based on opa_bundle_lib.tar.gz function
• to create a rule based on opa_bundle_lib.tar.gz rule

config.txt (yaml not a file format supported by github...) is a configuration file to run a OPA server using the two bundles above

Steps to reproduce:

• Run following commands to prepare the test environment

mkdir -p ~/MyTest/bundle
mkdir -p ~/MyTest/conf
cd ~/MyTest

• Copy into ~/MyTest/bundle the two bundles file provided above
• Copy into ~/MyTest/conf the config.txt file provided above and rename it config.yaml
• Into another terminal run following command to simulate a bundle web server

cd ~/MyTest
python3 -m http.server 8080

• Into the initial terminal run several times (maybe around 20 times) following command

opa run --server --config-file conf/config.yaml

Sometimes:

• OPA will load the two bundles in one sequence (when opa_bundle_lib.tar.gz is loaded before opa_main_project.tar.gz)
• Sometimes OPA will need two loads of opa_main_project.tar.gz (when opa_main_project.tar.gz is loaded before opa_bundle_lib.tar.gz) and following error is displayed.

{"level":"error","msg":"Bundle activation failed: 1 error occurred: policies/myproject/main.rego:14: rego_type_error: undefined function data.mylib.isIntoList","name":"opa_example_policy","plugin":"bundle","time":"2021-09-30T15:55:31+02:00"}

Note that it will be necessary to wait between polling.min_delay_seconds and polling.max_delay_seconds before OPA tries to reload opa_main_project.tar.gz and finally obtain a working OPA server.

Additional Info

If you modify opa_main_project.tar.gz bundle to remove the line

call_function_test = f.isIntoList("1", {"1", "2"})

you will see that no error will be raised. The problem is only on functions

[anderseknert]

Thanks @dsoguet! See the discussions from yesterday for some more background open-policy-agent/community#20

[dsoguet]

Thank you @anderseknert, very interesting !

The idea about having two types of import, i.e. import at compile time (strict) vs import at runtime, sounds good for me :)
(and again variables, functions and rules should be managed in the same way :p)

May be a question about all those discussions is "It is classical with computer languages to have libraries/helper code. They enable to be more efficient for several reasons (reuse, robustness, tests,...). What is the solution proned by OPA to create such libraries/helper code ?"

[anderseknert]

Helper libraries are definitely encouraged, though they wouldn't necessarily be kept in separate bundles. The solution to this is to simply include all dependencies in a single bundle. This bundle could be composed from many other bundles, but the idea is to not rely on "runtime" dependencies to be eventually available.

IMHO, the way multi-bundles break in unexpected ways (as you have shown) makes me think they shouldn't be an option in the first place.

[anderseknert]

Also, see #3371 as I have a feeling this would solve the root cause of the issue at hand here.

[stale]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.