Hi, > Am 30.06.2016 um 10:57 schrieb Rémy Dernat <[email protected]>: > > Hi, > > So I created a formula to add a node. This part work on the exec node. I > created a tar file, source settings.{c,sh} and copied sgeexecd to /etc/init.d/
Or create a symbolic link there to /usr/sge/default/common/sgeexecd > However, now, I am trying to add the exec node on the server side. My exec > node will also be a submit host; Here is what I think need to be done (in a > script or though a formula): > > - Create a generic sge template for the host Which template? You refer to `qconf -mconf <exechost>`? If all nodes are the same you don't need any special configuration for each exechost. In fact I delete all local configurations which might have been added automatically as the global configuration is sufficient. Then you can make the node an admin and submit host and add it to a hostgroup. As soon as execd on the node contacts the qmaster, it's becoming an exechost automatically. > - Create a SGE template for the host group > - Add the host to the host group template > - Modify the host template to match the exec node to add to the server > - Add the node to the sge master through the host template > -> qconf -Ae $exechostname host.tmpl > - Add the node to the host group: > -> qconf -Mhgrp @lhosts lhosts.tmpl Why using a file and not adding it directly? -- Reuti > - Add the node to the list of submit hosts: > -> qconf -as $exechostname > > Do you think I forget something (except to modify the firewall) ? > > Best, > > Remy > > 2016-06-28 12:35 GMT+02:00 William Hay <[email protected]>: > On Tue, Jun 28, 2016 at 11:06:44AM +0200, R??my Dernat wrote: > > Hi, > > I am using SGE for some years now. I install my nodes through rocks > > cluster with images. However, since Rocks is based on a old version of > > CentOS, which is older than the last fedora or RedHat, we think about > > moving to a debian base cluster, because we don't need certified stuff > > (eg. for IB or nvidia or for some other software/reason). > > I will configure my new nodes using the couple FAI/salt. > > I have already many salt formulas/recipes. > > I would like to manage my future cluster, and obviously my job scheduler, > > SGE, with salt. > > Concerning SGE, I think we will move to the last version of SoGE. > > I know that many of you already did it with puppet. I saw this repository > > on github: > > https://github.com/AAFC-MBB/sge-puppet.git > > I take a look into this puppet formula, and it seems that there is a lot > > to configure, not only SGE (ssh keys, iptables, nfs...). BTW, it is doing > > an update on the exec node, which is *not wanted* here. > > On many configuration file, on my master, I have this warning: > > ``` > > # Version: 2011.11p1 > > # > > # DO NOT MODIFY THIS FILE MANUALLY! > > # > > ``` > > Indeed, I have OGS/GE 2011.11p1, but how SGE store is configuration datas > > ? Everything is in configuration files ? If so, why this warning ? > > Any idea or best practice to look at ? > They're not just config files but grid-engine's record of information about > the object in question. > They exist to help grid-engine keep track of things over a qmaster restart. > The config is > just part of the information in them. > > Take a look at the files for exechosts they contain load values which aren't > things you configure > but reports from various load sensors. If you try writing to this file while > the qmaster is up > your changes might get overwritten by gridengine updating a load report or > the file might get corrupted > if you try to modify it in place. There is no documented procedure for > changing these files > and then telling a running gridengine to reread them. Instead you use qconf > to request a change then > the qmaster updates the files. > > You would also be taking on the burden of keeping cluster queues hostgroups > and qinstances > consistent which will be checked automatically if you just use qconf. > > William > > _______________________________________________ > users mailing list > [email protected] > https://gridengine.org/mailman/listinfo/users _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
