doomshrine / gocosi Goto Github PK

Are you interested in contributing to the development of this feature?

Yes

Is your feature request related to a problem? Please describe.

A lot of repositories struggle with implementing health check. We can standardise it for COSI Drivers.

Describe the solution you'd like.

Write a proposal/proof of concept, that will implement the custom health check mechanism. The healthcheck should:

• define a Checker interface;
• Checker should have methods for:
  • checking if the connection to the Object Storage Provider (OSP) can be established (CanConnect() error ?);
  • checking if the driver can authenticate to the OSP (IsAuthenticated() error ?)
• start a http server that can be used by Kubernetes or docker to check the /healthz endpoint.

Describe alternatives you've considered.

N/A

Additional Information

• The desired library to use is hellofresh/health-go.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• fix(deps): update module github.com/hellofresh/health-go/v5 to v5.5.1
• fix(deps): update opentelemetry-go monorepo (go.opentelemetry.io/otel, go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc, go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp, go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc, go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp, go.opentelemetry.io/otel/sdk, go.opentelemetry.io/otel/sdk/metric)

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Are you interested in contributing to the development of this feature?

Yes

Is your feature request related to a problem? Please describe.

New repos often are missing Dockerfiles, while learning and applying best practices is commonly a time consuming job.

Describe the solution you'd like.

Provide Dockerfile while bootstraping the new repository.

Dockerfile should include:

• Multi stage build (docker.io/library/golang:1.<x> as builder and other base image, e.g. gcr.io/distroless/static:<X>, docker.io/rockylinux/rockylinux:<X>-ubi-micro or something similar);
• Non root user;
• Cache mechanism in the builder;
• HEALTHCHECK instruction;

Describe alternatives you've considered.

N/A

Additional Information

N/A

Are you interested in contributing to the development of this feature?

Yes

Is your feature request related to a problem? Please describe.

Exporting Traces and Metrics should be integrated into the code by default. Right now, we are only starting spans/traces and counting metrics for the number of panics. Setting up the exporter is done exclusively by the driver developer, which can be a cumbersome process and often leads to inconsistency in how traces and metrics are collected and exported across different projects.

By providing default configurations for exporters, we can streamline the process and ensure that every project benefits from a standardised and efficient approach to exporting trace and metric data. This not only saves valuable development time but also promotes best practices in observability and monitoring.

Furthermore, default configurations can be optimized for common use cases, making it easier for developers to get started quickly with tracing and metrics without having to dive deep into the configuration details. This approach can greatly improve the out-of-the-box experience for new users and reduce the barrier to entry for adopting these essential monitoring and debugging tools.

Incorporating exporter configurations into the codebase as defaults doesn't mean eliminating flexibility. Advanced users can still override these defaults to tailor the setup to their specific needs. However, having sensible defaults in place ensures that even those who are not well-versed in observability can benefit from these features without a steep learning curve.

Ultimately, integrating trace and metric exporters into the codebase by default with well-thought-out default configurations can lead to more consistent, reliable, and accessible observability across your projects, benefiting both developers and end-users.

Describe the solution you'd like.

I would like a new Option (e.g. WithDefaultMetricExporter and WithDefaultTraceExporter), that will allow using default configuration of OTEL Exporters for Traces and Metrics, by just setting up the endpoint of OTEL Collector as documented in:

1. specification;
2. README of opentelemetry-go/exporters/otlp/otlptrace;
3. documentation of opentelemetry-go/exporters/otlp/otlpmetiric/otlpmetrichttp.

Describe alternatives you've considered.

N/A

Additional Information

Libraries that should be looked into:

• go.opentelemetry.io/otel/exporters/otlp/otlpmetric
• go.opentelemetry.io/otel/exporters/otlp/otlptrace

Are you interested in contributing to the development of this feature?

Yes

Is your feature request related to a problem? Please describe.

N/A

Describe the solution you'd like.

Write a proposal/proof of concept, that will implement the custom readiness probe mechanism.

Describe alternatives you've considered.

N/A

Additional Information

• Directly related to #19 ;
• The desired library to use is hellofresh/health-go.

What happened?

One of the runs in the GitHub Actions failed with the following log indicating data race.

Relevant log output

==================
WARNING: DATA RACE
Read at 0x00000128de40 by goroutine 11:
  github.com/doomshrine/gocosi.(*Driver).Run()
      /home/runner/work/gocosi/gocosi/gocosi.go:98 +0x51b
  github.com/doomshrine/gocosi.TestRun.func2()
      /home/runner/work/gocosi/gocosi/gocosi_test.go:102 +0xf6
  testing.tRunner()
      /opt/hostedtoolcache/go/1.20.7/x64/src/testing/testing.go:1576 +0x216
  testing.(*T).Run.func1()
      /opt/hostedtoolcache/go/1.20.7/x64/src/testing/testing.go:1629 +0x47

Previous write at 0x00000128de40 by goroutine 8:
  github.com/doomshrine/gocosi.SetLogger()
      /home/runner/work/gocosi/gocosi/gocosi.go:74 +0xca
  github.com/doomshrine/gocosi.TestSetLogger()
      /home/runner/work/gocosi/gocosi/gocosi_test.go:36 +0x74
  testing.tRunner()
      /opt/hostedtoolcache/go/1.20.7/x64/src/testing/testing.go:1576 +0x216
  testing.(*T).Run.func1()
      /opt/hostedtoolcache/go/1.20.7/x64/src/testing/testing.go:1629 +0x47

Goroutine 11 (running) created at:
  testing.(*T).Run()
      /opt/hostedtoolcache/go/1.20.7/x64/src/testing/testing.go:1629 +0x805
  github.com/doomshrine/gocosi.TestRun()
      /home/runner/work/gocosi/gocosi/gocosi_test.go:94 +0x97
  testing.tRunner()
      /opt/hostedtoolcache/go/1.20.7/x64/src/testing/testing.go:1576 +0x216
  testing.(*T).Run.func1()
      /opt/hostedtoolcache/go/1.20.7/x64/src/testing/testing.go:1629 +0x47

Goroutine 8 (running) created at:
  testing.(*T).Run()
      /opt/hostedtoolcache/go/1.20.7/x64/src/testing/testing.go:1629 +0x805
  testing.runTests.func1()
      /opt/hostedtoolcache/go/1.20.7/x64/src/testing/testing.go:2036 +0x8d
  testing.tRunner()
      /opt/hostedtoolcache/go/1.20.7/x64/src/testing/testing.go:1576 +0x216
  testing.runTests()
      /opt/hostedtoolcache/go/1.20.7/x64/src/testing/testing.go:2034 +0x87c
  testing.(*M).Run()
      /opt/hostedtoolcache/go/1.20.7/x64/src/testing/testing.go:1906 +0xb44
  main.main()
      _testmain.go:84 +0x2fc
==================
--- FAIL: TestRun (0.00s)
    --- FAIL: TestRun/run_with_defaults (0.00s)
        testing.go:1446: race detected during execution of test
--- FAIL: TestSetLogger (0.00s)
    testing.go:1446: race detected during execution of test
FAIL

Are you interested in contributing to the development of this feature?

Yes

Is your feature request related to a problem? Please describe.

New repos often are missing Dockerfiles, while learning and applying best practices is commonly a time consuming job.

Describe the solution you'd like.

Bootstrapping repo should generate the Kustomization scaffolding.

Describe alternatives you've considered.

Helm chart in the bootstrapped repo - this would introduce additional unwanted dependency on Helm, and it can interfere with the idea of central Helm repository in company/project.

Additional Information

No response

What happened?

Build badge link is not working.

Relevant log output

No response

Are you interested in contributing to the development of this feature?

Yes

Is your feature request related to a problem? Please describe.

The credentials returned in the Driver is of type map[string]string. It is sometimes confusing to new developers how to structure this value for available protocols.

Describe the solution you'd like.

I would like to have functions that simplify the creation of the credentials, e.g.:

func S3Credential(secretKeyID, secretKey, bucketName string, endpoint *url.URL) (map[string]string, error)

Additionally, for the purpose of custom functions that can be written in the future, provide each map key in form of constant, e.g.:

import "sigs.k8s.io/container-object-storage-interface-provisioner-sidecar/pkg/consts"

const (
	S3SecretAccessKeyID string = consts.SecretAccessKeyID
	// ...
)

Describe alternatives you've considered.

Importing the sigs.k8s.io/container-object-storage-interface-provisioner-sidecar/pkg/consts and creating the credentials by hand.

Additional Information

N/A