I’m wondering if there has been any thought and/or discussion about adding functionality to the Monitor to allow it to connect to a Mongo server instead of having to point it at a repository directory.
The specific use-case is being able to monitor and administer the queue at an alternate studio location, where the VPN connection is not able to reliably sustain an NFS mount in addition to our other traffic requirements.
I’m guessing we could hack together some basic monitoring tools using the Pulse Web Service, but with the new server-centric approach in D6, this seems like a waste of time for a pretty low-quality result; it seems like it would make more sense to just allow the Monitor to connect directly to a known repo server. Job submission and viewing reports, etc. would obviously be bigger challenges, but just being able to see all of the information that’s in the DB and trigger job/task state changes would be incredibly valuable.
There hasn’t been at this point. If we did support something like this, the following would have to be disabled:
report viewing/deleting
job submission
all script menus
job archiving
configuring events and plugins
event plugin triggers
The big concern is with event plugin triggers, since these can trigger when interacting with jobs through the Monitor. Maybe those could be triggered on another machine somehow. I don’t think we would want to use Pulse for this though, since we want to keep Pulse optional.
A potential workaround for now could be to install an “empty” repository in the remote studio location, and have it point to your production database. You could even sync up your event plugin scripts (if you guys use any).
Well, since this sounds like it’s currently a pretty edge-case scenario, requiring Pulse to enable this type of functionality actually seems totally acceptable. Obviously I don’t know if anyone else is facing a similar problem, but since Pulse is already required for pretty much anything else resembling remote administration (web service, mobile app support), using it as a sort of repository proxy seems like a pretty logical extension.
That’s an interesting idea. I’ll give that a shot when I get a chance and see if there are any “gotchas”.
I really feel like the server-centric approach to the repository is pretty well primed to support remote repositories as a first-class feature. It seems like a full implementation would require support for different protocols to access remote filesystems, and possibly something along the lines of a REST API piped through Pulse, but I would love to hear any more thoughts on this.