13 Commits

Author SHA1 Message Date
Johan Fylling a179a24c48 v1 API
All packages, except for `cmd` and `internal`, have been moved into a new `v1` root package.

Old packages are kept for backwards-compatibility reasons. All contained code is replaced with simple type aliases and proxy functions to `v1` implementations.

Old packages default to the Rego v0 syntax, new `v1` packages default to the Rego v1 syntax.

Signed-off-by: Johan Fylling <johan.dev@fylling.se>
2024-12-12 15:27:34 +01:00
Johan Fylling 7bb6dbe36b Preparing for v1 API
Moving (most) source to v1 root package to prepare for v0/v1 API separation.

Signed-off-by: Johan Fylling <johan.dev@fylling.se>
2024-12-12 15:09:03 +01:00
Ashutosh Narkar ebc3ab241a Always include HTTP request context in incoming req context
Previously the HTTP request context was included in the
request context at the info access log level. This means
if the access log level was set to error for instance,
the context would not include the http request context and
hence it would not be surfaced via decision logs.

This change always add the http request context to the request
context so that HTTP info like headers will be surfaced via decision
logs irrespective of the access log level.

Fixes: #6951

Signed-off-by: Ashutosh Narkar <anarkar4387@gmail.com>
2024-08-23 07:50:56 -07:00
Ashutosh Narkar a8ac7b38bb plugins/logs: Include http request context in decision logs
It would be useful if users had the ability to enhance the
decision log with info from the incoming HTTP request such as
headers. This change allows users to configure headers whose
values if present in the incoming HTTP request would be
surfaced via the decision log. This can be extended in the
future to include more context from the request.

Fixes: #6693

Signed-off-by: Ashutosh Narkar <anarkar4387@gmail.com>
2024-05-20 11:08:42 -07:00
Stephan Renatus 2c90500a0b logging: avoid '%!F(MISSING)' in logs (#6555)
When only passing a single string into a Printf-style function, any %-format
specs in it will be filled accordingly; but there will be no arguments to use.

So now, we'll avoid calling the `{Debug,Info,Warn,Error}f` functions when we
lack arguments.

Signed-off-by: Stephan Renatus <stephan@styra.com>
2024-01-29 10:31:42 +01:00
Stephan Renatus 4db7377969 server: pass decision_id via ctx, cleanup RemoteAddr -> RequestContext.ClientAddr (#5647)
Just s small cleanup in the server handler code. Ctx is for
request-scoped data, so let's put the decision ID there, too.

Our Eval and Log helper methods have way too many arguments already.

Signed-off-by: Stephan Renatus <stephan@styra.com>
2023-02-10 12:00:00 +01:00
Humberto Corrêa da Silva f1761ac77e server+runtime+logs: Add the req_id attribute on the decision logs (#5196)
Today it is not possible to correlate the decision log with
other types of logs (server, print, etc.) when the server log
level is >= INFO. The log correlation could be helpful in
troubleshooting.

A solution is to add a common attribute in all logs to make
the log correlation possible, so adding the req_id attribute
on decision logs, when server log level is >= INFO, will make it
possible.

Fixes: #5006

* Add documentation about decision log req_id attribute

The documentation purpose is to explain the relation with
others logs, how it could be used, and when it is included
on decision logs.

Signed-off-by: Humberto Corrêa da Silva <humbertoc_silva@hotmail.com>
2022-10-14 13:12:15 +02:00
Damien Burks bdafc01e0c Log .Warn at WARN level not ERROR (#4536)
And have the error level log warnings as well

Signed-off-by: Damien Burks <damien@damienjburks.com>
2022-04-05 22:41:45 +02:00
Vlad Iovanov c0a692d1ee logging: Remove logger GetFields function (#4116)
This removes the GetFields function from the logger interface, as mentioned in #4114.

GetFields used to be called in one place, creating a new logger using fields from an
http client afaict. I am not sure if my changes have the desired effect in that case,
or how this was desired to work - since the fields of the client are always changing
when making requests.

Fixes #4114.

Signed-off-by: viovanov <vlad@aserto.com>
2022-01-06 07:42:22 +01:00
Torin Sandall 0649fe96e2 plugins: Fix logger initialization on plugin manager
The plugin manager was initializing the logger _after_ creating
service clients which meant that service clients ended up relying on
the global logger. Since the runtime package did not configure the log
level on the global logger, the logs from the service clients were
missing.

This commit updates the plugin manager to initialize the logger
_before_ creating service clients and updates the runtime package to
set the log level on the global logger as a fallback.

Fixes #4071

Signed-off-by: Torin Sandall <torinsandall@gmail.com>
2021-11-30 11:06:07 -08:00
Torin Sandall e9d04fc1f5 runtime: Refactor logger usage
This commit does not change any functionality except it provides
callers with a way to provide a logger when instantiating the
runtime. Previously, the runtime had hardcoded dependencies on the
global logrus logger which made it problematic to test logging
behaviour. With this change, the logger can be supplied as a
parameter (which allows the caller to mock out the logger in tests...)

As part of this change, the dependencies on logrus have been moved out
of the runtime package entirely.

This commit includes a breaking change to the
runtime.NewLoggingHandler function: the function now requires a logger
to be supplied.

Signed-off-by: Torin Sandall <torinsandall@gmail.com>
2021-10-14 09:31:16 -07:00
Torin Sandall 8b40acea0a logging: Fix console logger instantiation
This commit fixes the console loggers so that messages are emitted
regardless of the debug log level. The problem was that in 3fcc875 we
updated the plugins to use a console logger obtained from the plugin
manager as opposed to a global logger instantiated in the plugins
package--the console logger obtained from the plugin manager was
instantiated in the runtime package by calling
logging.NewStandardLogger. Unfortunately, logging.NewStandardLogger
does not create a new logger--it returns the global logrus
logger.

This commit fixes the issue by deprecating logging.NewStandardLogger
and introducing two new functions in the logging package:

* logging.Get() - this replaces the old logging.NewStandardLogger
  function--this function should be called to obtain the debug logger
  used throughout OPA.

* logging.New() - this actually returns a new logger that can be
  configured independently from the debug logger used throughout
  OPA.

The runtime and sdk packages have been updated to call logging.New()
to obtain console loggers and the rest of the codebase has been
updated to call logging.Get() in place of logging.NewStandardLogger().

Fixes #3654

Signed-off-by: Torin Sandall <torinsandall@gmail.com>
2021-07-27 09:39:01 -07:00
Torin Sandall 3fcc875a55 logging: Move logging infrastructure into separate package
This commit moves the logging interface and implementations out of the
sdk package into the logging package.

This commit also updates the status and decision log plugins to use a
logger obtained from the plugin manager instead of going to the global
console logger in the plugins package. The latter change will be
important for SDK consumers. This change is backwards incompatible but
it's unlikely that anyone is relying on that export. The test for
console logger independence has also been moved into the plugins
package (from the status package.)

Fixes #3275

Co-authored-by: Torin Sandall <torinsandall@gmail.com>
Co-authored-by: Anders Eknert <anders@eknert.com>

Signed-off-by: Torin Sandall <torinsandall@gmail.com>
Signed-off-by: Anders Eknert <anders@eknert.com>
2021-05-10 11:34:14 -04:00