RE: [Condor-devel] Installation issues.

["Michael Yoder" <yoderm@xxxxxxxxxx>]

> > > In particular, it made modifications to the global config file 
> > > (not just the local config file) during the installation process.
>
> > We want to make condor_configure do the same thing.
> 
> Huh? I thought the big win with changing just the local config file
was
> that, on an upgrade, the base config file could be updated without
> disturbing the customized options. That's how the new Windows MSI
> installer works too.

Let me explain my use case a little more.  I want to set up the simplest
of all possible condor pools:  two machines, both Linux, running all
appropriate daemons.  Of course, I started with the CM:

$ ./condor_configure --install --install-dir=/home/condor/demopool/
--local-dir=/scratch/condor/demopool/ --type="submit,execute,manager"

Since this is a new install, and this is obviously the central manager,
it ought to make modifications to the global config file.  As it is, the
global config file isn't touched and everything goes into the local
config file.   This is bad because

a) Now every single machine in the pool will have to define pool wide
things like CONDOR_HOST, RELEASE_DIR and LOCAL_DIR in the local config
file.

b) If the user looks at the global config file, it looks all wrong: for
example, CONDOR_HOST is "central-manager-hostname.your.domain".  Looking
in the local config file for this info isn't perhaps the first thing
that would come to mind...

c) You'll have to re-supply information each time condor_configure is
used to start up another machine, while if it was all in the global
config file you could just point it there...

Of course, not everything should go into the global config file:
collector/negotiator things do indeed belong in the local config file.
To put it bluntly, condor_configure should do exactly what
condor_install does.  Using condor_install, most machines actually wind
up with a blank local config file, and I think this is a good thing.

Now I understand that condor_install isn't always appropriate: the
unbroken string of questions can be a little nerve-wracking, and it
won't work for an automated install.  Both formats have their
place...but the end result of each should be the same.

While I'm beating on condor_configure, I might as well mention that the
'--install' option is not well documented, either in usage() or in the
man page.  Suitable documentation might read:

--install[=<path/to/release.tar>]
Install the condor binaries from release.tar into the path given by
'--install-dir'.  You can simply specify '--install' if release.tar is
in the current working directory.  Do not specify this option if you are
only changing the configuration of an existing condor installation.

Another complaint I have is that condor_configure uses different
terminology than the rest of condor.  One example is '--install-dir',
which in the rest of the condor world is called the 'release dir'.
Another are the options passed to --type:
<[submit],[execute],[manager]>.  Now I know these terms make a lot of
sense, and they are indeed in the manual, but they aren't used anywhere
else in condor.  Moreover it's not crystal clear [IMHO] that "submit"
really means "start a schedd" and "execute" really means "start a
startd".  Either condor_configure should match the rest of condor, or
condor should be changed to match the script.  :-)  (Or, --type could
take the daemon names as alternate values...)

-Mike