[GE users] sge6.2u5 source ?

templedf daniel.templeton at oracle.com
Fri Jul 2 18:37:19 BST 2010


Ron,

I finally checked with Reisi about the docs.  Looks like there is indeed 
an internal doc on the comm lib.  It's honestly the first and only 
internal doc I'm aware of.  When Reisi has some spare time, I'll ask him 
to get it translated from our internal wiki to some externalizable 
format and clean it up for external consumption.

Daniel

On 06/25/10 09:47, ron wrote:
> --- On Fri, 6/25/10, templedf<daniel.templeton at oracle.com>  wrote:
>>> yep, I'm pretty sure there is some internal
>> documentation which would
>>> make adding features more easy.
>>
>> Sadly, no.  All of the docs we have are open.
>
> Hi Dan,
>
> I think the commlib is a big piece of undocumented code, and Christian said that he would work on the docs when I asked for them more than 5 years ago:
>
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=39&dsMessageId=11717
>
> So Sun did not have a lot of internal docs even for the support team?
>
>   -Ron
>
>
>>
>>> Also in reference to the recent
>>> question on the list about JGDI and JMX: any document
>> besides looking
>>> into the source?
>>>
>>
>> You can build the javadocs from the source.  Aside
>> from that, there's
>> nothing.  JGDI is not intended as a public API.
>> It exposes the
>> qmaster's internal data structures, which means it's almost
>> guaranteed
>> to change with every release.
>>
>>> Somehow I have the feeling, that SGE/OGE is somewhere
>> between closed
>>> source and open source. On the one hand it's open
>> source, but on the
>>> other hand still under SUN/Oracle's QA as they sell
>> their support and
>>> can't allow any custom changes to the code base of
>> course, which makes
>>> it impossible for the community to make just some
>> improvements to the
>>> source. Enhancements of e.g. `qstat' were quite often
>> on the list and
>>> some are doing it every time again for themselves when
>> a new release
>>> is available.
>>>
>>
>> We certainly have not done an exceptional job of making it
>> possible for
>> the community to contribute, but it does happen.  Take
>> the included MPI
>> support, for example. ;)
>>
>>> Are there any options, that the community becomes more
>> involved?
>>>
>>
>> I'm actually looking into it.
>>
>>>> and a pain in the ass to build :-) Of course I'm
>>>> aware of the fact that the community using job
>> schedulers is much to
>>>> small
>>>> to carry a refactoring of the code. Even then I'm
>> dreaming of a ./
>>>> configure;
>>>> make; make install process.
>>>>
>>> Me too. For now many depend on the courtesy binaries
>> simply because
>>> the compile process is a little but unusual, when you
>> are used to the
>>> automake tools. Changing to automake could make the
>> courtesy binaries
>>> dispensable.
>>>
>>> I would assume, that the number of users is increasing
>> with the number
>>> of cores available in a single machine: we are also
>> using SGE/OGE
>>> local on the workstations to serialize the workflow
>> instead of running
>>> 10 computations or so at the same time. When you are
>> used to SGE/OGE,
>>> it's a matter of minutes to install it local. A big
>> pro compared to
>>> other schedulers is, that it can even run under a user
>> account when
>>> there is only one user on the system anyway and all
>> parallel
>>> applications are only starting threads or forks (i.e.
>> no local `qrsh`)^
>>> %. A special single machine install could make it
>> attractive to new
>>> users.
>>>
>>> BTW: I assume, that all SGE_* environment variables
>> will be changed to
>>> OGE_* like it happened with COD_* prefix ~10 years
>> ago. Seeing this,
>>> OGE could also mean Open GridEngine.
>>>
>>
>> We aren't planning to change the SGE_* to OGE_* at this
>> time.  Some day
>> down the road we might change our minds, but it's really
>> not worth the
>> trouble it would cause for us and our users.
>>
>> Daniel
>>> -- Reuti
>>>
>>> %) Maybe this even doesn't apply any more with the new
>> -builtin-
>>> startup.
>>>
>>
>> The built-in interactive/parallel job support actually
>> makes it easier
>> to do a single-user install.  Prior to the built-in
>> support, the system
>> needed root access to support interactive/parallel jobs
>> properly.
>>
>>> Having the source available is a big plus for the Grid
>> Engine. It's
>>> even
>>> bigger then the availability of commercial support.
>> Whatever happens
>>> to SUN,
>>> Oracle and the Grid Engine team, there is a future for
>> the project.
>>> Every
>>> investment into the Grid Engine like configuration,
>> training,
>>> debugging etc.
>>> isn't lost. When the Grid Engine disappears or the
>> license changes,
>>> we take
>>> the source and do a fork. Newer Linux distros braking
>> the binary
>>> compatibility? Systems not officially supported? Take
>> the source.
>>>
>>> For my customers the situation looks similar. They buy
>> clusters for
>>> three to
>>> five years. I have even a system now running for seven
>> years, still
>>> under a
>>> Grid Engine 5.x.
>>> The customer has the warranty that a change of the
>> job
>>> scheduler isn't needed whatever happens.
>>>
>>> Loosing the access to the sources would mean we have
>> to change the
>>> standard
>>> job scheduler for our clusters. It would make me sad
>> as the Grid
>>> Engine is a
>>> great piece of software. Currently not really
>> replaceable with all
>>> if its
>>> features. Feel free to drop the courtesy binaries. But
>> don't stop
>>> the access
>>> to the sources!
>>>
>>> Beat
>>>
>>> --
>>>        \|/
>>
>>     Beat Rubischon<beat at 0x1b.ch>
>>>      ( 0^0 )
>>
>>     http://www.0x1b.ch/~beat/
>>>
>> oOO--(_)--OOo---------------------------------------------------
>>> Meine Erlebnisse, Gedanken und Traeume: http://www.0x1b.ch/blog/
>>>
>>>
>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=263781
>>>
>>> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net
>>> ].
>>>
>>>
>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=263914
>>>
>>> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
>>>
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=263916
>>
>> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
>>
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=264086
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=265689

To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].



More information about the gridengine-users mailing list