add heartbeat flag for grpc server and broker#464
add heartbeat flag for grpc server and broker#464clyang82 merged 1 commit intoopenshift-online:mainfrom
Conversation
WalkthroughAdds a feature to disable heartbeat messages from the gRPC server to clients through configuration flag. Implementation wires the heartbeat disable setting through config, broker initialization, and server-side conditional goroutine startup logic. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
📜 Recent review detailsConfiguration used: Organization UI Review profile: CHILL Plan: Pro Cache: Disabled due to data retention organization setting Knowledge base: Disabled due to ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (4)
🚧 Files skipped from review as they are similar to previous changes (2)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
🔇 Additional comments (3)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @go.mod:
- Line 45: The go.mod entry pins google.golang.org/grpc to v1.78.0 which appears
to be unavailable as a stable release; confirm the intended grpc version and
update go.mod to a published release (e.g., v1.77.0) or to the specific
prerelease tag if that was deliberate, then run the appropriate go get/Go
modules tidy to resolve deps; note that no new heartbeat API is required in
grpc_server.go or grpc_broker.go because existing heartbeat support uses
google.golang.org/grpc/keepalive with config flags HeartbeatCheckInterval and
HeartbeatDisable, so do not add heartbeat code—only correct the grpc module
version to a valid published tag.
🧹 Nitpick comments (2)
cmd/maestro/server/grpc_broker.go (1)
62-63: Consider propagating a context instead of usingcontext.Background().The
Listmethod signature doesn't accept a context, socontext.Background()is used. However, this loses any tracing/cancellation context from the caller. If the upstream interface (types.ListOptions) can be modified or if this method is called within a context-aware flow, consider addingcontext.Contextto the method signature for consistency with the broader context-propagation changes in this PR.pkg/client/cloudevents/grpcsource/watcherstore.go (1)
218-254: Consider updatingSync()to accept a context parameter for consistency.The
Sync()method still usesm.ctxforPageListand logging calls (lines 235, 247, 269, 272, 279), while other methods likeGetWatcher,Get, andListhave been updated to accept and propagate a caller-provided context. This creates an inconsistency in context handling across the store's API.If callers of
Sync()would benefit from passing their own context (for cancellation or tracing), consider updating this method signature as well.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Cache: Disabled due to data retention organization setting
Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (9)
cmd/maestro/server/grpc_broker.gocmd/maestro/server/grpc_server.gogo.modpkg/client/cloudevents/grpcsource/watcherstore.gopkg/config/grpc_server.gopkg/services/resource.gopkg/services/resource_test.gotest/performance/pkg/hub/store/createonly.gotest/store.go
🚧 Files skipped from review as they are similar to previous changes (3)
- pkg/config/grpc_server.go
- test/store.go
- pkg/services/resource.go
🧰 Additional context used
🧬 Code graph analysis (2)
pkg/client/cloudevents/grpcsource/watcherstore.go (4)
pkg/client/cloudevents/grpcsource/pager.go (1)
PageList(22-84)pkg/logger/operationid_middleware.go (1)
GetOperationID(59-64)pkg/api/openapi/model_list.go (1)
List(23-28)pkg/api/resource_types.go (1)
ResourceList(29-29)
test/performance/pkg/hub/store/createonly.go (2)
pkg/api/openapi/model_list.go (1)
List(23-28)pkg/api/resource_types.go (1)
ResourceList(29-29)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (8)
- GitHub Check: Red Hat Konflux / maestro-e2e-on-pull-request
- GitHub Check: Red Hat Konflux / maestro-on-pull-request
- GitHub Check: verify
- GitHub Check: e2e
- GitHub Check: e2e-broadcast-subscription
- GitHub Check: e2e-with-istio
- GitHub Check: upgrade
- GitHub Check: e2e-grpc-broker
🔇 Additional comments (18)
pkg/services/resource_test.go (3)
89-94: LGTM!The update correctly passes
context.Background()to match the newListmethod signature. This is the appropriate context choice for unit tests.
96-100: LGTM!Consistent with the other call sites, correctly updated to pass context as the first argument.
102-107: LGTM!All
Listcall sites in this test are now consistently updated to passcontext.Background()as the first argument, aligning with the new API signature.test/performance/pkg/hub/store/createonly.go (4)
21-23: LGTM!The
context.Contextparameter is correctly added to match the updated interface signature. The stub implementation appropriately remains unchanged.
43-45: LGTM!Context parameter added consistently with the interface change.
47-49: LGTM!Context parameter added consistently.
51-53: LGTM!Context parameter added consistently. The stub correctly returns
(nil, false, nil)to indicate the resource was not found.cmd/maestro/server/grpc_broker.go (1)
187-190: LGTM!The
BrokerOptionsinitialization correctly wires the heartbeat configuration from the server config, aligning with the PR objective to make heartbeat behavior configurable.cmd/maestro/server/grpc_server.go (2)
46-47: LGTM!The
heartbeatDisablefield addition follows the existing pattern for configuration-driven behavior in the struct.
351-375: LGTM!The heartbeat goroutine implementation is well-structured:
- Properly guarded by the
heartbeatDisableflag- Ticker cleanup via
defer ticker.Stop()- Non-blocking send with logging when channel is full
- Clean context cancellation handling
pkg/client/cloudevents/grpcsource/watcherstore.go (5)
76-114: LGTM!The
GetWatchermethod properly propagates the context to all internal calls (PageList,registerWatcher, and logging), maintaining consistency with the context-aware pattern.
128-152: LGTM!The
Getmethod correctly propagates context to the API call and uses it for operation ID retrieval, enabling proper request tracing.
156-192: LGTM!The
Listmethod properly threads the context through toPageListand logging calls.
194-197: LGTM!The unused
ctxparameter (indicated by_) is acceptable for this no-op stub method that exists to satisfy an interface.
287-301: LGTM!The
registerWatchermethod properly propagates context tonewWorkWatcherand logging.go.mod (3)
58-60: Pre-release dependencies updated - verify stability.The open-cluster-management.io dependencies have been updated to newer pre-release versions (dated January 2026). Pre-release versions may be less stable than official releases. Ensure these versions are tested and compatible with the heartbeat functionality changes.
29-29: LGTM on routine dependency updates.The minor and patch version updates for gomega, Kubernetes packages, and go-openapi packages appear routine and should maintain backward compatibility.
Also applies to: 51-55, 98-100, 197-199
127-127: The mailru/easyjson version update from v0.7.7 to v0.9.0 is an indirect dependency that does not require action. Release notes for v0.9.0 indicate only Go version compatibility updates and bugfixes with no documented breaking changes. The dependency chain remains stable through existing direct dependencies like sentry-go.
| go.opentelemetry.io/otel/trace v1.39.0 | ||
| golang.org/x/oauth2 v0.32.0 | ||
| google.golang.org/grpc v1.77.0 | ||
| google.golang.org/grpc v1.78.0 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
gRPC v1.78.0 release notes changelog heartbeat
💡 Result:
Short answer: There is no published full v1.78.0 core release notes entry that documents a new "heartbeat" change — only prerelease artifacts exist (v1.78.0-pre1). The official gRPC keepalive/heartbeat behavior is still described in the Keepalive guide and previous release notes (e.g. grpc-java notes for recent versions include keepalive/too_many_pings fixes). See sources below.
Sources:
- grpc core releases page (shows v1.78.0-pre1 as prerelease). [1]
- RubyGems listing for grpc (v1.78.0.pre1 artifacts, Jan 7, 2026). [2]
- gRPC Keepalive (heartbeat / PING) documentation. [3]
- Example: grpc-java v1.77.0 release notes mentioning keepalive/too_many_pings fix. [4]
If you want, I can:
- fetch the full CHANGELOG/PR list for the v1.78.0 tag for a specific language (C, Go, Java, Python, etc.), or
- scan the grpc/grpc PRs since v1.77.0 for any keepalive/heartbeat-related changes. Which would you prefer?
🌐 Web query:
google.golang.org/grpc v1.78.0 security vulnerabilities CVE
💡 Result:
Short answer: No known CVEs specifically affecting google.golang.org/grpc v1.78.0.
Details:
- The notable CVE-2023-44487 (HTTP/2 “rapid reset” DoS) affected older grpc-go releases and was patched in 1.56.3 / 1.57.1 / 1.58.3 and included in later releases (>=1.59.0). (github.com)
- Vulnerability trackers (Snyk / package listings) show no direct vulnerabilities listed for the current 1.78.0 release. (security.snyk.io)
If you want, I can (a) produce a short SBOM of CVEs affecting any grpc-go versions you care about, or (b) re-scan public trackers for any new advisories after Jan 12, 2026.
Citations:
- 1: https://github.com/grpc/grpc-go/security/advisories/GHSA-m425-mq94-257g?utm_source=openai
- 2: https://security.snyk.io/package/golang/github.com%2Fgrpc%2Fgrpc-go?utm_source=openai
🏁 Script executed:
# Check gRPC versions and releases through pkg.go.dev
curl -s "https://pkg.go.dev/google.golang.org/grpc@v1.78.0" 2>/dev/null | head -100 || echo "Direct API access limited"
# Alternative: Check go module repository
echo "=== Checking gRPC module versions ==="
rg "google.golang.org/grpc" . --type go --max-count 5
# Check if there are any other references to gRPC configuration or heartbeat
echo -e "\n=== Searching for heartbeat or keepalive references ==="
rg "heartbeat|keepalive|Keepalive" . --type go -i | head -20Repository: openshift-online/maestro
Length of output: 7800
Verify gRPC v1.78.0 availability—only prerelease artifacts (v1.78.0-pre1) are currently published.
gRPC v1.78.0 appears to exist only as a prerelease (v1.78.0-pre1) with no published stable release. The go.mod dependency on the stable v1.78.0 may fail to resolve. Confirm whether v1.78.0 is intended, or use v1.77.0 or another available stable release.
Additionally, the codebase already implements heartbeat functionality via google.golang.org/grpc/keepalive (imported in grpc_server.go and grpc_broker.go) with existing configuration flags (HeartbeatCheckInterval, HeartbeatDisable) in pkg/config/grpc_server.go. No new heartbeat features are documented for v1.78.0. No CVEs affect this version.
🤖 Prompt for AI Agents
In @go.mod at line 45, The go.mod entry pins google.golang.org/grpc to v1.78.0
which appears to be unavailable as a stable release; confirm the intended grpc
version and update go.mod to a published release (e.g., v1.77.0) or to the
specific prerelease tag if that was deliberate, then run the appropriate go
get/Go modules tidy to resolve deps; note that no new heartbeat API is required
in grpc_server.go or grpc_broker.go because existing heartbeat support uses
google.golang.org/grpc/keepalive with config flags HeartbeatCheckInterval and
HeartbeatDisable, so do not add heartbeat code—only correct the grpc module
version to a valid published tag.
There was a problem hiding this comment.
I'm confusion... it seems that the go-grpc has a stable release https://pkg.go.dev/google.golang.org/grpc@v1.78.0
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
google.golang.org/grpc v1.78.0 stable release January 2026
💡 Result:
No — as of January 12, 2026 there is no stable google.golang.org/grpc v1.78.0 release. The golang/grpc package on pkg.go.dev shows v1.77.0 as the current released version [1], and the upstream gRPC repository only has a v1.78.0-pre1 prerelease (Dec 25, 2025), not a stable v1.78.0 release. [2]
Sources:
- pkg.go.dev listing for google.golang.org/grpc (Version = 1.77.0). [1]
- grpc/grpc GitHub releases (v1.78.0-pre1 published Dec 25, 2025). [2]
🏁 Script executed:
#!/bin/bash
# Check if v1.78.0 actually resolves in Go modules
echo "=== Checking if google.golang.org/grpc@v1.78.0 resolves ==="
go list -m -versions google.golang.org/grpc 2>&1 | tail -5
echo -e "\n=== Attempting to fetch v1.78.0 specifically ==="
go list -m google.golang.org/grpc@v1.78.0 2>&1
echo -e "\n=== Checking latest version ==="
go list -m google.golang.org/grpc@latest 2>&1
echo -e "\n=== Fetching pkg.go.dev page for v1.78.0 ==="
curl -s "https://pkg.go.dev/google.golang.org/grpc@v1.78.0" | grep -A 5 -B 5 "Version" | head -20
echo -e "\n=== Current go.mod entry ==="
grep "google.golang.org/grpc" go.mod
Length of output: 3322
@skeeey You're absolutely right, and I apologize for the confusion! 🙏
The script execution confirms that v1.78.0 is indeed a stable, published release and is currently the latest version:
go list -m google.golang.org/grpc@latest
google.golang.org/grpc v1.78.0
The version resolves correctly in the Go module system, and pkg.go.dev shows it with the "Latest" badge. My earlier comment was based on incorrect information from web search results that appear to have been outdated.
The dependency bump from v1.77.0 to v1.78.0 is perfectly fine. There's no issue with this change in your go.mod file.
Thank you for catching this error, and sorry for any confusion my initial review caused!
There was a problem hiding this comment.
the keepalive and heartbeat is different things for grpc server
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
gRPC keepalive vs application heartbeat difference
💡 Result:
Short answer
- gRPC keepalive = transport-level HTTP/2 PINGs (managed by gRPC stack) to detect/keep open idle connections and trigger connection close when PINGs aren’t ACKed. Configured with KEEPALIVE_TIME, KEEPALIVE_TIMEOUT, etc.; requires coordination with the server and can be rejected or limited by proxies/servers. [1]
- Application heartbeat = application‑level RPC/message you send inside your protocol (e.g., “heartbeat” RPC or periodic ping message). It’s visible to app logic, can carry semantic/health data, and is controlled entirely by your app (retries, auth, backoff). It won’t be treated as an HTTP/2 PING and may not prevent idle timeouts in intermediaries. [1][2]
Key differences (concise)
- Layer: keepalive = transport/HTTP2; heartbeat = application layer. [1]
- Purpose: keepalive ≈ keep connection alive / detect broken TCP/HTTP2 channels; heartbeat ≈ check service liveness, health, application-level readiness. [1]
- Visibility: keepalive is transparent to app (handled by gRPC runtime); heartbeat is part of your API and seen by service code. [1]
- Intermediaries: proxies/load-balancers may drop or suppress keepalive PINGs or impose limits (so PINGs can be ignored or proxied differently); application heartbeats are normal RPCs and more likely to traverse proxies intact but still count as application traffic. [2]
- Control & semantics: keepalive is coarse (interval, timeout, permit-without-calls) and can cause GOAWAY/connection close if misused; heartbeat lets you implement richer semantics (health codes, retries, partial failure handling). [1][3]
- Cost and safety: aggressive keepalive can increase load or trigger “too_many_pings”/GOAWAY from servers; application heartbeats let you throttle/Backoff in-app. [1][3]
When to use which
- Use gRPC keepalive when you need the runtime to detect dead/idle TCP/HTTP2 connections (e.g., to prevent NAT/proxy idle close) and you can coordinate settings with service owners. [1]
- Use application heartbeat when you need application-level health info, custom semantics, or want to avoid transport-level side effects (and when you need the heartbeat to be part of service contract). Use both if you need transport liveness plus app-level health. [1]
Sources
[1] gRPC Keepalive docs. (gRPC official). (grpc.io)
[2] Examples/behavior with proxies (Envoy) where keepalive PING semantics differ and can hide connection loss. (github.com)
[3] gRPC issue discussions about limits and server GOAWAY/too_many_pings behavior. (github.com)
If you want, I can show recommended config patterns (examples) for keepalive vs an application heartbeat RPC.
Citations:
- 1: https://grpc.io/docs/guides/keepalive/?utm_source=openai
- 2: gRPC streaming keepAlive ping never fails when proxied through Envoy envoyproxy/envoy#2086
- 3: Client keepalive stops sending pings after 2 attempts grpc/grpc#25722
@skeeey You're absolutely right, and thank you for the clarification! 🙏
I apologize for the confusion in my previous comments. gRPC keepalive and application-level heartbeat are indeed different concepts:
gRPC keepalive operates at the transport/HTTP/2 layer—it uses HTTP/2 PING frames managed by the gRPC runtime to detect dead connections and prevent idle timeouts, and it's transparent to application code.
Application heartbeat (what this PR implements) operates at the application layer—these are custom messages/events sent through your protocol that are visible to your service logic and can carry semantic/health data.
Your PR correctly implements application-level heartbeat messages in grpc_server.go by:
- Adding a
HeartbeatDisableflag to control whether heartbeat events are sent - Using a ticker to emit periodic heartbeat events through the gRPC stream
- Making this behavior configurable at the application level
This is completely separate from gRPC's transport-level keepalive mechanism, and the --heartbeat-disable flag appropriately controls this application-level feature.
The go.mod bump to gRPC v1.78.0 is fine (as confirmed earlier), and your heartbeat implementation is appropriate for application-level health signaling. Sorry again for the earlier confusion!
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
cmd/maestro/server/grpc_broker.go (1)
62-63: Consider propagating context instead of usingcontext.Background().The
Listmethod signature doesn't accept a context, but it now callss.resourceService.List(context.Background(), listOpts). SinceListis part of an interface that may be called in contexts where cancellation or timeouts matter, consider updating the interface to accept a context parameter, similar to howGetandHandleStatusUpdatealready do.Using
context.Background()means the operation cannot be cancelled and won't respect request timeouts or deadlines.♻️ Suggested improvement
// List the cloudEvent from the service -func (s *GRPCBrokerService) List(listOpts types.ListOptions) ([]*ce.Event, error) { - resources, err := s.resourceService.List(context.Background(), listOpts) +func (s *GRPCBrokerService) List(ctx context.Context, listOpts types.ListOptions) ([]*ce.Event, error) { + resources, err := s.resourceService.List(ctx, listOpts)
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Cache: Disabled due to data retention organization setting
Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (9)
cmd/maestro/server/grpc_broker.gocmd/maestro/server/grpc_server.gogo.modpkg/client/cloudevents/grpcsource/watcherstore.gopkg/config/grpc_server.gopkg/services/resource.gopkg/services/resource_test.gotest/performance/pkg/hub/store/createonly.gotest/store.go
🚧 Files skipped from review as they are similar to previous changes (3)
- pkg/config/grpc_server.go
- pkg/services/resource_test.go
- test/store.go
🧰 Additional context used
🧬 Code graph analysis (2)
pkg/services/resource.go (3)
pkg/api/openapi/model_list.go (1)
List(23-28)pkg/db/migrations/202311151850_add_resources.go (1)
Resource(10-24)pkg/api/resource_types.go (1)
Resource(14-27)
pkg/client/cloudevents/grpcsource/watcherstore.go (2)
pkg/client/cloudevents/grpcsource/pager.go (1)
PageList(22-84)pkg/logger/operationid_middleware.go (1)
GetOperationID(59-64)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
- GitHub Check: Red Hat Konflux / maestro-on-pull-request
- GitHub Check: Red Hat Konflux / maestro-e2e-on-pull-request
- GitHub Check: e2e-grpc-broker
- GitHub Check: e2e
- GitHub Check: e2e-with-istio
- GitHub Check: e2e-broadcast-subscription
- GitHub Check: upgrade
🔇 Additional comments (17)
test/performance/pkg/hub/store/createonly.go (1)
21-23: LGTM!The method signatures have been correctly updated to accept
context.Contextas the first parameter, aligning with the broader interface changes for context propagation across the store/watcher APIs. The stub implementations appropriately leave the context unused since they return unsupported errors or nil values.Also applies to: 43-45, 47-49, 51-53
cmd/maestro/server/grpc_broker.go (1)
187-190: LGTM!The broker options are correctly wired to pass the heartbeat configuration from the server config, enabling runtime control over heartbeat behavior.
cmd/maestro/server/grpc_server.go (3)
46-47: LGTM!The new
heartbeatDisablefield is appropriately added to the struct alongside the existingheartbeatCheckIntervalfield.
147-148: LGTM!The
heartbeatDisablefield is correctly initialized from the configuration.
351-375: LGTM!The conditional heartbeat logic is well-implemented:
- Ticker is properly cleaned up with
defer ticker.Stop()- Context cancellation is correctly handled for graceful shutdown
- Non-blocking send to
heartbeatChprevents the goroutine from blocking when the channel is full- The log message at line 368 provides visibility when heartbeats are dropped
pkg/services/resource.go (2)
36-36: LGTM!Adding
ctx context.Contextto theListmethod signature aligns with the other methods in theResourceServiceinterface and enables proper context propagation for cancellation and timeout handling.
327-328: LGTM!The implementation correctly propagates the context to the underlying DAO method
FindByConsumerName, enabling cancellation and timeout support at the database layer.pkg/client/cloudevents/grpcsource/watcherstore.go (6)
76-114: LGTM!Context is properly threaded through
PageList,registerWatcher, and logging calls. This aligns well with the broader context-passing pattern for tracing and operation-scoped metadata.
128-152: LGTM!The context is correctly used for the API request, operation ID extraction, and logging. This enables proper request cancellation, deadline propagation, and log correlation.
156-192: LGTM!Context threading through
PageListand logging is consistent with the other methods.
194-197: LGTM!Using
_for the unused context parameter is idiomatic Go. The no-op behavior is intentional and documented.
287-301: LGTM!Context is properly threaded to watcher creation and logging. The metric increment not using context is appropriate.
218-254: Verify:Sync()intentionally retainsm.ctxusage.Unlike the other methods (
GetWatcher,Get,List) that were updated to accept a context parameter,Sync()still uses the struct-levelm.ctx. This appears intentional sinceSync()is a background operation not tied to a specific request context.Please confirm this is the intended behavior, or consider updating
Sync()to accept a context parameter if callers should be able to control cancellation/deadlines.go.mod (4)
127-127: No action needed — easyjson v0.9.0 is stable.The version jump from v0.7.7 to v0.9.0 is a normal minor version update with no breaking changes. Release notes confirm only a Go version bump and bug fixes. The update is safe.
45-45: Verify gRPC v1.78.0 is intentional and check for breaking change impact.The search results show that v1.78.0 is currently available only as a pre-release (
v1.78.0-pre1), not a final release. Additionally, grpc-go v1.78.0 introduces a breaking change: the client now rejects target URLs with unbracketed colons in hostnames (e.g.,dns://::1/foo.bar.commust now bedns://[::1]/foo.bar.com) due to Go 1.26's stricter URL parsing.Confirm whether the pre-release version was intentional, and verify that any gRPC DNS targets or IPv6 addresses in the codebase use properly bracketed hostnames to avoid connectivity failures.
51-55: All Kubernetes library packages at v0.34.3 are valid and stable. The consistent patch update from v0.34.2 to v0.34.3 across k8s.io/api, apimachinery, apiserver, client-go, and component-base has been verified. v0.34.3 corresponds to Kubernetes 1.34.3, a stable release from December 2025. This is a low-risk patch update that follows best practices for keeping tightly coupled Kubernetes libraries in sync.
58-60: Confirm necessity of pre-release OCM dependencies.The Open Cluster Management dependencies are using pseudo-versions (v1.1.1-0...) for unreleased commits. Stable v1.1.1 releases do not yet exist for these packages (latest published is v1.1.0).
Pseudo-versions are a valid Go pattern for depending on specific upstream commits, but confirm this is intentional for your use case and that the features/fixes in these pre-release versions are necessary. If the needed functionality is already available in v1.1.0 or earlier stable releases, prefer those instead to avoid depending on development commits.
|
/cc @clyang82 |
Signed-off-by: Wei Liu <liuweixa@redhat.com>
2 participants
No description provided.