Re: [HTCondor-users] Stop making users explore

[Miha Ahronovitz <myinnervoice@xxxxxxxxx>]

Michael, I appreciate your words and ideas. I like this in particular:

And I'm thinking that a clear walkthrough on standing Âup a simple Linux-only vanilla pool with dedicated exec hosts, a "condor" username and home directory, shared filesystem, common UID domain, and all that very basic stuff would be a good foundation for novices - even novices with 25 years of experience, like me - to start building from.

After 30 years, the HTCondor project needs some new ways to grow. I feel every word you write as true, it can not continue dumping staffÂ

HTCondor project IMO needs people like you to start new new distributions, and support Âthem commercially for ease of use and UX improved  I even like the name " Novice Condor".

BTW, the Condor team has some of the best engineers I ever met in my professional life. HTCondor, by sheer volume of code and ideas , is a gigantic undertaking.

What we need is to make usable all this know-how Âinto something people love and can use using human intuition. Advice like

1ÂÂ ( TARGET.Memory >= 1465 )ÂÂÂÂÂÂÂÂ 0ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ MODIFY TO 973

is BRILLIANT , but not intuitive. A product is more than just code (lots of it) and documentation (lots of it).Â

A definition of a product (one of many) is here:

A good, idea, method, information, object or service created as a result of a process and serves a need or satisfies a want. It has a combination of tangible and intangible attributes (benefits, features, functions, uses) that a seller offers a buyer for purchase. For example a seller of a toothbrush not only offers the physical product but also the idea that the consumer will be improving the health of their teeth.

HTCondor open source can not be a product, because (1) Âis not something a seller offers a buyer for purchase. Then Â(2) it lost track of whose needs or wants it must satisfy . There is no doubt that that HTCondor has substantial tangible and intangible benefits.

But without Âitems (1) and (2) we can not call it a product. Even for the scientific community, I discovered that scientists are just as human as all of us and will not put up with complexity to do their research. This explains why Cycle Computing is so successful.

Many thanks

Miha

On Sat, Nov 16, 2013 at 10:17 PM, Michael Pelletier <mvpel@xxxxxxxxx> wrote:

Miha,

As a new adopter of HTCondor, moving from a poorly-maintained, poorly-understood, five-year-old Sun Grid Engine system over the past few months, I think your post is pretty much spot on. Even the administrators have to explore too, I found - it took me a while to figure out just how my users' intended jobs mapped into a meaningful, coherent HTCondor configuration, and I'm still getting the hang of rank and requirement expressions.

I can't remember the last time I saw a single-CPU machine in a business context, but it took me a surprising amount of time to get a handle on dynamic slots, which I think was because I didn't have a clear understanding of how the pieces fit together.

I mean, the "Introduction" to the Admin's section of the manual is basically just a reference guide for the different daemons, describing what they do, but not so much of why they do it, and with whom, and to what end. I sometimes felt like I was trying to learn to drive by reading a Haynes manual.

The "hole" I wanted was standing up a pool of dedicated machines for vanilla jobs, and it was a bit of work to find the proper drill bit.

I think the challenge the dev team is trying to deal with in what they're putting out is that there's so many different possible use scenarios - Windows machines, Linux/Solaris/etc, EC2, different UID and FS domains, scavenging from desktops, you name it - not everyone is going to want a vanilla-only dedicated-exec-host pool. Plus they've been immersed in it for so long, they may not even realize what it really takes for an average admin to go from zero to condor_submit.

I've been collecting some mental notes as I've worked through the process of introducing HTCondor to our environment and migrating from SGE, which I hope to use to help others avoid the kind of effort I had to expend in order to make the journey.

And I'm thinking that a clear walkthrough on standing Âup a simple Linux-only vanilla pool with dedicated exec hosts, a "condor" username and home directory, shared filesystem, common UID domain, and all that very basic stuff would be a good foundation for novices - even novices with 25 years of experience, like me - to start building from.

This is how I've got about 1,000 cores in the pool running pretty well, particularly after teaching about the joys of $_CONDOR_SCRATCH_DIR. But as I'm gaining confidence and knowledge, I'm eyeing the hundreds of 8-core Windows desktops on the network with my mouth watering over the transformational power that can offer to my users and our customers, and meanwhile I preach the HTCondor gospel to the users and gain converts.

  -Michael Pelletier.

_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users

The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/

Attachment: Grid Engine.JPG
Description: JPEG image