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

Allow puppetboard to start without a running puppetdb #980

Open
defnull opened this issue Nov 23, 2023 · 0 comments
Open

Allow puppetboard to start without a running puppetdb #980

defnull opened this issue Nov 23, 2023 · 0 comments

Comments

@defnull
Copy link

defnull commented Nov 23, 2023

Currently puppetboard tries to connect to puppetdb as a side-effect of importing puppetboard.app and calls sys.exit() if that (or the version check) fails. It also configures logging (six times). Both is unusual, as imports should not have such side-effects. This may cause some issues:

  • Puppetboard will fail (hard) if puppetdb is not ready yet, resulting in lots of unnecessary container or service restarts and lots of log noise during startup. Once the app is running, puppetdb can go down and errors are properly handled. It is just the initial check that may cause a hard error.
  • Puppetboard overrides logging configuration done by the actual entry point (e.g. a custom wsgi.py that imports puppetboard).
  • Puppetboard cannot be embedded into another WSGI application or wrapped with middleware easily, because importing puppetboard.app may trigger sys.exit() as a side-effect.

Proposal:

  • Only do uncritical stuff at import-time (e.g. importing all the puppetboard.views or configuring jinja2) so import app from puppetboard.app does not crash the process but still returns a fully populated app object.
  • Move logging configuration and checks into a new puppetboard.app::bootstrap(checks=True, logging=True) function that simply returns the app object and can be used by gunicorn for initialization.
  • Bonus points if configuration can be passed in as a dict (instead of the implicit and hard-coded dependency on os.environ)

Some background: I'm working on a project that provides teams with a convenient web UI to manage a puppet-server (e.g. deploy environments from git, sign certs, encrypt secrets, ...). This web app also has a puppetboard embedded in it, which is protected by the same auth framework (OpenID+RBAC) as the rest of the application. I had to jump through a bunch of hoops to get this to work, but it works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant