* Move the integration guide into the core docs. This is one of the
most common questions when people get started.
* Split the configuration and monitoring sections into their own
pages. This prepares the management page for an introduction that
explains the control plane concept.
* Move bundle section up to the top of the page since basic policy
distribution is usually the first concern.
Signed-off-by: Torin Sandall <torinsandall@gmail.com>
The docs have grown organically and it was time for a reorganization, specifically
helping people understand at a single glance the information
that is available in the docs.
The new docs are organized as follows:
- Core docs (policy and data)
- Use-case specific docs
- Operations
- Support
As part of the reorganization, several files were renamed and/or combined.
Also made an editing pass over what was previously the user-attribute docs
and generalized them to focus on data-replication, an issue that is
now promoted to the core docs. As part of that, updated the images
and removed the old ones; new image sources are in google slides.
Tweaked the navigation bar to give more space on the left-hand column
so that more of the topics are visible without scrolling.
Signed-off-by: Tim Hinrichs <tim@styra.com>
* Remove metric provider config to avoid introducing new public
interfaces. Since there is only one provider (prometheus) and it
doesn't have any configurable settings, remove the configuration
changes for now. We can always add these in the future.
* Remove dummy metric provider implementation. This isn't needed now
that we're using the metrics.Metrics interface instead of
metrics.GlobalMetrics.
* Remove metrics.GlobalMetrics in favour of metrics.Metrics. Move the
HTTP handler instrumentation interfaces into the server package to
avoid coupling the metrics package to the net/http package.
* Refactor the prometheus provider to implement the metrics.Metrics
interface. Since the prometheus registry can error on Gather()
calls, the provider has been updated to accept a logger and use ti
when the Gather() call fails. This doesn't affect any public
interfaces so it can be revisited in future if needed. Alteratnively
we could add a Gather() interface onto metrics.Metrics which could
return the error.
* Refactor status plugin to include metrics in status update by
default. Users implementing the status API are likely to need
performance metrics to gauge the OPA's health. Moreover if they are
implementing the status API it's unlikely they will want to poll the
/metrics endpoint on the OPA HTTP API (which may not even be
exposed.)
* Move the prometheus endpoint test case into the e2e package so the
server package has no dependencies on prometheus anymore.
Signed-off-by: Torin Sandall <torinsandall@gmail.com>
Prometheus metrics can give much of insight into OPA's health.
Run-time metrics are a natural part of the application state
so having them in status update seems like a right change
that can help server understand what's going in with the OPA
instance.
The commit also encapsulates all prometheus-related code in one package
and abstracts it with generic interface so that it would be possible
to add other metrics providers
Addresses #1606
Signed-off-by: Stan Lagun <stan@styra.com>
This change brings in support for multiple bundles to be downloaded
and activated OPA.
This is enabled by using the new config option `bundles` to define
the bundles, and deprecates the older `bundle` option.
The new `bundles` keyword and structure is propagated through to the
decision logs, status API, provenance, stored manifests, etc. Check
out the doc changes for all the updated structures.
That being said any existing configuration using `bundle` will *not*
see the new structure, everything is intended to be backwards
compatible (almost to a fault).
Fixes: #721
Signed-off-by: Patrick East <east.patrick@gmail.com>
It is not very discoverable as to how the `--set` options work when
keys have `.` characters in them. This adds in a section to the config
docs on how to do it.
Signed-off-by: Patrick East <east.patrick@gmail.com>
Clarify the requirements/caveats for using the local decision logger
and include a blurb on the decision log.
Signed-off-by: Patrick East <east.patrick@gmail.com>
Add option to log decision logs locally. They'll get logged via
Logrus at info level.
To enable configure OPA with something like:
```
decision_logs:
console: true
```
This will work alongside remote services and plugins. It will also
log the masked events in the case a masking policy is set.
Fixes: #1334
Signed-off-by: Patrick East <east.patrick@gmail.com>
These changes enhance the in-built decision logger to support masking
of input and result fields for cases where sensitive information is
passed to OPA (or generated by the policy.)
Also, fix rego package to avoid panic-ing on programmatically created
queriest that lack Location information.
Fixes#779
Signed-off-by: Torin Sandall <torinsandall@gmail.com>
Previously the code content was only kept in master and was
Subsequently referenced by the versioned doc contents. This causes
A few problems.. so we will version it along with the doc content.
To get this to work we make a handful of changes:
* Move the docs up into just opa/docs/content/*, we’re going to remove
The difference between local/dev and production builds soon.
* Move the “code” directory into the content dir, it is content tied
To the markdown files already there.
* Change the Hugo config to ignore the code directories
* Change the “code” shortcode to load the versioned code snippet
* Change load-docs to copy the code directory in addition to the other
markdown content.
Signed-off-by: Patrick East <east.patrick@gmail.com>
Torin Sandall