Hi! I'm trying to run the example docker-compose f...
# opal
m
Hi! I'm trying to run the example docker-compose file "docker-compose-api-policy-source-example.yml" with default settings, but it fails to start the opal-server container as stated in the logs below. It worked with v0.9.9-rc.1 but since 0.9.9-rc.2 it doesn't work. Trace is from opal-server container v0.10.0-rc.1:
Copy code
<date_time> | 17 | opal_common.sources.api_policy_source   |ERROR  | Failed to load initial policy from remote API bundle server
Traceback (most recent call last):
  File "/usr/local/bin/gunicorn", line 33, in <module>
    sys.exit(load_entry_point('gunicorn==26.2.0', 'console_scripts', 'gunicorn')())
  File "/usr/local/lib/python3.10/site-packages/gunicorn/app/wsgiapp.py", line 66, in run
    WSGIApplication("%(prog)s [OPTIONS] [APP_MODULE]", prog=prog).run()
  File "/usr/local/lib/python3.10/site-packages/gunicorn/app/base.py", line 235, in run
    super().run()
  File "/usr/local/lib/python3.10/site-packages/gunicorn/app/base.py", line 71, in run
    Arbiter(self).run()
  File "/usr/local/lib/python3.10/site-packages/gunicorn/arbiter.py", line 248, in run
    self.manage_workers()
  File "/usr/local/lib/python3.10/site-packages/gunicorn/arbiter.py", line 701, in manage_workers
    self.spawn_workers()
  File "/usr/local/lib/python3.10/site-packages/gunicorn/arbiter.py", line 788, in spawn_workers
    self.spawn_worker()
  File "/usr/local/lib/python3.10/site-packages/gunicorn/arbiter.py", line 753, in spawn_worker
    worker.init_process()
  File "/usr/local/lib/python3.10/site-packages/gunicorn/workers/base.py", line 145, in init_process
    self.run()
  File "/usr/local/lib/python3.10/site-packages/uvicorn/workers.py", line 104, in run
    return asyncio_run(self._serve(), loop_factory=self.config.get_loop_factory())
  File "/usr/local/lib/python3.10/site-packages/uvicorn/_compat.py", line 60, in asyncio_run
    return loop.run_until_complete(main)
  File "/usr/local/lib/python3.10/site-packages/opal_common-0.0.0-py3.10.egg/opal_common/sources/base_policy_source.py", line 54, in run
    await self.get_initial_policy_state_from_remote()
> File "/usr/local/lib/python3.10/site-packages/opal_common-0.0.0-py3.10.egg/opal_common/sources/api_policy_source.py", line 88, in get_initial_policy_state_from_remote
    self.local_git = self.tar_to_git.create_local_git()
  File "/usr/local/lib/python3.10/site-packages/opal_common-0.0.0-py3.10.egg/opal_common/git_utils/tar_file_to_local_git_extractor.py", line 56, in create_local_git
    local_git = self.commit_local_git(should_init=True)
  File "/usr/local/lib/python3.10/site-packages/opal_common-0.0.0-py3.10.egg/opal_common/git_utils/tar_file_to_local_git_extractor.py", line 46, in commit_local_git
    local_git.index.add(self.policy_bundle_git_add_pattern)
  File "/usr/local/lib/python3.10/site-packages/git/index/base.py", line 925, in add
    paths, entries = self._preprocess_add_items(items)
  File "/usr/local/lib/python3.10/site-packages/git/index/base.py", line 710, in _preprocess_add_items
    paths.append(self._to_relative_path(item))
  File "/usr/local/lib/python3.10/site-packages/git/index/base.py", line 696, in _to_relative_path
    return _to_relative_path(cast(PathLike, self.repo.working_tree_dir), path)
  File "/usr/local/lib/python3.10/site-packages/git/util.py", line 373, in _to_relative_path
    raise ValueError("Path %r is not in repository at %r" % (path_str, root_abs))
ValueError: Path '*' is not in repository at '//opal/opal/opal_repo_clone'
a
Hi @Marcus Nyh, I'm an AI assistant for Permit.io. I'll analyze available sources and get back to you shortly.
The traceback points to
TarFileToLocalGitExtractor.commit_local_git()
calling
local_git.index.add(self.policy_bundle_git_add_pattern)
in
opal-common/opal_common/git_utils/tar_file_to_local_git_extractor.py
, which is the exact same line and file referenced in a report of related behavior with this component(1). In that report, this same call is described as only staging additions/modifications of files present on disk, and not being able to properly handle certain path patterns, with a suggested fix of replacing it with:
Copy code
local_git.git.add(self.policy_bundle_git_add_pattern, all=True)
(1) That report also confirms this is a recognized bug with the
index.add()
call in this file, and that a corresponding pull request has been opened for it(1). Since your traceback shows the identical failing call (
local_git.index.add(self.policy_bundle_git_add_pattern)
) raising a
ValueError
on the path pattern, this matches the underlying mechanism described in that report(1). For general context on how the API bundle source is supposed to work — the OPAL server fetches the
bundle.tar.gz
, extracts it, and creates a git repo from its contents to track changes(2). If you'd like, I can also point you to how to configure polling vs. webhook detection for this bundle server(2).
To learn more, see the sources I considered: [[1] Deleted policy in API source type is not propagated to client](https://github.com/permitio/opal/issues/900) [[2] Policy syncing from API](https://docs.opal.ac/tutorials/track_an_api_bundle_server)
d
Hi @Marcus Nyh This wasn't caused by an OPAL code change between rc.1 and rc.2. Newer images ship with GitPython 3.1.58+, which changed how
index.add()
validates paths. Inside the container, the
opal
user's home dir is
//opal
(double slash). That means
~/opal
in the example compose expands to
//opal/opal
, and the new GitPython check rejects every path in a repo rooted under
//
. The #900 link the bot shared is a different issue, so no code changes are needed on your side. Quick fix to try in`docker-compose-api-policy-source-example.yml`, change
OPAL_POLICY_REPO_CLONE_PATH=~/opal
to
OPAL_POLICY_REPO_CLONE_PATH=/opal/opal
Let me know if that works 🙂
m
Thanks it worked👍
🚀 1