daniel-sanche
Repos
54
Followers
62
Following
1

An implementation of the Power Crust algorithm in MATLAB Code

11
5

KubeMonitor is a macOS app that displays information about your active Kubernetes cluster in your menu bar

121
4

let your users add images from their Facebook albums

53
13

Events

improved type checking

Created at 11 hours ago

convert client info into gapic subclass

fixed lint issues

Merge branch 'fix_headers' of github.com:googleapis/python-logging into fix_headers

Created at 11 hours ago
pull request opened
fix: client_info default values

When client_info is not given to a new client, it now defaults to the values used by self._connection._client_info, rather than using None. This will allow the expected headers to be populated when using the grpc transport

Also added tests to ensure client_info is always set as expected in all classes

Fixes https://github.com/googleapis/python-logging/issues/680

Created at 12 hours ago
bug: client_info is not being properly set in client init

When a new client is initialized, there is no default value for the client_info parameter. This means that some of the expected headers are not being set on calls through the client, causing our instrumentation to not capture them properly.

Created at 12 hours ago
daniel-sanche create branch fix_headers
Created at 12 hours ago
logging: provided timestamps are ignored in GKE when using RedirectAsJSON(os.Stdout)

Yes, this seems directly related to https://github.com/googleapis/google-cloud-go/issues/6995. Unfortunately, fully fixing would significantly change the current behaviour of existing loggers, since many jsonPayloads would change into textPayloads after the change. So it will have to wait until we are ready for our next major release to make the breaking change.

We can partially address this by adding an extra timestamp value with the proper formatting. There would still be an extra timestamp in the jsonPayload, but at least the timestamp field would also be set properly. I can try to look into that soon

Created at 19 hours ago
Update logging quickstart sample

Improve the Logging quickstart in Python. Quickstart should work out of the box and contain all the instructions (in comments) so users can immediately see their logs.

Additional criteria:

  • [ ] include comments on various ways to authenticate
  • [ ] encourage users to log with standard log wrapper e.g. logging.warning(text) rather than directly writing LogEntries. Context: In an ideal world, customers should be able to use existing logging frameworks native to their language. With some simple appender/handler to also ship logs to Cloud Logging. Customers aren't locked into logging library syntax, thus it's easier to both onboarding and offboard off of these client libraries.
  • [ ] comment that if users need more customizable logs, redirect to writing log entries
  • [ ] if applicable, a test for this sample
Created at 2 days ago
daniel-sanche delete branch release-please--branches--main
Created at 2 days ago

chore(main): release 3.3.0 (#645)

Created at 2 days ago
pull request closed
chore(main): release 3.3.0

:robot: I have created a release beep boop

3.3.0 (2022-11-26)

Features

  • Add support for custom JSON encoders (#657) (77e621c)
  • Include context on batch log errors (#650) (d08be9a)
  • Set partial_success to default to true for batched logs (#649) (e56d3e8)
  • Support Django asgi middleware (#625) (f52b3aa)

Bug Fixes

  • deps: Allow protobuf 3.19.5 (#644) (12f3001)
  • Json fields dictionary has modification side effect (#654) (a62a0d6)

This PR was generated with Release Please. See documentation.

Created at 2 days ago
RequestMiddleware not working at Django 4.1

I tryed to use google.cloud.logging_v2.handlers.middleware.RequestMiddleware at Django 4.1.3, Python 3.10 but errors raises bellow:

Environment details

  • OS type and version: Linux
  • Python version: 3.10
  • pip version: pip-22.3.1
  • google-cloud-logging version: 3.2.5

Steps to reproduce

  1. Create new Django project.
  2. Add the RequestMiddleware to settings.MIDDLEWARE
  3. start runserver
  4. access / path --> error raised.

Code example

# settings.py at Django
MIDDLEWARE = [
    'google.cloud.logging_v2.handlers.middleware.RequestMiddleware',
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

Stack trace

Traceback (most recent call last):
  File "/home/vagrant/tmp/myproject/venv/lib/python3.10/site-packages/django/core/handlers/exception.py", line 55, in inner
    response = get_response(request)
  File "/home/vagrant/tmp/myproject/venv/lib/python3.10/site-packages/django/utils/deprecation.py", line 131, in __call__
    if self._is_coroutine:
AttributeError: 'RequestMiddleware' object has no attribute '_is_coroutine'

At the same code, when using Django 4.0.8, it's working.

Created at 2 days ago
RequestMiddleware not working at Django 4.1

This should be fixed by this recent PR, which will soon be released as v3.3.0

I just did a quick test with Django 4.1.3, and didn't run into any issues. Please re-open it if you still have problems after the 3.3.0 release

Created at 2 days ago
issue comment
fix: Need a way to disable flushing

Given the expectations to the backward compatibility and an attempt to avoid introduction of the new interfaces while keeping the existing interface intuitive, I propose the following implementation and recommend to extend it to the java-logging-logback library:

  1. Refactor LoggingHandler.severityFor(Level level) method to switch/case based on the java.util.logging.Level values and not Integer values that supposed to reflect the numeric values of the logging levels.
  2. For the case Level.OFF return null:
    case Level.OFF:
        return null;
    
  3. Keep the rest implementation (I mainly reference to LoggingImpl.java:885) as it is now.

Yeah, this seems like a great solution to me. It seems to be in line with the original intent of the setFlushSeverity function, where null was documented to mean "flush off", so this feels like the safest way to implement this change

Created at 2 days ago
issue comment
fix: Need a way to disable flushing

Unrecognized is part of the log severity proto definition. The spec doesn't make it clear how it is meant to be used, but that doesn't mean it's safe to redefine.

We will likely encounter some legitimate logs with their severity field set to "unrecognized". (speculation: maybe some OTel exporters will use "unrecognized" when there's not a direct mapping between a GCP LogSeverity and a different vendor's?) If we treat "Unrecognized" to mean "Log flushing Off", that could make things confusing if customers attempt to actually filter for those logs. And it could be hard to fix in the future

Created at 3 days ago
issue comment
fix: Need a way to disable flushing

pending writes if log severity is equal or above flush severity... LogSeverity.UNRECOGNIZED already exists and I use it only for this specific feature to indicate that we should skip logging since flush severity

My concern is that the spec for LogSeverity.UNRECOGNIZED was not intended to mean "log flusing off", so I'm worried about future problems from overloading the meaning of that field

but I was thinking that creating Severity.OFF = LogSeverity.UNRECOGNIZED did not make much sense either since Severity is tied with LogSeverity.

Could we do Severity.OFF = null instead, so we're not overloading an existing field?

Created at 3 days ago
issue comment
fix: Need a way to disable flushing

I use Severity.UNRECOGNIZED as a severity to signal turning off flushing for java-logging since there is no way to extend equivalent LogSeverity which is protobuf enum .

Overloading Severity.UNRECOGNIZED for this doesn't really sit right with me. It feels like it could cause significant technical debt in the future.

  1. Can we use a separate bool flag to turn flushing on/off instead of overloading the Severity field?
  2. Or, since everything seems to use the Severity enum, couldn't we add a Severity.OFF item there, without it having a corresponding proto entry?
Created at 3 days ago
pull request opened
fix API doc formatting

There was an extra space in the API doc markdown table, causing the formatting to break

Created at 6 days ago

fix API doc formatting

Created at 1 week ago