Outreachy - added initial ideas #224
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -8,7 +8,10 @@ title: 'Outreachy' | |
|
|
||
| The OpenTracing and Jaeger projects are happy to announce our participation in the Outreachy program, running | ||
| from December 2017 to March 2018. As part of this joint effort, we'll be collecting ideas for tasks related to | ||
| OpenTracing, Jaeger or both that would be appropriate for an intern to work on. | ||
|
|
||
| Please see the main [program page](https://outreachy.org) for the general information about the program, such | ||
| as its purpose, timeline, eligibility requirements, and how to apply. | ||
|
|
||
| ## What is OpenTracing | ||
|
|
||
|
|
@@ -54,8 +57,56 @@ Interested in becoming a mentor? Contact one of the coordinators! | |
|
|
||
| ## Available tasks | ||
|
|
||
| ### Instrumentation for mobile applications | ||
|
|
||
| Mentor: Gary Brown | ||
|
|
||
| * Collect ideas on what's possible and what's desirable for mobile applications | ||
| * Decide and experiment with different options for an optimized mobile experience, like, which sampling strategies | ||
| make more sense | ||
| * Create the missing pieces, like OpenTracing framework integration for some Android component, or a specific Jaeger | ||
| tracer for mobile usage | ||
| * Documentation + examples | ||
| * The end result would be: a trace starts when a user opens the app on the phone and backend microservices are called | ||
|
|
||
| ### Split the JavaScript OT library: NodeJS and Browser | ||
|
There was a problem hiding this comment. This is a jaeger specific task I believe @pavolloffay ? There was a problem hiding this comment. Maybe add Jaeger in the title |
||
|
|
||
| Mentor: Pavol Loffay | ||
|
|
||
| * HttpSender which works in a web browser | ||
| * Intercept web browser events (maybe can be done as OpenTracing instrumentation) | ||
|
|
||
| ### Drive consensus on a common format for reporting trace/span data | ||
|
There was a problem hiding this comment. I am not sure this is a good intern project, it requires a lot more experience with the tracing space There was a problem hiding this comment. Reason I thought this might be good is that the intern project is just to document and implement prototype (one or more language tracers/jaeger backend adapter) - guidance on what should be in the standard format should come from the community, so their role would be to request input and feed that into their prototype. The initial starting point would be that it must capture the information provided via the OpenTracing API. There was a problem hiding this comment. If we keep this, could you send a PR to change this page with the outcome of the discussion? There was a problem hiding this comment. Actually "driving consensus" is a tall order for an intern... lots of strong and entrenched opinions in this area, etc, etc. I would suggest reframing this as There was a problem hiding this comment. @yurishkuro Would rewording as @bhs suggests be ok, or would you still prefer it is removed? There was a problem hiding this comment. Yes. Can we add some description? |
||
|
|
||
| Mentor: Gary Brown | ||
|
|
||
|
There was a problem hiding this comment. Would be good to reference this opentracing/specification#86 - although it discusses both in-band and out-of-band, but it sets the context aswell. |
||
| ### OpenTracing MockTracer JUnit rule. | ||
|
|
||
| Mentor: Pavol Loffay | ||
|
|
||
| * Clear reported spans between tests. Automatically assert on errors. | ||
|
|
||
| ### Move community Jaeger tracers to the jaegertracing organization. | ||
|
|
||
| Mentor: Gary Brown | ||
|
|
||
| * This task include writing xdock tests, missing reporters.. | ||
|
|
||
| ### Create OpenTracing API for language not currently supported | ||
|
|
||
| Mentor: Pavol Loffay | ||
|
|
||
| * For instance, for missing Android parts. | ||
|
|
||
| ### Write Jaeger tracer implementation for any OpenTracing API. | ||
|
|
||
| Mentor: Gary Brown | ||
|
|
||
| * C# | ||
| * Kotlin for Android | ||
|
There was a problem hiding this comment. This is funny there is no OpenTracing Kotlin API There was a problem hiding this comment. I believe that Kotlin is a JVM-based language, so, the Java one would work. I'm not sure Kotlin would make sense here, but it's part of the task to figure this out. |
||
|
|
||
| Additionally to the tasks above, we recommend looking at the following issue trackers. You might want to pick | ||
| an easy one before applying, to get a better sense of what the projects are about. | ||
|
|
||
| * [OpenTracing issue tracker](https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+org%3Aopentracing) | ||
| * [Jaeger issue tracker](https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+org%3Ajaegertracing) | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doing mobile instrumentation efficiently is actually a non-trivial engineering project. For example, our mobile team has a whole platform sub-team that built a performance SDK that does clever things like gauging the available network bandwidth from the phone and sending monitoring data via unused bandwidth only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree that to provide a production quality solution will be non-trivial, but this type of project has been popular with GSoC students on Hawkular, and the expectation would only be to provide an initial proof of concept with demonstrator. If it then looks promising, further performance work could be done by more experienced contributors?