Project

General

Profile

Feature #3102

Add a tool to create links to LSB standard locations for Condor tarball installs

Added by Igor Sfiligoi almost 7 years ago. Updated over 5 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
11/01/2012
Due date:
% Done:

0%

Estimated time:
Stakeholders:
Duration:

Description

If one installs Condor with the condor_provided installer, the files end in a dedicated directory tree.
Which is good, because it is self contained.

However, it would still be good to have the relevant files linked from LSB standard locations,
when installing as root.

Condor currently does not provide such an option in their installer, so we should provide a tool to do it.

History

#1 Updated by Igor Sfiligoi almost 7 years ago

The proposed name of the tool is

glidecondor_linkLSB

in the install directory.

#2 Updated by Igor Sfiligoi almost 7 years ago

  • Status changed from New to Feedback
  • Assignee changed from Igor Sfiligoi to Burt Holzman

Committed to
branch_v2plus_igor_3102

Burt: Do you want to have a look?

#3 Updated by Douglas Strain almost 7 years ago

I'm not sure I agree with this tool. It's really asking to get shot in the foot. I guess if it is hidden in the tool directory, its completely optional for users to run. However, I don't think this is a good idea to support. There are a lot of use cases that are a mess with this tool. For instance,

- User installs condor, runs linkLSB, then wants to install a new condor. All the links point to the wrong thing, and the tool does not help you sort out the mess.
- User installs condor, runs linkLSB, then decides to install the RPM (or messes up a yum conf and it updates automatically, or installs something else that installs condor as a dependency, etc). Who knows what will happen, but I am sure it will be a disaster. a dependency, etc). Who knows what will happen, but I am sure it will be a disaster.
- Servers with multiple condor installations for testing, etc. Though there is no conflict or bug with this tool, it would make things extra confusing.

As a style note, it also seems very gross. I certainly don't want to support this kind of configuration. I can certainly imagine myself trying to debug an issue for hours before realizing that the user has run this command and forgot about it, and all the condor binaries in are in unexpected locations

#4 Updated by Igor Sfiligoi almost 7 years ago

Whoever uses the tarball templates to install a root-level setup will want to do this.
With or without the tool.

So, the net result will not be any better without the tool...
at least the tool will check if the files are the same, if ran multiple times.

PS: And, yes, there may be good reasons for not using RPMs, but still use the config.d setup.

#5 Updated by Igor Sfiligoi almost 7 years ago

BTW: The existing installers do something similar, by
a) symlinking /etc/condor/condor_config to the $INSTDIR/etc/condor_config
and
b) creating files in /etc/profile.d

#6 Updated by Igor Sfiligoi over 6 years ago

Hi Burt & co.
What do you want to do with this?

From your message above it is not clear if you are veto-ing it, or if it can be saved with some kind of change.

#7 Updated by Burt Holzman over 6 years ago

It's tabled for the time being.
We need to review the install and deploy process in the project. We've never converged on this.

#8 Updated by Parag Mhashilkar over 5 years ago

  • Target version changed from v2_7_x to v3_x


Also available in: Atom PDF