Re: [Oscar-devel] RE : OSCAR GUI

[Chuck R. <cf...@ps...>]

A reasonable perspective. Those are all good things to prioritize.

DongInn seemed to be suggesting a GSoC project. I think GSoCs are more
geared toward something like a new interface and not general code
maintenance. In that respect, I think, a new GUI might still be a good
project (particularly if the oscarcli was fixed in the process).

I'm not a big java fan either. Javascript is not java, but java may
have been implied anyway. The current Tk interface works, but is not
always intuitive. As for the databases, I just wanted to point out the
duplication of function and suggest something lighter or integrated. I
think these database instances have so few writes that they could be
replaced with something like sleepycat. Granted, mysql has not been a
big problem to date, but it is a complex beast and complexity can
introduce problems. By saying v7.0, I intended to imply not a high
priority.

On Tue, Mar 19, 2013 at 5:13 AM, LAHAYE Olivier <oli...@ce...> wrote:
> Hi,
>
> IMHO, Java is hipe and  fashion, but leads to many eadaches concerning compatibility, to the point that each application requireing java is forced to ship its own java machine. I end up having 3 or 4 java machines installed on my systems (matlab, netbackup, ....) A pure nightmare when you need to upgrade.
> More over, oscar is already written in many languages (perl, python, bash, tcl, Tk, C, C++, ...), and I don't think that adding one more language will ease maintenance.
>
> Regarding the database, mysql is used by systeminstaller and oscar, and I don't understand why removing it could be a progress. It's a stand alone database and can be secured easily.
>
> I agree that jobmonarch using postgresql is not cool (2 database engines while one is far sufficient), but it's an upstream choice unfortunately. I've been in contact with developpers, and the project is not dead. v0.4 will be released some day. The TODO says that in the future, we should be able to choose the database backend. (no work done yet though).
>
> I understand that GUI is sometimes a problem, but honestly, on a cluster, you often have access to a X display on the local network. I think that there are far more urgent stuff to work on like:
> - having grindengine that works (current sge package is completely broken)
> - having blcr build for dkms
> - having a maintenance mode to:
>   - put online or offline nodes for maintenance
>   - move jobs (hybern,ate on a node and restore on another: usefull to isolate a node for maintenance)
>   - update nodes
>   - deploy new packages.
>   - stop the cluster hybernating nodes using a simple click.
>   - manage work queues
> - having a console log...
>
> My 2 cents,
>
> Olivier.