Hi Henrik, Could you please write your comments to the google sites? http://code.google.com/p/ogf-nsi-project/issues/detail?id=9&colspec=ID Otherwise, discussions might be forgotten and not be reflected in the future versions. To write comments to the above site, please ask Guy to register your google account. Regards, Tomohiro On Mon, 3 Oct 2011 13:21:01 +0200 (CEST) Henrik Thostrup Jensen <htj@nordu.net> wrote:
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.