July 10, 2026

[cassidyjames]

Our next bi-weekly working group call will be July 10, 1730–1830 UTC!

• Google Meet
• #osprey in the ROOST Discord
• Discord event series

Proposed discussion topics:

• PRs needing review
• LLM interface
• RFC: Rule authoring in the UI as a thin client over git PRs? #394
• 1.1.0 milestone planning/triage
• Anything else that can be upstreamed?
• Adopter feedback/topics

As always, feel to comment below with any additional agenda items or discussion topics. See you there!

[julietshen]

Also for the agenda/FYI - I'm going to try and finish #236

[cassidyjames]

Attendees: @cassidyjames, @haileyok, @julietshen, @EXBreder, @chimosky, @ThisIsMissEm, @ThatKoffe, @selena-lustig

Notes

PRs needing review

• Make Osprey runnable without GCP credentials (tracking) #343 is the parent issue for all things needed for Osprey to work without GCP credentials
  • feat(publisher): degrade PubSubPublisher to noop when GCP credentials are absent #388 PubSubPublisher GCP
    • @julietshen is refactoring in response to @ThisIsMissEm’s review
    • There's several places where we have a GCP Project ID, that's due to some adopters dividing up projects, so we can't infer a flag from the absence of that configuration property
    • For the configuration flag here, we can lift it upwards, so PubSubProducer doesn't have any enable/disable state, since the auth is only checked once at init, it could throw an exception that the construction site catches and swap out for NullProducer there. Then the configuration flag is a general OSPREY_PUBSUB_ENABLED boolean, and the code just checks if that's set to true, if not it returns NullProducer instead of dropping into PubSubProducer.
  • Without gcp #401 is a draft PR for not requiring GCP. Need feedback from people more familiar with this setup
    • @haileyok may be able to look next week
  • Rules visualizer analytics: could have an ENABLED flag for this as well?
    • This is apparently really old… maybe we open a new issue to refactor/remove this?
  • For BigQuery, we could have a OSPREY_BIGQUERY_ENABLED or OSPREY_ANALYTICS_ENABLED
  • Jslog4kube and ddtrace could also be split out of Make Osprey runnable without GCP credentials (tracking) #343 to separate issues, as they're not strictly GCP related
• Kafka-related PRs: unsure what the status is; no response from VINODvoid on make kafka topic creation and partition config configurable via env vars #255; might be resolved?
  • @julietshen to take a look
• Add osprey-stress CLI (closes #324) #367 is ready, needs an approving review
  • Minor conflict to resolve in CHANGELOG
• Bump protobuf 4.25.8 → 5.29.6 #349 also bumps GRPCIO version, may be unblocked by Add osprey-stress CLI (closes #324) #367
  • @julietshen can test this a bit
  • @haileyok left some recommendations; maybe it makes more sense to split into separate PRs to bump GRPC and protobuf separately?
  • Can someone (@reitblatt? ROOSTer?) do a spike to see if this can be separated?
  • @cassidyjames to take a look and poke @reitblatt
• Replace Highcharts with Apache ECharts in Timeseries chart #374 if the UI looks fine, we’re happy to merge
• Dependabot
  • @julietshen to audit packages that need to be upgraded; see if there’s anything left that’s actually unused in upstream Osprey

Next release: 1.1

• LLM powered querying + interface
  • Add pluggable LLM API provider hook with tool calling #337 still a draft, how can we help move it forward? 🥹
    • Probably demoable for TrustCon as “the direction things are going” but not merged yet; still very experimental
  • Created LLM Interface for AI-assisted query building and investigations #412 to track UI work for AI-assisted queries and investigations
    • Output of LLM rules would go into same rules db as Add in-app rule authoring backed by a draft rules table #402’s rules authoring flow
• Milestone review
  • Add linting #130 is vague; need to revisit
• RFC: rule authoring/editing in the UI Add in-app rule authoring backed by a draft rules table #402
  • Rule authoring UI looks good/makes sense!
  • Code forge integration might be overkill; maybe could instead add a “draft rules” table
    • For Discord and Bluesky it might make sense, but from an ease of deployment standpoint it might still not be great; merging the PR doesn’t actually deploy the rules
      • We don’t currently have an example of etcd deployment right now
    • GitHub credential access is awkward; either the submitter needs to sign in w/GitHub and needs to have access to the repo, etc. or if it’s using a shared/programmatic GitHub account, the submitter might not be able to see the opened PR.
    • Could be a “rules” table, with a “status” column for draft; would make it easier to build on i.e. for an approval process, background status, etc.