fabric8 has working kubernetes-zipkin about zipkin-kubernetes HOT 25 CLOSED

@xh3b4sd https://github.com/fabric8io/kubernetes-zipkin is still leading the charge on this, so I'd use their images until/unless something is extracted here.

from zipkin-kubernetes.

That's great! :-)

from zipkin-kubernetes.

sorry somehow wasn't watching the repo :P So this, has certainly stalled out. how should we proceed? @davsclaus would you be open to moving that repo over to openzipkin org where it would be more visible? existing committers could keep access

from zipkin-kubernetes.

In general I think that its a good idea to move the repo to zipkin, but I think also need to check what we have there and what makes sense to move under the openzipkin umbrella.

1. maven based projects that generate kubernetes configuration for zipkin (release includes generated conf).
2. a custom maven image for openzipkin mysql (this should also be contributed back).
3. starter modules that aggregate kubernetes configuration into basic distros (minimal, mysql, dev).
4. basic system tests for (3) using fabric8-arquillian.
5. packing for use in the fabric8 console.
6. example.
7. jenkins pipeline scripts for releasing.

What do you guys think?

from zipkin-kubernetes.

from zipkin-kubernetes.

Just to clarify... What we've put together is something that has no runtime dependency on fabric8 and it can just run straight on vanilla kubernetes. The user can just grab the released artifacts and just use them from the command line using just kubectl.

Still the configuration is generated by maven tooling and thats something that makes perfect sense for us, but that may not be the case for everyone. I guess we could have the generated artifacts in the top-level directory and keep the generators in a subdirectory were someone can run them optionally (not as part of a build/release process). We could do the same for the integration/system tests too.

So the structure could look like this:

 zipkin-kubernetes
            |
            |
            +---codegen
            |       |
            |       +---collector
            |       +---mysql
            |       +---query
            |       +---cassandra
            |
            +----tests
            |
            +---zipkin-mysql.json
            +---zipkin-mysql.yaml
            +---zipkin-dev.json
            +---zipkin-dev.yaml

For the rest I don't have a strong opinion.

from zipkin-kubernetes.

and I almost forgot.... @adriancole its been a while... and its always a pleasure :-)

from zipkin-kubernetes.

from zipkin-kubernetes.

@iocanel thanks for clearing this up.

Firstly, this work is pretty darned cool. I especially like the arquillian integration. We have some similar things in the new server, to make sure we don't pass tests unless packaging works. That works, even if not as elegant as arquillian. We have nothing like this in docker, but desperately need it because there have been problems.

There have been some changes since you'all started wrt config, and while the new server's not complete, yet, we will want to focus on the new codebase which for example supports elasticsearch etc. For example "dev" doesn't exist, although an in-memory, or otherwise no-args server could be called dev. Regardless, we should work off what the new server has, as some of it might be easier to do with properties vs env variables depending..

Regardless, I think if we are working on something that's using the recent codebase, that adds sustainable support for k8s, and.. has integration tests?! that's be fantastic. I can help test.

from zipkin-kubernetes.

On the Jenkins vs Travis thing. I've not used modern jenkins, especially the pipeline thing. It looks cool, but @abesto should probably want to be on board as he usually ends up involved :)

https://github.com/fabric8io/kubernetes-zipkin/blob/master/Jenkinsfile

from zipkin-kubernetes.

ps @niccaluim I know you raised the original PR on k8s, and @smreed tried it. you folks have stake in this discussion

from zipkin-kubernetes.

Oh hi. This sounds extremely cool.

Thanks for the mention. On the CI end of things, I think there's no cause for worry :) I'd probably push for migrating the build / release process to Travis, both for consistency and availability (we don't have a Jenkins cluster set up, and I don't know of a provider that gives OSS projects free, public Jenkins infra). I expect most of the work there will be merging the existing logic currently in the Jenkins pipeline, and the conventions that are emerging in the Zipkin release process.

If there are no objections to this course of action, then I think CI will be fine. If it sounds bad for some reason, then let's figure out what to do there :) Everything can be solved.

from zipkin-kubernetes.

@adriancole we took a while to respond as we have been traveling to a face to face meeting in the fabric8 team. Good to hear you guys are discussing this, @iocanel is the right person to be involved.

from zipkin-kubernetes.

@abesto: on top of the jenkins cluster requirement, I forgot to mention that our pipeline scripts also require a k8s environment, so most probably we should exclude that for now...

from zipkin-kubernetes.

This looks interesting. We are currently deploying zipkin into our Kubernetes cluster with yaml we've adapted from the docker-zipkin project. The fabric8 starter artifacts look nice. If we were to adopt them, frankly, we would probably just copy the yaml files into our own internal repo and make some modifications (namespace, service labels and annotations, the like). So consider this a vote for @iocanel's suggestion of a layout that makes the yaml the focus, and the tooling to generate it an optional subdirectory.

from zipkin-kubernetes.

Hey folks, the big server transition is now complete, so probably a good time to pick this up (even if I'm headed to holiday :))

https://github.com/openzipkin/docker-zipkin

from zipkin-kubernetes.

So, how are we going to proceed?

Would you like me to create a PR?

from zipkin-kubernetes.

@iocanel yeap I don't think things will progress without it. My main thing is to ensure the server is the current codebase (as it doesn't have separate images for collector, query, web anymore).

I can review and test any changes (or at least attempt!)

from zipkin-kubernetes.

Having a single image now makes things easier!

from zipkin-kubernetes.

Hey there. Is there any progress on this issue? I would like to play around with a full Zipkin stack on Kubernetes.

from zipkin-kubernetes.

The fabric8 repo is still active, and has cool stuff like Prometheus integration, while this repository is still empty. Maybe we should just delete this repository (and maybe "officially" endorse https://github.com/fabric8io/kubernetes-zipkin)?

from zipkin-kubernetes.

The main issue with the https://github.com/fabric8io/kubernetes-zipkin is that I have been the main contributor and I don't have the cycles to maintain it.

I think that moving those stuff here is most probably the best option.

from zipkin-kubernetes.

Oh, I see. That's indeed a problem, especially since I don't know of any active Kubernetes-using core Zipkin contributors, so just moving to under openzipkin won't necessarily improve things by itself. Not sure on what the implications are of moving / not moving, wrt. expectation management of users. @openzipkin/devops-tooling halp?

from zipkin-kubernetes.

from zipkin-kubernetes.

I'm moving this repo to the attic as there's been no pickup in activity

from zipkin-kubernetes.