Bugzilla – Bug 1738
a feature needed for job refresh
Last modified: 2005-02-24 13:43:42
You need to
before you can comment on or make changes to this bug.
Actually, it is not a bug. It is a feature that I would like to have for job
To refresh credential for a long runnning job, I modified the source code by
adding service data that contain the identity and termination time of the job
credential. I also added a method to update the termination time when the job is
It will be nice that the job manager have the functionality described above, so
that user can query the termination time of the job credential and the
terminatation time is updated whenver the job is refreshed.
I'm open to suggestions on the right way to refresh the credentials of running
jobs. It seems to me that
we need service data for the ManagedJob instances telling us the DN and
expiration time of the job's
credential, and we need that service data to be updated when we refresh the
I believe that according to Sumin's testing, when we delegate a new credential
to the ManagedJob
instance, the ManagedJobImpl refreshCredentials() method isn't called. Is that
Also, if we just want to delegate a credential to a service, is there a
recommended service method we
should call? I guess we want a method as close to a no-op as possible because
we're just interested in
doing the delegation. Is findServiceData() a good method to use for refreshing
I do not think that I made my test result clear. What I observed is that if we
use findservicedata() to refresh the credential, the credential do get
refreshed because it does not throw "expired credential" exception even though
the original credential is expired already. However, refreshCredentials()
method does not get called. If we add a method to update the termination time
and call this method when we refresh the credential, not only the termination
time is updated, but also refreshCredentials() method is called.
I am not sure what is the reason. I guess that when we call findservicedata()
to refresh the credential, some method in ManagedJobImpl's superclass is
called. However, if the newly added method is called to refresh the
credential, refreshCredentials() in ManagedJobImpl is called.
I think we need a dummy method in ManagedJobImpl. Whenever this method is
called, refreshCredentials() method will be invoked. And we can update the
info on the new credential in refreshCredentials() method.
If the delegated proxy (DP) has expired then client attempts to authenticate to
should fail. But that does not appear to be what you are reporting. Can you
If the MJS DP has not expired and you attempt to delegate via FSD, what is the
We CAN successfully refresh the credential when the old one is soon-to-be
expired. However, the current Gobus does not provide all the interfaces we
need. For example, it does not provide an interface to check the job
credential's termination time. (How can we know when to refresh the credential
if we cannot get the termination time? :-)) We have to modify the source code
to 1) add service data such as the job credential's termination time and 2)
add a method to update the termination time when the credential gets refreshed.
We are wondering whether or not Globus can add such features, since they are
critical for job credential refresh.
There are plans for a new GT service to manage credential delegation
service - DS). The current plans are that a client can delegate a credential
to the DS and then tell the MJS or RFT to use the credential from the DS. This
will not be
in place for GT 4.0, but should be in a subsequent GT release.
Would your needs be satisfied if the DS offered state change notifications?
if you could receive a notification every hour for the # of valid hours left on
For the MJS to offer this same information would seem redundant.
I'd prefer an interface whereby I could query the lifetime of DS credentials
rather than requesting an
(unreliable?) notification. Also, I'd want to be able to query the MMJFS data
to find out what DS
credentials my jobs are using, so I don't need to track that separately. And
first, I'd like to be able to
query the MMJFS to find out what jobs I have running, i.e., which jobs I own or
which jobs are running
with my identity, again, so I don't have to track that separately.
Agreed. Those requests are reasonable. The idea is that a client would tell
here is the key (or ID) to the DC that has been created in the DS.
Then the MJFS would fetch the DC from the DS and publish the key so a client
retrace it's steps to find out info about the credential it delegated to the
notification was just an example, the same information could be queried from
I believe the functionality requested has been implemented in GT 4.0 beta
(3.9.5). A client can query a
delegation service resource for credential lifetime and subscribe for
notifications if desired.
A client can find the delegated creds used for each job by querying the RP
looking for the jobCredentialEndpoint stagingCredentialEndpoint.
The job lifetime and the delegatedCred lifetimes are separate and should remain
so. If a client wants
them to be the same, then they can make it so.