Hi Please remember to keep your NSI agents running and well-taken care of so people can test their implementations against yours. Here is a short reservation test result: OpenNSA WS reservation test client Network: Aruba Reservation created. Connection ID: urn:uuid:bcfa9dda-ea7b-11e0-9905-00144f20a8d2 Network: Bonaire Callback for call urn:uuid:bd0924e0-ea7b-11e0-9905-00144f20a8d2/reservation from urn:ogf:network:nsa:Bonaire-OpenDRAC timed out. Network: Curacao Callback for call urn:uuid:c8f50fa8-ea7b-11e0-9905-00144f20a8d2/reservation from urn:ogf:network:nsa:Curacao-AutoBAHN timed out. Network: Dominica Callback for call urn:uuid:d4e0feee-ea7b-11e0-9905-00144f20a8d2/reservation from urn:ogf:network:nsa:Dominica-OSCARS timed out. Network: Grenada org.apache.cxf.binding.soap.SoapFault: Could not initialize class com.sun.xml.internal.ws.spi.ProviderImpl Network: Jamaica Reservation created. Connection ID: urn:uuid:e18453ee-ea7b-11e0-9905-00144f20a8d2 Network: Martinique Callback for call urn:uuid:e5561296-ea7b-11e0-9905-00144f20a8d2/reservation from urn:ogf:network:nsa:Martinique-DynamicKL timed out. Result: 2/7 succesfull registrations. Come on, we can do better :-). Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
Hi Henrik, Grenada should be working now. Could you try again? Tomohiro On Thu, 29 Sep 2011 11:23:35 +0200 (CEST) Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi
Please remember to keep your NSI agents running and well-taken care of so people can test their implementations against yours. Here is a short reservation test result:
OpenNSA WS reservation test client Network: Aruba Reservation created. Connection ID: urn:uuid:bcfa9dda-ea7b-11e0-9905-00144f20a8d2
Network: Bonaire Callback for call urn:uuid:bd0924e0-ea7b-11e0-9905-00144f20a8d2/reservation from urn:ogf:network:nsa:Bonaire-OpenDRAC timed out.
Network: Curacao Callback for call urn:uuid:c8f50fa8-ea7b-11e0-9905-00144f20a8d2/reservation from urn:ogf:network:nsa:Curacao-AutoBAHN timed out.
Network: Dominica Callback for call urn:uuid:d4e0feee-ea7b-11e0-9905-00144f20a8d2/reservation from urn:ogf:network:nsa:Dominica-OSCARS timed out.
Network: Grenada org.apache.cxf.binding.soap.SoapFault: Could not initialize class com.sun.xml.internal.ws.spi.ProviderImpl
Network: Jamaica Reservation created. Connection ID: urn:uuid:e18453ee-ea7b-11e0-9905-00144f20a8d2
Network: Martinique Callback for call urn:uuid:e5561296-ea7b-11e0-9905-00144f20a8d2/reservation from urn:ogf:network:nsa:Martinique-DynamicKL timed out.
Result: 2/7 succesfull registrations.
Come on, we can do better :-).
Best regards, Henrik
Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hi On Fri, 30 Sep 2011, Tomohiro Kudoh wrote:
Grenada should be working now. Could you try again?
Indeed it is working now. I did reservation-provision-terminate cycle which worked. Latency was a bit high in provision (is this on purpose?), but otherwise it went well. Thanks. Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
Hi Henrik, Thank you for testing. It seems working well. Regarding the provisioning timeing, for example, ConnectionId = urn:uuid:d4abdd9c-eb3c-11e0-93ee-00144f20a8d2 2011-09-30 17:19:32.495 +0900 INFO [ReservationRequestType received] start Fri Sep 30 08:19:51 GMT+00:00 2011 2011-09-30 17:19:34.332 +0900 INFO end sendReservationConfirmed start-time of this reservation was 19:51 after the hour. 2011-09-30 17:19:34.616 +0900 INFO [ProvisionRequestType received] Provision request was received at 19:34 after the hour. So, it is auto-provisioning. 2011-09-30 17:19:51.048 +0900 INFO [ProvisionConfirmedRequestType send] 2011-09-30 17:19:51.648 +0900 INFO end sendProvisionConfirmed Therefore, following the current state machine specification, a provision confirm is sent at the start-time, 19:51 after the hour. Tomohiro On Fri, 30 Sep 2011 10:22:40 +0200 (CEST) Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi
On Fri, 30 Sep 2011, Tomohiro Kudoh wrote:
Grenada should be working now. Could you try again?
Indeed it is working now. I did reservation-provision-terminate cycle which worked. Latency was a bit high in provision (is this on purpose?), but otherwise it went well. Thanks.
Best regards, Henrik
Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
Hi again On Fri, 30 Sep 2011, Tomohiro Kudoh wrote:
Regarding the provisioning timeing, for example,
start-time of this reservation was 19:51 after the hour.
Provision request was received at 19:34 after the hour. So, it is auto-provisioning.
Therefore, following the current state machine specification, a provision confirm is sent at the start-time, 19:51 after the hour.
OK, I am a bit confused here. If I look at the state machine matrix, a provision request for a connection in reserved state should result in a transition to Auto-provision and emit a prov.rq message. AFAICT this is wrong. The question is if there should be no message emitted (i.e., wait till the start_time event occurs, but there is no message emitted for that either). Alternatively (and this is what I _think_ is correct) is that a prov.cf message should be emitted. Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
Hi Henrik, 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. There is an argument on this matter as shown in: http://code.google.com/p/ogf-nsi-project/issues/detail?id=9&colspec=ID Type Status Priority Owner FoundInVersion FixedInVersion Summary The design may be changed after discussion. But at this moment, the SM matrix is right. Tomohiro 2011/9/30 Henrik Thostrup Jensen <htj@nordu.net>:
Hi again
On Fri, 30 Sep 2011, Tomohiro Kudoh wrote:
Regarding the provisioning timeing, for example,
start-time of this reservation was 19:51 after the hour.
Provision request was received at 19:34 after the hour. So, it is auto-provisioning.
Therefore, following the current state machine specification, a provision confirm is sent at the start-time, 19:51 after the hour.
OK, I am a bit confused here.
If I look at the state machine matrix, a provision request for a connection in reserved state should result in a transition to Auto-provision and emit a prov.rq message. AFAICT this is wrong.
The question is if there should be no message emitted (i.e., wait till the start_time event occurs, but there is no message emitted for that either). Alternatively (and this is what I _think_ is correct) is that a prov.cf message should be emitted.
Best regards, Henrik
Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
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.
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.
Hi all, Due to scheduled maintenance of our building, G-lambda/AIST (Grenada) NSI servers are temporally shutdown. They will be available again on Tuesday. Tomohiro
participants (2)
-
Henrik Thostrup Jensen -
Tomohiro Kudoh