doomshrine / gocosi Goto Github PK
View Code? Open in Web Editor NEWA Container Object Storage Interface (COSI) library and other helpful utilities created with Go.
License: Apache License 2.0
A Container Object Storage Interface (COSI) library and other helpful utilities created with Go.
License: Apache License 2.0
Yes
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.
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:
N/A
Libraries that should be looked into:
Yes
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.
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
// ...
)
Importing the sigs.k8s.io/container-object-storage-interface-provisioner-sidecar/pkg/consts
and creating the credentials by hand.
N/A
Yes
New repos often are missing Dockerfiles, while learning and applying best practices is commonly a time consuming job.
Provide Dockerfile while bootstraping the new repository.
Dockerfile should include:
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);HEALTHCHECK
instruction;N/A
N/A
This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
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
)cmd/bootstrap/template/Dockerfile.tpl
docker.io/library/golang 1.21.4
.github/workflows/conventional-changelog.yaml
actions/checkout v4
requarks/changelog-action v1
ncipollo/release-action v1.13.0
.github/workflows/labels.yaml
actions/checkout v4
actions/setup-go v4
.github/workflows/linters.yaml
actions/checkout v4
actions/setup-go v4
golangci/golangci-lint-action v3
.github/workflows/semantic-pr.yaml
amannn/action-semantic-pull-request v5
.github/workflows/tests.yaml
actions/checkout v4
actions/setup-go v4
codecov/codecov-action v3
go.mod
go 1.21
github.com/doomshrine/must v1.0.0
github.com/doomshrine/testcontext v1.0.0
github.com/go-logr/logr v1.3.0
github.com/grpc-ecosystem/go-grpc-middleware/v2 v2.0.1
github.com/hellofresh/health-go/v5 v5.5.0
github.com/stretchr/testify v1.8.4
go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc v0.46.0
go.opentelemetry.io/otel v1.20.0
go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc v0.43.0
go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp v0.43.0
go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc v1.20.0
go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp v1.20.0
go.opentelemetry.io/otel/sdk v1.20.0
go.opentelemetry.io/otel/sdk/metric v1.20.0
google.golang.org/grpc v1.59.0
sigs.k8s.io/container-object-storage-interface-spec v0.1.0
Build badge link is not working.
No response
Yes
N/A
Write a proposal/proof of concept, that will implement the custom readiness probe mechanism.
N/A
Yes
A lot of repositories struggle with implementing health check. We can standardise it for COSI Drivers.
Write a proposal/proof of concept, that will implement the custom health check mechanism. The healthcheck should:
Checker
interface;Checker
should have methods for:
CanConnect() error
?);IsAuthenticated() error
?)/healthz
endpoint.N/A
One of the runs in the GitHub Actions failed with the following log indicating data race.
==================
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
Yes
New repos often are missing Dockerfiles, while learning and applying best practices is commonly a time consuming job.
Bootstrapping repo should generate the Kustomization scaffolding.
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.
No response
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.