Repository navigation
Conversation
A Go web application that renders a greeting page and calls the
go-greeter service to produce the greeting itself:
browser -> webapp-go-greeter -> service-go-greeter
The second hop is the point of the sample. The webapp never hardcodes an
address for the greeter; it reads GREETING_SERVICE_URL, which OpenChoreo
resolves per environment from a declared dependency. With the variable
unset the page still loads and the greeting fails with a readable error.
The response shows which service produced which half of the answer, so
the call chain is visible on the page.
Trace context headers (traceparent, tracestate, baggage, x-request-id and
B3) are copied onto the downstream request, so the two hops join into a
single trace rather than two unrelated ones.
The dependency block in workload.yaml is left commented out, because
declaring it is the exercise in the course lesson on connecting
components. The readiness probe reports on this app only and never checks
the greeter, so a greeter outage cannot take this pod out of service.
Signed-off-by: Ketharan <ketharan.mail@gmail.com>
The sample previously only forwarded trace headers, so it never appeared in a trace backend. It now exports spans over OTLP and writes JSON logs that carry trace_id and span_id, so a log line can be matched to the trace that produced it. - a span for the inbound request and for the outbound call to the greeter, with context propagated so the two hops form one trace - resource attributes for the component, environment and project when OpenChoreo supplies them - tracing is best-effort: disabled when no OTLP endpoint is set, and a warning rather than a failure when the collector is unreachable Go moves to 1.26 in both go.mod and the Dockerfile, which the OpenTelemetry modules require. Signed-off-by: Ketharan <ketharan.mail@gmail.com>
The subtitle described the sample's own two-service topology, which reads as internal detail to anyone opening the page. Replace it with a plain welcome; the response cards still show which service produced which half. Signed-off-by: Ketharan <ketharan.mail@gmail.com>
The response showed which service answered, the resolved upstream address and the round-trip time, and the second line leaned on deployment jargon. That is useful when debugging and out of place for someone who came to say hello. The page now shows just the greeting and a friendly line under it. The service name, upstream address, elapsed time and trace id are still in the JSON response and in the logs, where they belong. Signed-off-by: Ketharan <ketharan.mail@gmail.com>
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
The repository has no sample that consumes another component's endpoint through a declared
dependency. This adds one, so the connect-components flow has something to point at.
Approach
webapp-go-greeteris a Go web application that renders a greeting page and callsservice-go-greeterto produce the greeting:The second hop is the point. The webapp never hardcodes the greeter's address; it reads
GREETING_SERVICE_URL, which OpenChoreo resolves per environment from a declared dependency.With the variable unset the page still loads and the greeting fails with a readable error.
The dependency block in
workload.yamlis left commented out, because declaring it is theexercise. Readiness reports on this app only and never checks the greeter, so a greeter outage
cannot take the pod out of service. Traces are exported over OTLP and logs are JSON carrying
trace_idandspan_id; both are best-effort and disabled when no collector is configured.Related Issues
None.
Checklist