Last modified: 2014-08-04 19:41:44 UTC
Vagrant's role::eventlogging installs the EventLogging extension but it does not run any listener to handle the event stream. Yuvi and I think that the best bet here may be to run the python eventlogging-devserver script via upstart with output redirected to a log in /vagrant/logs. An open question a this point is the "best" way to do this. Do we use virtualenv to sandbox the python modules required? Do we need a puppet module to help with upstart handling? What other parts are tricky?
[mass-moving from Tools>MediaWiki-Vagrant to separate product. See bug 54041. Filter bugmail on this comment.]
(In reply to comment #0) > What other parts are tricky? The request to event.gif is generated in the user's browser, which is running in the host environment, not the guest. So if you want the VM to handle events, you need to forward another port. We don't have a great mechanism in place for conditionally forwarding a port on the basis of role activation, so there's that. Role activation happens in Ruby code on the guest, so you could ostensibly have roles that go beyond Puppet manifest manipulation and actually modify the VirtualBox / Vagrant container it executes in. I'm not sure this is the best use-case for it, but it is something that I'd be happy to see implemented. There are two other things to consider. One is that it's a totally viable option for Wikimedia folks to simply set $wgEventLoggingBaseUri to the Labs endpoint (//bits.beta.wmflabs.org/event.gif) or even production (//bits.wikimedia.org/event.gif). Events generated on your dev instance will be logged, and they'll be marked as hailing from 'devwiki' (or whatever you set your wiki $wgDBname to). Finally, remember that all that the production beacon endpoints do is log the request. There's no reason why that couldn't be done by MediaWiki -- say, in an API module. This is exactly how the old ClickTracking extension that EventLogging replaced was implemented. We had to move away from that because the application servers are slow and expect the caches to protect them from the brunt of production traffic, whereas events are unique and thus cache-busting. But what's true of Wikimedia's production environment isn't true for your dev wiki or for lots of other small- to mid-sized production wikis that could handle event pings perfectly well. Implementing this would not only obviate the need to open an additional port but also make EventLogging useful to third-parties. There's a long-standing bug for this, bug 43601. I put some notes and code there. It should be straightforward to do, I just haven't gotten around to it. If one of you guys wants to do it: <3.
*** Bug 52872 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > The request to event.gif is generated in the user's browser, which is running > in the host environment, not the guest. So if you want the VM to handle > events, you need to forward another port. Alternately, the vagrant apache instance could be configured to reverse proxy requests to /event.gif to the port 8100 service via mod_proxy and the ProxyPass directive.
(In reply to comment #4) > Alternately, the vagrant apache instance could be configured to reverse proxy > requests to /event.gif to the port 8100 service via mod_proxy and the > ProxyPass directive. As I mentioned in person, I think this is a great idea.
Change 84627 had a related patch set uploaded by BryanDavis: Add role for EventLogging that runs a local server. https://gerrit.wikimedia.org/r/84627
Change 84627 had a related patch set uploaded by Ori.livneh: Add role for EventLogging that runs a local server. https://gerrit.wikimedia.org/r/84627
Change 84627 abandoned by Ori.livneh: Add role for EventLogging that runs a local server. https://gerrit.wikimedia.org/r/84627
Unlick the cookie. Proposed patch was abandoned.
