-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Logviewer ? #6
Comments
It's possible, but it's not wired up. As always, PRs are welcome. |
I still haven't managed to get storm to work on mesos, despite days of efforts, so first things first.. :) |
IIRC, click logviewer link from nimbus web ui will always try to connect to a constant port (8080? not for sure now), however, mesos launch supervisor in a unique and random generated directory, so the logviewer can't(maybe hack in some way) figure out where to find the correct worker's log. |
Certainly that could be fixed. |
@yaronr give me about a week to finish up and I'll post how I got it all running ontop of mesos + marathon without hardcoding the nimbus master or anything. The gist of it is:
All of this and I actually don't run it in docker, but natively under marathon, by downloading the built storm distribution and the run-storm.py via the In a perfect world, the framework would support a lot of this natively, but I'm a python/golang/c guy, and have never taken a serious stab at java. |
SEJeff - Could we use something like mesos-dns to indicate where the nimbus is located? It works well for Myriad and may work well here. |
It kind of defeats the point of mesos to require hard coding masters that might change. Mesos DNS is a reasonable workaround, as is my solution of having a python script write to ZK before starting nimbus and another to read from nimbus before starting storm ui. The framework should do this natively. |
Makes sense that the framework should do it natively, I was just suggestion the mesos-dns as a way that the nimbus/ui could be run from any node (given access to the code to run it) and where it landed wouldn't matter to the supervisors as they are pointing to a static name that resolves to a dynamic IP. |
True. Thanks for the suggestion |
Wouldn't the most straight forward approach be to have the supervisor/executor fire up the logviewer when mesos fires it up? If no one is working this I would like to get the logview working under mesos. |
I've raised an issue with how the PR #38 will handle multiple MesosSupervisors / topologies being scheduled onto the same mesos-slave host, please see: #38 (comment) My proposal for the immediate future is to back out #38 , but I'm not sure what we should do long-term. I have some off-the-cuff thoughts here: #38 (comment) Would appreciate others weighing in with their thoughts. |
I've filed a ticket against the Apache Storm project to add support for multiple container-specific logviewers: STORM-1342, thus allowing us to close PR #51. Will require discussions with the Storm PMC type people to try to come to an acceptable design, I'm not planning on working on that in the next couple of months. |
Hi
I would like to access the storm logviewer on one of the supervisors.
How do I do that?
(AFAIK the supervisors are started by mesos)
Thanks
The text was updated successfully, but these errors were encountered: