I would like to contribute to the logstash project. But, I can't find any ideas related to Logstash on the list. Some of the high hanging open issues, I found were here. Are there any other ideas related to Logstash which I could dive into?
This one looks interesting. But are you all planning to work on this?
Any updates on this? @xeraa
Sorry for the delay! We're at our annual conference in San Francisco right now and everybody has been super busy with this.
The good thing is that @yaauie from the Logstash team volunteered to mentor projects. We'll get back to you early next week with more specific project ideas (I hope ).
I'll be submitting a PR on our GSOC ideas repo shortly for the ideas I have on the Logstash projects, and will follow up here after.
Awesome! Have fun at the conference!
Thanks, @yaauie! Looking forward to the project!
@hvardhan thanks for your patience! Ry has now added https://github.com/elastic/gsoc#logstash_java_plugin_api (thanks for that as well!).
Let us know what you think about that.
@yaauie I have been looking at different discussions and pull requests related to Java Plugin API (#7986).
- What are the popular plugins that you are looking to support? We could pick plugins from each type (Input, Output, Filter, and Codec). Here's a list of plugins sorted according to stars.
- What's the current status of the Java Plugin API?
- Which approach are you all going to follow for the Java Plugin API? Are you all planning to use annotations based approach or try something else?
- We can test the API using other JVM languages like Kotlin, Scala. This would encourage developers from other languages to write a logstash plugin.
The point of the project is to exercise the API, not necessarily to support a specific subset of the existing plugins; we would want a variety of inputs, outputs, filters, and codecs to ensure that each of those APIs was well-exercised. Selecting a variety of pre-existing plugins gives us a pretty good idea of the types of configurations plugins expose to the Logstash Pipeline Configuration format, which should help shape the needs of the API.
There is a Work-In-Progress PR, along with a lot of discussion -- you can take a look at the current approach to build context.
And, because the point of the project is to shape the API, we want to exercise it as much as possible; if the API makes writing plugins in alternate first-class JVM languages unreasonably difficult or awkward, that information may help us to iterate on the API in a way that makes it less awkward overall. Writing the exact same plugin against the API in multiple languages could be a great way to find where it needs to improve
I have added a draft proposal. Please take a look and let me know what you think.