profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/indrekj/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

dkubb/yardstick 163

A tool for verifying YARD documentation coverage

indrekj/guard-slim 6

Guard gem for slim

indrekj/bitbot-trader 4

Ruby API for MtGox and Bitstamp

indrekj/ib_estonia 1

Generates Estonian Tax report from Interactive Brokers report

PullRequestReviewEvent

created tagsalemove/freddy

tagv2.2.1

Messaging api supporting request-response and acknowledgements.

created time in 3 days

delete branch salemove/freddy

delete branch : forwardable

delete time in 3 days

push eventsalemove/freddy

Indrek Juhkam

commit sha 0a71c1c3ea4940c1c5122aabb85877e2d8d1df10

Explicitly require forwardable This is usually present because some other gem loads it as well. In one of our microservices however no other depdenecy required it. Requiring freddy failed with: ``` uninitialized constant Freddy::Adapters::BunnyAdapter::Channel::Forwardable ```

view details

Indrek Juhkam

commit sha f641532bce5a73efd56ff7b971a5b207f3434af1

Bump version to 2.2.1

view details

Indrek Juhkam

commit sha 347de92060e340c06083158d4510327f95996d2f

Merge pull request #70 from salemove/forwardable Explicitly require forwardable

view details

push time in 3 days

PR merged salemove/freddy

Reviewers
Explicitly require forwardable

This is usually present because some other gem loads it as well. In one of our microservices however no other depdenecy required it. Requiring freddy failed with:

uninitialized constant Freddy::Adapters::BunnyAdapter::Channel::Forwardable
+2 -1

0 comment

2 changed files

indrekj

pr closed time in 3 days

PR opened salemove/freddy

Explicitly require forwardable

This is usually present because some other gem loads it as well. In one of our microservices however no other depdenecy required it. Requiring freddy failed with:

uninitialized constant Freddy::Adapters::BunnyAdapter::Channel::Forwardable
+2 -1

0 comment

2 changed files

pr created time in 3 days

create barnchsalemove/freddy

branch : forwardable

created branch time in 3 days

Pull request review commentopen-telemetry/opentelemetry-erlang-contrib

Update otel-phoenix deps

 defmodule OpentelemetryPhoenix.MixProject do   defp deps do     [       {:opentelemetry_api, "~> 1.0.0-rc"},-      {:opentelemetry, "~> 1.0.0-rc"},       {:opentelemetry_telemetry, "~> 1.0.0-beta"},-      {:telemetry, "~> 0.4"},+      {:telemetry, "~> 0.4 or ~> 1.0.0"},

My proposal would allow 0.4 - 1.[x] (2.0 excluded). You could always define the minimum minor version like ~> 1.1. This would still allow users to use 1.2, 1.3, etc. Generally, I think the unlocked minor version is better, because if's locked and one library requires 1.0 and another one requires 1.1 then the user cannot use them together. This is also how it is done in the phoenix library as well: https://github.com/phoenixframework/phoenix/blob/473b10bb4166c57700b1e6d1a518f76458640da7/mix.exs#L66 .

Just my thoughts.

bryannaegele

comment created time in 3 days

PullRequestReviewEvent

pull request commentsalemove/elixir-http_client

Update Tesla to 1.4

Up to you. It's surprising that they did such a breaking change in a minor version, but on the other hand, it probably doesn't have a huge impact and generally, backoff is better anyway.

ostap0207

comment created time in 4 days

PullRequestReviewEvent
CommitCommentEvent

Pull request review commentopen-telemetry/opentelemetry-erlang-contrib

Update otel-phoenix deps

 defmodule OpentelemetryPhoenix.MixProject do   defp deps do     [       {:opentelemetry_api, "~> 1.0.0-rc"},-      {:opentelemetry, "~> 1.0.0-rc"},       {:opentelemetry_telemetry, "~> 1.0.0-beta"},-      {:telemetry, "~> 0.4"},+      {:telemetry, "~> 0.4 or ~> 1.0.0"},
      {:telemetry, "~> 0.4 or ~> 1.0"},

I don't think we need to lock the minor version

bryannaegele

comment created time in 4 days

PullRequestReviewEvent

pull request commentopen-telemetry/opentelemetry-ruby

feat: add Que instrumentation

@fbogsany Thank you :bow:. I'd appreciate it if someone could also publish it to rubygems. This would allow us to start migrating all our ruby projects to opentelemetry.

indrekj

comment created time in 4 days

issue commentopen-telemetry/opentelemetry-operator

Provide a way to add annotations to Pods

The latter: PodSpec of a collector instance as deployment.

indrekj

comment created time in 4 days

delete branch indrekj/opentelemetry-ruby

delete branch : instrumentation-que

delete time in 4 days

issue commentopen-telemetry/opentelemetry-helm-charts

Latest version in helm repo is 0.2.0

Still a problem,

https://github.com/open-telemetry/opentelemetry-helm-charts/runs/3580447145

Now failed with:

remote: error: GH006: Protected branch update failed for refs/heads/gh-pages.        
remote: error: Required status check "EasyCLA" is expected.        
To https://github.com/open-telemetry/opentelemetry-helm-charts
 ! [remote rejected] HEAD -> gh-pages (protected branch hook declined)
error: failed to push some refs to 'https://github.com/open-telemetry/opentelemetry-helm-charts'
Error: exit status 1
anuraaga

comment created time in 5 days

pull request commentopen-telemetry/opentelemetry-ruby

feat: add Que instrumentation

@fbogsany @ahayworth pinging you as you've been active before in this PR. I would like to get this merged/released. Is there anything else I am missing?

indrekj

comment created time in 5 days

pull request commentopen-telemetry/opentelemetry-erlang-contrib

Add opentelemetry integration to Oban

@tsloughter Rebased my PR and addressed the checklist in the open checklist PR.

@dvic I did see that repository, though only after most of my code was already done. I would like to get this PR approved/merged before porting over your changes. This current PR takes care of job processing and trace propagation. I see you added tracing for circuits, plugins etc. It likely makes sense to port them over but as it needs some testing and making sure they follow semantic conventions I'd like to start with the basic features that this PR should take care of.

indrekj

comment created time in 5 days

push eventindrekj/opentelemetry-erlang-contrib

Bryan Naegele

commit sha a216f6ce20ad3f396006a038d8bc41ab1f566859

Otel phoenix migration (#4) * Otel phoenix migration * Abandon dynamic matrix for now * Add project-level codeowners * Add examples and phoenix * Typo

view details

Bryan Naegele

commit sha b9efd1d228c61d99f16ce6ce913f88758bfabb50

Update issue templates

view details

Bryan Naegele

commit sha 7209beabc3d42427f8a4685cea4762c85098f96d

Update README.md

view details

Bryan Naegele

commit sha aabe880146bcf3d4a0cf2188a408a60d0f9c06f8

Update labeler.yml

view details

Bryan Naegele

commit sha 4d758e89f51d62d890241033c83a4a23b1617eab

Update test matrix strategy (#10)

view details

Bryan Naegele

commit sha e49b8e9b3fef2b92c5d1bb164bc1b3eeb02f20c6

Update elixir.yml

view details

Indrek Juhkam

commit sha c20a9ad21f8cefd1d374bf782f1a7614a1dde333

Add opentelemetry integration to Oban By default a new trace is automatically started when a job is processed by monitoring these events: * `[:oban, :job, :start]` — at the point a job is fetched from the database and will execute * `[:oban, :job, :stop]` — after a job succeeds and the success is recorded in the database * `[:oban, :job, :exception]` — after a job fails and the failure is recorded in the database To also record a span when a job is created and to link traces together `Oban.insert/2` has to be replaced by `OpentelemetryOban.insert/2`. Before: ```elixir %{id: 1, in_the: "business", of_doing: "business"} |> MyApp.Business.new() |> Oban.insert() ``` After: ```elixir %{id: 1, in_the: "business", of_doing: "business"} |> MyApp.Business.new() |> OpentelemetryOban.insert() ```

view details

push time in 5 days

pull request commentopen-telemetry/opentelemetry-erlang

Add b3multi option to OTEL_PROPAGATORS

@tsloughter I added a commit that fixes the issue I mentioned: https://github.com/open-telemetry/opentelemetry-erlang/pull/272/commits/6942f0864c661329b856b2937fe610511d9561aa . I have no idea if this is the actual approach you'd want to use but it should be backwards compatible and it does work.

indrekj

comment created time in 8 days

push eventindrekj/opentelemetry-erlang

Łukasz Niemier

commit sha 74d457d79cc8f1f1a0ca839c9b844813b4faaf4f

chore: update Iliia name and workplace for him and me

view details

Iliia Khaprov

commit sha 67f02df21e57e8e68eb597aee90d8da62fd50402

Merge pull request #275 from open-telemetry/chore/update-names Update Iliia name and workplace

view details

Indrek Juhkam

commit sha 7a68b5cca6128ae3ea44efcb08e7d7553f3d9d42

Add b3multi option to OTEL_PROPAGATORS According to [OTEL Spec][1] there are `b3` and `b3multi`. The latter is supposed to be used when [Multi B3 format][2] is used. This is exactly what b3_propagators() currently is doing. [1]: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/sdk-environment-variables.md#general-sdk-configuration [2]: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/context/api-propagators.md#b3-extract

view details

Indrek Juhkam

commit sha 6942f0864c661329b856b2937fe610511d9561aa

Fix using OTEL_PROPAGATORS env variable Previously OTEL_PROPAGATORS set `propagators` argument. However, in src/opentelemetry_app.erl `text_map_propagators` was used: ``` setup_text_map_propagators(Opts) -> Propagators = proplists:get_value(text_map_propagators, Opts, []), ... ``` This meant that `propagators` argument that we got from OTEL_PROPAGATORS env variable was not used anywhere. Even though you could set OTEL_PROPAGATORS="b3multi" it didn't do anything. `:otel_propagator.text_map_inject([])` still returned tracecontext. Here I changed OTEL_PROPAGATORS to put the value to text_map_propagators which is used. Now when using `OTEL_PROPAGATORS="b3multi"` then `:otel_propagator.text_map_inject([])` actually returns B3 headers. The setting can still be controlled with already existing app settings as well: ``` config :opentelemetry, text_map_propagators: [&:otel_tracer_default.b3_propagators/0] ``` but OTEL_PROPAGATORS takes priority if it is defined.

view details

push time in 8 days

push eventindrekj/opentelemetry-erlang

Indrek Juhkam

commit sha 173f86c0b06a27283b1370e35f992aa10ca50eca

Fix using OTEL_PROPAGATORS env variable Previously OTEL_PROPAGATORS set `propagators` argument. However, in src/opentelemetry_app.erl `text_map_propagators` was used: ``` setup_text_map_propagators(Opts) -> Propagators = proplists:get_value(text_map_propagators, Opts, []), ... ``` This meant that `propagators` argument that we got from OTEL_PROPAGATORS env variable was not used anywhere. Even though you could set OTEL_PROPAGATORS="b3multi" it didn't do anything. `:otel_propagator.text_map_inject([])` still returned tracecontext. Here I changed OTEL_PROPAGATORS to put the value to text_map_propagators which is used. Now when using `OTEL_PROPAGATORS="b3multi"` then `:otel_propagator.text_map_inject([])` actually returns B3 headers. The setting can still be controlled with already existing app settings as well: ``` config :opentelemetry, text_map_propagators: [&:otel_tracer_default.b3_propagators/0] ``` but OTEL_PROPAGATORS takes priority if it is defined.

view details

push time in 8 days

created tagsalemove/freddy

tagv2.2.0

Messaging api supporting request-response and acknowledgements.

created time in 8 days

delete branch salemove/freddy

delete branch : otel-improvements

delete time in 8 days

push eventsalemove/freddy

Indrek Juhkam

commit sha fdf6b330ca7bae3934aa2b0c77184e1c729ee881

Rename messaging operation from receive to process Receive is supposed to be used when doing batch processing or when receive and process are both used. If there's only one event and processing happens immediately, then it makes more sense to use `process`.

view details

Indrek Juhkam

commit sha 2f01cc88a1e8b4a52fec0e6415ffc065e872767d

Start a new trace when receiving a broadcast RPC still uses the same trace, but broadcasts (Freddy#deliver) now create new traces but we still store the original trace link for observability. I previously went against the spec because Zipkin doesn't support links. But we're likely going to replace Zipkin and it's better to follow the OpenTelemetry spec.

view details

Indrek Juhkam

commit sha afb98b896e2cde12c2e8e56e82e2f057482ee1dc

Bump version to 2.2.0

view details

Indrek Juhkam

commit sha 1bd68c82a013e2b6763bd1741ad710e13d007d14

Merge pull request #69 from salemove/otel-improvements Start a new trace when receiving a broadcast

view details

push time in 8 days

PR merged salemove/freddy

Start a new trace when receiving a broadcast

RPC still uses the same trace, but broadcasts (Freddy#deliver) now create new traces but we still store the original trace link for observability.

I previously went against the spec because Zipkin doesn't support links. But we're likely going to replace Zipkin and it's better to follow the OpenTelemetry spec.

+37 -8

0 comment

3 changed files

indrekj

pr closed time in 8 days

pull request commentopen-telemetry/opentelemetry-erlang

[HOLD] Add b3multi option to OTEL_PROPAGATORS

The issue is that it is not used. Basically, propagators sets it to b3 (when using env var) but then that is just ignored. So even though I use b3multi env variable, everything is still propagated using w3c trace context. Currently, it seems that OTEL_PROPAGATORS is basically a no-op. At least that's how I understand this.

indrekj

comment created time in 9 days

Pull request review commentricardoccpaiva/opentelemetry_tesla

Add Tesla middleware

 defmodule OpentelemetryTesla.MixProject do   def project do     [       app: :opentelemetry_tesla,-      version: "1.0.0-rc.1",+      version: "1.1.0-rc.1",

oh nvm. I thought the previous version was 0.1. Going from 1.0 to 1.1 is totally fine here.

ricardoccpaiva

comment created time in 9 days