|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Objectcom.waveset.provision.ThreadContext
com.waveset.provision.ProvisionContext
A class holding the runtime state for a single provisioning operation on a user.
One of these will be created by the Provisioner when it decides to go ahead and push changes to the resources. It maintains a structure of ResourceOp objects and provides a way to iterate over them. Order dependencies declared by Roles/Applications are understood, ResourceOp objects will be returned in the correct order.
The context is designed to be accessed by multiple threads. This allows us to launch several threads to perform a number of ResourceOp operations in parallel.
Besides maintaining the state, we also put the core provisioning implementation methods here too, as well as the methods for determining the resource OPs and calculating the order dependencies.
Field Summary | |
static java.lang.String |
code_id
|
protected static Trace |
trace
|
Constructor Summary | |
ProvisionContext(Provisioner p,
ProvisioningOptions options)
|
Method Summary | |
void |
buildDeProvisioningOps()
Build the ops for DEprovisioning. |
void |
buildOps(boolean deProvision)
Build the resource ops. |
void |
buildPolicyOps()
Build the ops for policy checking. |
void |
buildProvisioningOps()
Build the ops for REprovisioning. |
void |
buildResourceOps(boolean deProvision)
To implement the "reverse order of creation" rule, any delete dependencies have to be stored in the ResourceInfo object in the _dependentResourceId field. |
protected void |
calculateRetry(Resource resource,
ResourceOp op,
GenericObject retryInfo,
boolean terminateRetry,
java.util.List retWarnings)
Determine whether or not we need to retry the resource op and when it should be done. |
void |
checkResources()
Iterate over the resource ops, performing the "check" function. |
void |
doResources()
Iterate over the resource ops, performing the "do" function. |
void |
dumpFile(java.lang.String file)
|
int |
getDesiredThreads()
Calculate the optimum number of threads that could be launched to perform the ResourceOps in parallel. |
java.util.List |
getFiltered()
|
ResourceOp |
getNextOp()
Return the next operation that a thread can perform. |
protected java.util.Date |
getNextRetry(Resource resource,
int nextRetryCount)
Get the date/time of the next retry for the given resource and retry count. |
java.util.List |
getOps()
Return the list of ResourceOps. |
OrderedResourceOps |
getOrderedResourceOps()
|
Provisioner |
getProvisioner()
|
WavesetResult |
getResult()
|
boolean |
isFinished(int thread)
Returns true once all operations have been performed. |
java.lang.String |
opsToVerboseString(java.lang.String indent)
|
void |
prepare()
Make any last minute preparations before launching. |
void |
processOp(ResourceOp op,
int thread)
Called by each thread after it has obtained an operation to perform. |
void |
setChecking(boolean b)
|
void |
setDependencies()
After the OP buckets have been calculated, make sure that all ResourceInfo objects have any order dependencies recorded, so that they can be deleted in the proper order. |
java.lang.String |
toVerboseString()
|
java.lang.String |
toVerboseString(java.lang.String indent)
|
protected void |
updateRetryInfo()
jsl - added due to the new ProvisioningOptions encapsulation, still needs some rework. |
protected void |
updateRetryInfo(GenericObject retryInfo)
Update the retryInfo (stored in the task variables) based on the results in the ResourceOp's. |
Methods inherited from class com.waveset.provision.ThreadContext |
buildResourceUser, buildResourceUser, checkAdapters, generateIdentities, getAdministratorName, getExplicitIdentity, getOp, getOptions, getUser, getUserName, launchThreads, normalizeResourceInfos, overrideResourceAttributes, println, setTrace |
Methods inherited from class java.lang.Object |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
Field Detail |
public static final java.lang.String code_id
protected static final Trace trace
Constructor Detail |
public ProvisionContext(Provisioner p, ProvisioningOptions options)
Method Detail |
public void setChecking(boolean b)
public Provisioner getProvisioner()
getProvisioner
in class ThreadContext
public java.util.List getOps()
ThreadContext
getOps
in class ThreadContext
public OrderedResourceOps getOrderedResourceOps()
public java.util.List getFiltered()
public WavesetResult getResult()
public void checkResources() throws WavesetException
WavesetException
public void doResources() throws WavesetException
WavesetException
public void prepare() throws WavesetException
Go through each ResourceInfo making sure it has a resource identity. We can't build the identity immediately after buildResourceOps because we won't always have an accountId yet (if we're generating one) and we need build the resource-specific users that contain all of the identity template attributes.
prepare
in class ThreadContext
WavesetException
public int getDesiredThreads()
Assuming the sizes are relatively close, each ordered bucket will require its own thread. Could be smarter here if the sizes are radically different. Random ops can all be done in parallel. An optimistic measure would be one thread for every random OP plus the number of buckets.
Delete ops are a little harder since they have their own dependency chains. We'll assume that there can be one thread for each delete OP that does not have a dependency, as these represent the heads of the list.
getDesiredThreads
in class ThreadContext
public boolean isFinished(int thread)
The thread number is passed here so we can selectively decide to let threads expire even though we're not really done with processing. This might happen if we launched 10 threads to do a bunch of random things in parallel, but we're now down to 2 that have to iterate through 2 ordered lists. Since the other threads have nothing to do, we can let the die.
isFinished
in class ThreadContext
public ResourceOp getNextOp()
To fix Bug#1598, deletes are processed first. There is an obscure case, where there are two Resource definitions with different names, that both point to the same physical resource. Assume a user is added to one and removed from the other. If you process updates first, we create the new one, but then turn around and delete it when the deletes are processed. By doing deletes first, we still delete the account, but then create it again. Ideally, we would try to recognize that these are the same and not delete it at all, but that requires semantic analysis of the Resource definitions which we really can't do (provide something in ResourceAdapterBase to do this?). So, while the behavior might still be unpleasant, we're arguably better by leaving the fresh account behind.
getNextOp
in class ThreadContext
public void processOp(ResourceOp op, int thread) throws WavesetException
processOp
in class ThreadContext
WavesetException
public void buildPolicyOps() throws WavesetException
WavesetException
public void buildProvisioningOps() throws WavesetException
WavesetException
public void buildDeProvisioningOps() throws WavesetException
WavesetException
public void buildOps(boolean deProvision) throws WavesetException
WavesetException
public void buildResourceOps(boolean deProvision) throws WavesetException
I tried to come up with a optimized bucket-oriented implementation for deletion, but it started getting too complicated and error prone. Instead, we'll just keep all delete OPs in one bucket, and check delete dependencies on the fly in getNextOp. In theory, this could be more expensive since we'll be performing the same tests multiple times rather than once up front. But the code is much simpler this way.
WavesetException
public void setDependencies() throws WavesetException
Recalculate this each time, in case someone wants to correct a previously specified order. Note that if you have more than one account on a resource, we will have selected one at random to "satisfy" the ordered assignment. This may not be the one you want, but trying to solve that will significantly complicate things.
WavesetException
protected void updateRetryInfo() throws WavesetException
WavesetException
protected void updateRetryInfo(GenericObject retryInfo) throws WavesetException
WavesetException
protected void calculateRetry(Resource resource, ResourceOp op, GenericObject retryInfo, boolean terminateRetry, java.util.List retWarnings)
protected java.util.Date getNextRetry(Resource resource, int nextRetryCount)
public void dumpFile(java.lang.String file)
public java.lang.String opsToVerboseString(java.lang.String indent)
public java.lang.String toVerboseString()
public java.lang.String toVerboseString(java.lang.String indent)
|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |