Re: [Condor-users] vm1 info in vm2 ClassAd?

[Ian Chesal <ICHESAL@xxxxxxxxxx>]

> Ian, out of interest how does this handle the machine being
> entirely empty and multiple jobs being able to run?

Not elegantly. :D

> Do they all start, then the ones that aren't blessed for the
> special mode kicked shortly after?

It depends on the order jobs start on the machine.

If a sensitive job starts in slot 1 then the START attribute for every
other slot will, more or less, immediate evaluate to False. So even
though the jobs were matched, they'll get rejected by the machine when
the schedd tries to tell the machine to start the job. If a job starts
in any other slot before the slot 1 sensitive job then it'll be
preempted by the sensitive job when it starts in slot 1.

There's certainly a lot of wasted CPU with this approach. We only deploy
this config on a handful of machines in our pools. And we keep a pretty
steady diet of sensitive runtime jobs in the queue so the machines are
only rarely running jobs in all slots.

> The "negotiation lacks awareness of changes brought about by
> previous assignments in the cycle for SMP machines" is really
> quite annoying.
>
> A simple switch to allow only one assignment/alteration of a
> slot on an SMP machine per negotiation cycle (and require a
> refresh of the condor_collector state of all slots on that
> machine until it is okay to assign to it again) would be nice
> as you could then write idealized configuration and look to
> have this made more effective and efficient later.

I have to admit I hadn't even *noticed* support for dynamic machine
partitioning until yesterday. I thought it was in 7.3.x, not 7.2.x -- so
I'm wondering how 7.2.x supports this now. As you've pointed out: there
are some fundamental issues with negotiation that make dynamic
partitioning challenging.

I'm swamped, but hopefully I can find some time to play with it in
September.

> Obviously anything depending on something like hawkeye would
> always require this but simple ones that just reference the
> state of other slots in terms of what jobs are assigned to
> them would work fine in a 'self aware negotiation model.

Because there's a check against the machine's current classad status on
assignment of a job --> machine it works out in the end even though the
negotiator knows nothing about this. But it's ineffecient and I wouldn't
recommend an entire farm configured the with my sensitive job setup.
You'll notice all my configs force the slot to retire so it returns to
the pool for re-negoiation. I rarely take advantage of the schedd's
ability to run another job from the cluster (auto-cluster? can the
schedd crack clusters like the negotiator?) because we want our machines
getting jobs assigned based on priority. So I'm particularly sensitive
to things that cause a lot of preemption on my farm since every
preemption means a return to the negotiator before the slot gets another
job.

- Ian

Confidentiality Notice.
This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution,  or copying  of this message, or any attachments, is strictly prohibited.  If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments.  Thank you.