[Nsi-wg] Keep those

[Henrik Thostrup Jensen]

Hi again

On Fri, 30 Sep 2011, Tomohiro Kudoh wrote:

> The state machine matrix follows the current design of state machine.
> The "prov.rq" message sent at the Auto-provision state is for
> children, to propagate the provision request. In the current design,
> no prov.cf is returned to the requester at the time a prov.rq message
> is received if it is before the start-time. The SM silently transits
> to  "Auto provision" and then transits to "Provisioning" at the
> start-time. It returns prov.cf or prov.fl when actual provisioning is
> succeeded/failed at the start-time.

OK, I think I get it now. I missed the part about propagation to 
providers. It is a bit tricky to infer if a message should be issued back 
to the requester or down to a provider, as it is not clear what role the 
state is being handled for.

Another issue with the state machine, are the "holds". These are not 
really possible to do in a state machine as it requires the addition of a 
queue construct. I am not quite sure how to handle this, but with them, it 
is not actually possible to implement this as a pure state machine for 
handling requests.

This is more a generic protocol issue, but I am not thrilled about the 
state updates to auto-provision and scheduled being silent, i.e., the 
requester isn't notified when the state changes into this. I've previously 
suggested making a generic stateUpdated / stateChanged message from 
provider -> requester for these things, which could be used for all 
provier -> requester communication (except query of course).

Some of these things should probably have been in a seperate mail to the 
list, oh well.


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at ndgf.org>
  NORDUnet / Nordic Data Grid Facility.