Skip to content

Add a handler to the WebRTC operator for context.#2431

Open
3405691582 wants to merge 1 commit intogoogle:mainfrom
3405691582:context
Open

Add a handler to the WebRTC operator for context.#2431
3405691582 wants to merge 1 commit intogoogle:mainfrom
3405691582:context

Conversation

@3405691582
Copy link
Copy Markdown
Collaborator

We may be running in environments where only the WebRTC operator is exposed. This can make it difficult to verify information about that environment; for example, is the operator (and cvd, etc.) running in a container, or not? One simple way to do this is to expose an endpoint on the operator for debugging purposes, and one simple way to get information about the environment is to expose the hostname.

For now, we just expose the hostname, but it may be worthwhile adding extra fields in the future.

Bug: 503333785

We may be running in environments where only the WebRTC operator is
exposed. This can make it difficult to verify information about that
environment; for example, is the operator (and cvd, etc.) running
in a container, or not? One simple way to do this is to expose an
endpoint on the operator for debugging purposes, and one simple way
to get information about the environment is to expose the hostname.

For now, we just expose the hostname, but it may be worthwhile adding
extra fields in the future.
@3405691582 3405691582 requested a review from ser-io April 21, 2026 16:05
@jemoreira
Copy link
Copy Markdown
Member

jemoreira commented Apr 21, 2026

for example, is the operator (and cvd, etc.) running in a container, or not?

You should know this from the environment you're running on, not from the operator. It should be possible for the owners of said environments to hide those details from the user, so the operator should not expose them.

It would only be ok to expose this info the Cloud Orchestrator, when requesting details about a host.

@3405691582
Copy link
Copy Markdown
Collaborator Author

for example, is the operator (and cvd, etc.) running in a container, or not?

You should know this from the environment you're running on, not from the operator. It should be possible for the owners of said environments to hide those details from the user, so the operator should not expose them.

It's useful to know something about the environment for debugging purposes.

My other approach would be to use something like the EchoServer as a Schelling point for this information. Is that better, is that also problematic?

router.HandleFunc("/infra_config", func(w http.ResponseWriter, r *http.Request) {
ReplyJSONOK(w, config)
}).Methods("GET")
router.HandleFunc("/context", func(w http.ResponseWriter, r *http.Request) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

There's a endpoint /_debug/varz in HO and I think they aim to achieve the same, if so, let's use the same path for alignment.

http.Error(w, err.Error(), http.StatusInternalServerError)
return
}
ctx := make(map[string]interface{})
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Let's use a defined struct rather than a free form map to keep track of what's being returned.

@ser-io ser-io requested a review from jemoreira April 21, 2026 16:18
}

func getContext(w http.ResponseWriter, r *http.Request) {
hostname, err := os.Hostname()
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Right now we are only querying the hostname. In the future context as a whole should have more information. Wondering whether you can populate context fields that won't change during the lifetime of the operator when the operator starts and the return the already populated struct on every GET request rather than querying the system everytime?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants