There is some confusion about this integration of multi-core into the current
accounting mechanisms.  I think now it seems likely Nimbus will move to a
'credit' based system where minutes aren't even the currency.  The presence of
multiple cores would make your allocation 'more expensive' in terms of credits.
 But this is summer work and I am trying to think about how we should approach
this bug.  Any comments?

Well, at this point, is a user charged more minutes if they request more
memory? If not, then should they be charged for more CPU? Then in the future,
when credits are implemented, we can create some function where Memory, CPU,
etc are the input and nimbucks are the output.

Yeah, right now they are not charged by memory either.  The algorithm for
coming up with the "Nimbucks" that would be spent is currently what's under
discussion.

Maybe we include multi-cpu then withOUT the accounting.  Maybe just an
enhancement to group-authz that says maxcores?

Yep, that would be fine by me. I wouldn't even mind implementing it. I should
have time this week to look at it.

That would be great, it should not be very difficult.  And I think if the new
setting is not present in the policy file, it could imply not to worry about
that particular part of the request.  Thanks Patrick.

Okay, I have a proposed patch for this bug in github right now.
http://github.com/oldpatricka/nimbus/commit/61c22381c0844159c3e738d00fb0bdc8e6afa420

I wasn't too sure that getZeroOrPositiveLongAllowNull method was the best way
to go about the problem (or that it was the best name for that method, but I
couldn't think of anything cleverer. I'm also not sure about whether I need to
include maxCPUs in all of the groupxx.properties examples, or whether 2 is a
good example value.

Patrick, thankyou very much, sorry it's taken me so long to get to this.  I've
visually reviewd and it looks good to me.  I will merge to master and test
asap.

Thankyou.

No worries, if you notice anything awry, let me know, and I can make some
changes.

I will account for the differences between your original work and the
differences introduced by this patch to the scheduler:

https://bugzilla.mcs.anl.gov/globus/show_bug.cgi?id=7015

http://github.com/nimbusproject/nimbus/compare/192443f...e8939b9

Thankyou Patrick!!  Basic exercising of it in the context of this pre-Nimbus
2.4 5 master is done, it will go under more tests when Bug 7062 is completed.

Merged into master for Nimbus 2.5:

    http://github.com/nimbusproject/nimbus/compare/fece9df...439fb44

NOTE this adds an optional field to the WSRF protocol.  This is backwards
compatible: if it is missing, the default is chosen as it always has been
(default is configured in "etc/workspace-control/main.conf" on VMMs).

The schedule thing mentioned in Comment #9 is not relevant now actually. The
scheduler will not be taking core into account as of the merge mentioned in
Comment #10