Get rid of the v1 codebase
codefromthecrypt opened this issue · 11 comments
We don't have a lot of hands to do "huge maintenance work". There was a lot of demand for a v2 format, so we released a v2 core library as soon as we could (september 2017).
With this in place, we were able to decouple libraries from the v1 codebase. This included brave and zipkin-reporter, which no longer have mandatory dependencies on it. However, there's still a large amount of work to do. This issue tracks that work:
- Port mysql (as-is) to the zipkin2 codebase, or redo it
- Port "cassandra" (as-is) to the zipkin2 codebase, or drop it
- Remove zipkin v1 dep from zipkin-junit and repackage under io.zipkin.zipkin2 namespace
- Make a new collector, which accepts even the old v1 thrift: make the server depend on it.
- redo all the storage tests to port to v2 codebase
- implement the zipkin UI in v2 javascript (implies clock skew and merge logic)
Making this issue was Influenced, but not caused by a strange recent flurry of issues #2044 #2045 #2046 It has always been implicitly on the backlog
cc @openzipkin/core @shakuzen @marcingrzejszczak @devinsba I will start on this when I return from holiday 21 May
here's a corresponding issue in brave openzipkin/brave#699
@adriancole Enjoy your vacation~
@tbwork thanks tons! enjoying the last of it now :)
PS thought while away:
io.zipkin.zipkin2:zipkin-collector could be a new java 8+ only jar. The only consumer of this code is the server, which is java 8 anyway. This will make things easier as formerly there was tension about the codebase which is only used by the server/collector.
Note: A future version of this collector could do reactive streams (1.0 or via java 9) or other fanciness, but I don't think we should do that now. There is so much work just to migrate off the v1 code we should make sure this completes before working on candy.
#2066 is the conversion library.. need to vet this through storage and the dependency linker code
Rogar that!
storage are converted. next step is to make the server not require zipkin v1 storage component, which simplifies autoconfig. This also implies redoing autoconfig to not export it either.
managed a huge chunk while on a flight. this refactors the server to only use v2 storage beans (note that v1 bridging is still here until collector v2 is done) #2077
Next big chunk is a migration of the colletor code #2078 once this is merged, no remote repositories need to use io.zipkin.java dependency indirectly or directly. Before release, I'll sweep through the server and remove the last things that use old code. Will probably do one last release with io.zipkin.java:zipkin and after that stop publishing it.
For those following along, the zipkin v1 library is now only a test dependency, except in the server, as of v2.9 The server still uses it to present v1 read endpoints. As these are only used by the UI, the path of least resistance is to move the clock skew etc code into the UI, so that it can start reading the v2 endpoints only. This would allow us to decommission the read endpoint of the v1 api, even if we continue to support the v1 POST endpoint on the server.
Supporting the v1 read endpoint on the server is maintenance better spent elsewhere. Once we've migrated the UI, the only consumer of it would be alternative UIs, which themselves could copy/paste or otherwise the conversion code. This is a lot better than supporting 2 read endpoints in Java imho.
camel no longer uses v1 libraries: apache/camel#2383