Understanding OPA Bundle Document

[Ronnie-personal]

Hi,

I'm reading https://www.openpolicyagent.org/docs/latest/management-bundles/#multiple-sources-of-policy-and-data, would like to understand more about the implications of using multiple bundles in one OPA configuration.

Why we prefer single bundle over multiple bundles?

Thanks!

[charlieegan3]

Hi Ronnie, using a single bundle might be operationally simpler. You have a single file to test and deploy.

Using multiple bundles comes in handy if you need to version different parts of the policy and data at different rates. For example, data often changes a lot faster than policy and so you might want to have that come from a different bundle.

If you're starting out I'd suggest using a single bundle to get going and then evolve from there where you see pain points.

[Ronnie-personal]

@charlieegan3

Thank you so much for the prompt reply.

Do you recommend using multiple services? Do you see any issue with following example configurtion?

services:

• name: acmecorp
  url: https://example.com/service/v1
  credentials:
  bearer:
  token: "abc123"
• name: anotherone
  url: https://secondsite.com/service/v1
  credentials:
  bearer:
  token: "xyz"

bundles:
bundle1:
service: acmecorp
resource: somedir/bundle1.tar.gz
bundle2:
service: acmecorp
resource: somedir/bundle2.tar.gz
bundle3:
service: anotherone
resource: somedir/bundle3.tar.gz

[anderseknert]

There are a few reasons to why a single bundle is recommended over using multiple ones, but the main one is IMHO that multiple bundles moves potential problems from "build time" to runtime, and in almost all cases, you'll want to know about problems as early as possible. For example — if there is conflicting data between bundle1 and bundle2, OPA will reject loading bundle2, as it should — but I'd much rather know about that in my build pipeline than I would from reading logs from an OPA running in production. There are obviously other things you can do to try and prevent this, but having your policy defined in a single place, tested and deployed as a single unit... avoids a whole bunch of potential problems, and is IMHO a better developer experience.

[Ronnie-personal]

I got your point!

[Ronnie-personal]

In case we need to use multiple bundles for whatever reason, do you recommend using one bundle service or multiple bundle services? Are there any implications for using multiple bundle services?

[charlieegan3]

Not really. It just depends on where your policy and data come from. Multiple services gives users the option of having them come from different places if they need to. If you can have them all come from the same service, that might be simpler to deploy and manage.

[Ronnie-personal]

Are you aware of any bundle server which supports long polling? S3, Azure storage & nginx?

[anderseknert]

I believe long-polling is going to require a custom server implementation, as it would need to know what specifically would be the trigger to stop the polling (i.e. a bundle update). It's possible that there exists web servers who will recognize long-polling and trigger on a change of file, or may be configured to act like that... but I don't know.

[Ronnie-personal]

Thank you! When I have chance to test, I will report back.

[Ronnie-personal]

Can you please help me to understand the configuration for the long polling? It only requires one setting, 'bundles[_].polling.long_polling_timeout_seconds'?

[anderseknert]

Yes, and that the server responds with a special Content-Type header. So custom implementation needed.
See https://www.openpolicyagent.org/docs/latest/management-bundles/#http-long-polling