Open cisaacstern opened 2 years ago
IMHO this path makes a lot of sense, and the questions above are good ones to frame implementation.
To state one perhaps obvious idea, design-wise it makes sense to me for to add a placeholder Bakery.get_logs
method to the base bakery, as is done for:
and then have each bakery type override this method with its own implementation. For DataflowBakery
, there's already an assumption (though not a requirement) that the gcloud
CLI will exist (and be authenticated) in the environment, so perhaps fetching logs via subprocess calls to gcloud
would be a good default pathway for DataflowBakery.get_logs
?
lack of security around the
pangeo-forge-orchestrator
endpoints
We do have the ability to lock certain endpoints with authentication headers (and already do so for create/delete/update operations). Certainly we could do so for these endpoints as well (or a subset of them), and let https://pangeo-forge.org authenticate via a next.js server-side call. That being said, this approach doesn't really change the fact that the logs will eventually be publicly queryable (whether the user is querying directly, or with https://pangeo-forge.org as an intermediary).
Just made a few notes on this subject in https://github.com/pangeo-forge/pangeo-forge-orchestrator/pull/150#issuecomment-1269253104. Specifically, the fetch_logs
executable as part of that PR (adapted from some code @yuvipanda shared) would be great basis for this feature.
Reposting @sharkinsspatial's comment from https://github.com/pangeo-forge/registrar/issues/53#issuecomment-1232274752 here, since I believe this will be the best place to discuss this topic going forward: