Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[jaeger-v2] Add support for GRPC storarge #5228

Merged
merged 8 commits into from Feb 27, 2024

Conversation

james-ryans
Copy link
Contributor

Which problem is this PR solving?

Description of the changes

  • Implement GRPC storage backend for Jaeger-V2 storage

How was this change tested?

  • Run two jaegertracing/jaeger-remote-storage at 17271 and 17281 ports
  • Execute go run -tags=ui ./cmd/jaeger --config ./cmd/jaeger/grpc_config.yaml

Checklist

Signed-off-by: James Ryans <james.ryans2012@gmail.com>
@james-ryans james-ryans requested a review from a team as a code owner February 24, 2024 10:50
Copy link

codecov bot commented Feb 24, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.62%. Comparing base (0c53139) to head (cd405ef).

Additional details and impacted files
@@             Coverage Diff             @@
##             main    #5228       +/-   ##
===========================================
+ Coverage   52.95%   94.62%   +41.67%     
===========================================
  Files         149      336      +187     
  Lines        8796    19521    +10725     
===========================================
+ Hits         4658    18472    +13814     
+ Misses       3779      861     -2918     
+ Partials      359      188      -171     
Flag Coverage Δ
cassandra-3.x 24.94% <ø> (ø)
cassandra-4.x 24.94% <ø> (ø)
elasticsearch-5.x 21.66% <ø> (ø)
elasticsearch-6.x 21.66% <ø> (ø)
elasticsearch-7.x 21.79% <ø> (ø)
elasticsearch-8.x 21.88% <ø> (ø)
grpc-badger 19.26% <42.85%> (+0.15%) ⬆️
kafka 13.74% <ø> (ø)
opensearch-1.x 21.79% <ø> (+0.01%) ⬆️
opensearch-2.x 21.79% <ø> (+0.01%) ⬆️
unittests 92.38% <72.72%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Signed-off-by: James Ryans <james.ryans2012@gmail.com>
@@ -78,6 +79,9 @@ func (c *Configuration) Close() error {
c.pluginHealthCheck.Stop()
c.pluginHealthCheckDone <- true
}
if c.remoteRPCClient != nil {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To pass the previous code coverage, I set up a gRPC server within the unit test for the factory to use, since we can't just mock the gRPC configuration. Because the current gRPC storage doesn't close the remote gRPC client, I added a method to close the client right inside the factory's Close() function. However, it looks like the code coverage tool isn't recognizing this particular line as covered. Even though I've called the Close() function in my unit test, which should hit this line, the method is abstracted behind an interface. Could this be why it's not showing up as covered?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in Go coverage is computed in a weird way, it's package local, i.e. coverage is only collected for a package from tests running in the same package. This behavior can be altered by passing additional packages explicitly, as we do for storage integration tests (we tell Go to count coverage in all other packages):

$(GOTEST) -coverpkg=./... -coverprofile cover.out $(STORAGE_PKGS)

So when the integration test runs for grpc-plugin it should include your Close changes, but not if you just run go test manually without -coverpkg

Comment on lines 156 to 158
if err != nil {
t.Fatalf("failed to listen: %v", err)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if err != nil {
t.Fatalf("failed to listen: %v", err)
}
require.NoError(t, err, "failed to listen")

@@ -106,12 +110,13 @@ func (c *Configuration) buildRemote(logger *zap.Logger, tracerProvider trace.Tra
opts = append(opts, grpc.WithUnaryInterceptor(tenancy.NewClientUnaryInterceptor(tenancyMgr)))
opts = append(opts, grpc.WithStreamInterceptor(tenancy.NewClientStreamInterceptor(tenancyMgr)))
}
conn, err := grpc.DialContext(ctx, c.RemoteServerAddr, opts...)
var err error
c.remoteRPCClient, err = grpc.DialContext(ctx, c.RemoteServerAddr, opts...)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not a client

Suggested change
c.remoteRPCClient, err = grpc.DialContext(ctx, c.RemoteServerAddr, opts...)
c.remoteConn, err = grpc.DialContext(ctx, c.RemoteServerAddr, opts...)

@@ -78,6 +79,9 @@ func (c *Configuration) Close() error {
c.pluginHealthCheck.Stop()
c.pluginHealthCheckDone <- true
}
if c.remoteRPCClient != nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in Go coverage is computed in a weird way, it's package local, i.e. coverage is only collected for a package from tests running in the same package. This behavior can be altered by passing additional packages explicitly, as we do for storage integration tests (we tell Go to count coverage in all other packages):

$(GOTEST) -coverpkg=./... -coverprofile cover.out $(STORAGE_PKGS)

So when the integration test runs for grpc-plugin it should include your Close changes, but not if you just run go test manually without -coverpkg

)

// Config has the configuration for jaeger-query,
type Config struct {
Memory map[string]memoryCfg.Configuration `mapstructure:"memory"`
Badger map[string]badgerCfg.NamespaceConfig `mapstructure:"badger"`
GRPC map[string]grpcCfg.Configuration `mapstructure:"grpc"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is how we want to do the configuration in V2, but we can address it more holistically later -- #5229

Signed-off-by: James Ryans <james.ryans2012@gmail.com>
Signed-off-by: James Ryans <james.ryans2012@gmail.com>
Signed-off-by: James Ryans <james.ryans2012@gmail.com>
Signed-off-by: James Ryans <james.ryans2012@gmail.com>
Comment on lines 170 to 173
err := f.Close()
if err != nil {
log.Fatalf("Client exited with error: %v", err)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
err := f.Close()
if err != nil {
log.Fatalf("Client exited with error: %v", err)
}
require.NoError(t, f.Close())

}

func (s *GRPCStorageIntegrationTestSuite) initialize() error {
s.logger, _ = testutils.NewLogger()

if s.factory != nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how would it be not nil at this point if the factory is only created in L119? Is it from another run of the test? If so we should close it as part of the clean-up, not as part of starting a new test

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, my initial thought was because it restarts the server when initializing, so I think it makes sense if I put it there too. But, moving it to the clean-up process does make things clearer. I've changed it.

Signed-off-by: James Ryans <james.ryans2012@gmail.com>
Signed-off-by: James Ryans <james.ryans2012@gmail.com>
@james-ryans
Copy link
Contributor Author

Do you know why the previous Protogen Validation CI failed? I didn't change anything in the idl module, and now it succeeded without me fixing anything. https://github.com/jaegertracing/jaeger/actions/runs/8066523840

@yurishkuro
Copy link
Member

Unclear why it failed:

--gogo_out: protoc-gen-gogo: Plugin failed with status code 127.
make: *** [Makefile.Protobuf.mk:97: proto-api-v2] Error 1

It's strange that the container doesn't print any more logs about it.

@yurishkuro yurishkuro merged commit 751efdb into jaegertracing:main Feb 27, 2024
35 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog:exprimental Change to an experimental part of the code v2
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants