Server/client architecture

[mkb0517]

No description provided.

[mkb0517]

Fills REQ_12, REQ_13

[mkb0517]

When server mode is implemented, there needs to be a client interface for users. For example, when running during the night for Quick Look purposes, the user needs to be able to send commands to the server. This would also be applicable to future science platforms, like if this were running at KOA.

For the first case, the Client would be a stripped down version of the server that sends requests for specific actions rather than running the actions locally. It needs to be able to set the parameters for configuration or refer to a specific config file for use.

For the science platform case, the client would also likely include a web interface so that users can access the client from a web browser and see the information they want in KOA while also planning the reduction for the data.

In either case, the client has to be configurable to point it at the right server.

[joshwalawender]

I would strongly encourage the server/client mode to be completely divorced from the run a linear series of steps mode (i.e. local laptop mode). Make the server/client code be a separate install which wraps the other code, so as not to carry around excess code because unsophisticated users might get confused by the options is provides.

[mkb0517]

I would strongly encourage the server/client mode to be completely divorced from the run a linear series of steps mode (i.e. local laptop mode). Make the server/client code be a separate install which wraps the other code, so as not to carry around excess code because unsophisticated users might get confused by the options is provides.

I don't think this is necessarily the best idea. If a user wants to reduce data in the middle of the night from their laptop, they shouldn't have to install two different version of the same program to do two different modes. They also shouldn't have to log into a WMKO or remote observing computer to do the reductions in server mode. The program should default to local use mode and only give access to the client/server mode when actively engaged. That being said, if they want to see the data being reduced and maybe update parameters, they should be able to do that from the same program by invoking the client/server mode.

[mkb0517]

For server/client mode, there should be an argument to the program that allows the server to start up as a daemon on the server machine and a reduced instruction set to be loaded on the client machine. Something like python reduce.py -mode=server and python reduce.py -mode=client -server=wmko -auth=AUTH_HASH. (note: mode defaults to local)

[joshwalawender]

I still very strongly assert that installing multiple modes at once is going to lead to support problems. I can not imagine a non-developer wanting to move back and forth frequently between local only mode and client mode, but I can absolutely see a user having an issue that is due to them having triggered client mode because so and so down the hall said these were the arguments to use and then they combined that with other advice that is related to running in local mode. Users take advice from one another and just try things without understanding them. There will be instances when a user runs -mode=client and has no idea what it means. Make the modes different installs or at the very least have them invoked with completely different names. The distinction needs to be absolutely clear to users who have no idea what the architecture of the system is or what these terms mean. Clarity is crucial for support and user training.

[mkb0517]

It wouldn't be developers using client-mode. Client-mode is mostly for night time observers to view Quick Look reductions or possibly people using KOA as a science platform. It would give them an interface to the server where all the work is being done. In both of these cases, they would probably want to have access to the local mode as well in order to do smaller batches of reprocessing. In fact, most if not all pipeline developers will probably only use local mode for development.

It's possible to set up different aliases for the varying modes, but I think this could also be easily handled through proper documentation of the invocation.