Re: [Condor-devel] Is Redefining OpSys a Good Idea?

[Ian Chesal <ichesal@xxxxxxxxxxxxxxxxxx>]

On Tuesday, 13 September, 2011 at 1:36 PM, Douglas Thain wrote:

Howdy -

I am about ready to throw in the towel on Linux compatibility.

Programs compiled on RHEL5 don't run on RHEL6, and going
between Red Hat and Debian is a joke. Our users get upset
every year during the upgrade cycle when nobody knows whether
their jobs will run correctly.

Fun times.

Have you considered statically linked binaries? It can help with the dependency hell that Linux distros present. It comes with costs though; with bigger binaries and memory footprints being two prominent ones.

We are already defining a custom attribute redhat_version which
is pulled from /etc/redhat-release via the startd cron, but everyone
forgets to do this and gets burned eventually. I also don't see an obvious
way to programmatically get redhat_version into SUBMIT_EXPRS so
it matches automatically but also allows the smart user to remove the
requirement.

In principle, I can just redefine OpSys to be "RHEL5" or "DEBIAN" instead
of "LINUX" in STARTD_EXPRS and SUBMIT_EXPRS, to make
it abundantly clear to users that these are completely different systems.

However, is this a good idea?

I think in context it's a good idea.

Is OpSys hard coded anywhere that would prevent this from working?

Shouldn't be.

Does anyone have a better solution to dealing with the Linux mess?

I've always used a custom attribute for specific linux variant steering because OpSys == "Linux" was so convenient for people who were doing statically linked binaries and really didn't care where they ran. But overriding OpSys is a fine way to get past the problem you're dealing with.

Regards,

- Ian

---

Ian Chesal

Cycle Computing, LLC

Leader in Open Compute Solutions for Clouds, Servers, and Desktops

Enterprise Condor Support and Management Tools

http://www.cyclecomputing.com

http://www.cyclecloud.com

http://twitter.com/cyclecomputing