Support for a non-core API working group?
danielhochman opened this issue · comments
My team at Lyft is looking to collaborate on specialized management server APIs with other companies who are using Envoy or in the process of migrating to Envoy. The first example of this for which I would like to form a working group are APIs related to scheduling and monitoring fault injection and red-line tests. There are ~10 engineers interested in joining up as of now.
The desired collaboration tools we have identified so far are:
- GitHub repository for protobufs and design docs (with a small amount of CI resources for linting purposes)
- Google Docs for initial proposal development
- Slack channel
Assuming there is interest in hosting this group in the Envoy organization, I am also seeking input on a name for the repo and Slack channel. So far I have thought of api-contrib or api-working-group, but I definitely want to avoid confusing these APIs with Envoy's core control plane APIs. Maybe management-api-working-group?
I'm supportive of getting this going and I think it's fine to allow iteration on this in a separate repo, but it would be good to clear indicate what is in scope here vs. out of scope so that we don't conflict with other ongoing efforts in UDPA and the core Envoy API. Would it be possible to put together a short 1-2 page proposal of the scope where we could also hash out naming, etc.? Thank you!
cc @envoyproxy/udpa-wg @envoyproxy/api-shepherds
You might also have some interest from @envoyproxy/nighthawk-maintainers when it comes to APIs that are intended for supporting load tests.
I'll get to work on a one-pager. Thanks for your input so far.
I put this together for a propsal. Let me know where you'd like to see more detail.
Thanks @danielhochman. At a high level this proposal looks great to me and I think we should move forward with creating the repo for collaboration. I will let this sit for a few days to see if anyone has any substantive comments.