[Fwd: [ogsa-wg] BES Comments]
Hi all, Paul Strong, you may remember him as GGF18 keynote speaker, asks me to forward his comments on BES spec to OGSA-BES-WG list. Thanks, -- Hiro Kishimoto -------- Original Message -------- Subject: [ogsa-wg] BES Comments Date: Tue, 21 Nov 2006 11:18:25 -0700 From: Strong, Paul <pstrong@ebay.com> To: <ogsa-bes-wg@ogf.org>, <ogsa-wg@ogf.org> All, I have been attempting to catch up on BES and was reading the v1.0 document. I have some questions and comments. Please note that I have no context from meetings or discussions about BES so please forgive my ignorance, I may be missing important context or details :o) i) Why are there 2 client focused interfaces (3 interfaces in total)? It is very natural for there to be 2 interfaces to a service/component, one focused on delivering client functionality and one for manageability. It is also natural to minimize the number of interfaces and the calls across them so as to aid maintainability. It would appear to me that the difference between the two BES client interfaces is that one allows activities to be created and for collections of activities to be monitored and managed. The other is focused on individual activities, but includes very similar functionality. There seems to be a lot of commonality. What are the reasons for them not being combined? Indeed as I read further I note that BES-Activity exposes no operations, so perhaps this interface is being deprecated and the document is in the process of being edited? ii) Why does the state model not end in one terminated state? Are there any real differences between the 3 enumerated end states other than how the activity ended up in the state? iii) Also it seems somewhat counter intuitive that if one is going to have three termination states, one should end up in the one state which reflects both success and failure (Finished) and a separate one for failures that prevent the activity from exiting in a controlled fashion. It seems like the transitions to the terminated state should be something like - a. Completed Successfully b. Failed c. Cancelled iv) Is there any notion of a retry, given that the state machine captures failure? Or perhaps rescheduling? For example one could imagine additional useful transitions - a. Pending to Pending - i.e. rescheduling b. Running to Pending - i.e. failed/retrying Having these in the base profile or basic model would enable greater flexibility in implementing future profiles where one could request that the BES container implement retries or allow rescheduling. Or are you categorically stating that users will never be able to reschedule or request automatic retries. Again if this is the case, it should probably be explicitly stated. I would actually urge you to make the base specification as broad as possible in terms of the acceptable state changes at this level to avoid unnecessarily constraining yourself down the line. I think this is especially important given what is stated in 4.2. v) Labeling of the state transitions would be most helpful, together with the adoption of standard UML statechart representation. Included is a state transition diagram which includes a few additional transitions which may, or may not be helpful/appropriate. :o) vi) 4.2 - State Specialization really seems to be indicating that this specification makes no assumptions with respect to sub-states that may be incorporated within an implementation but that such sub-states are acceptable as long as they do not introduce new state transitions between the standard, specified states. It would be very helpful to simply state this before all of the examples. vii) Do you expect to extend the BES model to activities that are not binaries running on operating systems? Regards Paul -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
ii) Why does the state model not end in one terminated state? Are there any real differences between the 3 enumerated end states other than how the activity ended up in the state?
iii) Also it seems somewhat counter intuitive that if one is going to have three termination states, one should end up in the one state which reflects both success and failure (Finished) and a separate one for failures that prevent the activity from exiting in a controlled fashion. It seems like the transitions to the terminated state should be something like -
a. Completed Successfully
b. Failed
c. Cancelled
The three states are intended to convey how the activity completes. The finished state indicates that the activity itself completed (without outside intervention), but makes no statement about whether the computation that the activity was engaged in was successful or not. This was envisioned to be extended through some extension sub-states. One of the reasons is that it's hard (generically) to determine whether an activity completes successfully or not. Using things like (say) exit code is traditional, but doesn't always help you distinguish between failure ("file doesn't exist") or a problem in the running of the activity ("my calculated result is wrong"). Failed means that some "outside event" (e.g. a host failure) caused the activity to finish prematurely, so that you can't say whether it completed or not. And Cancelled is used to indicate a manual intervention that stops the activity from completing. At one point we discussed having one terminal state, but we felt that three was quite useful.
iv) Is there any notion of a retry, given that the state machine captures failure? Or perhaps rescheduling? For example one could imagine additional useful transitions -
a. Pending to Pending - i.e. rescheduling
b. Running to Pending - i.e. failed/retrying
Having these in the base profile or basic model would enable greater flexibility in implementing future profiles where one could request that the BES container implement retries or allow rescheduling. Or are you categorically stating that users will never be able to reschedule or request automatic retries. Again if this is the case, it should probably be explicitly stated. I would actually urge you to make the base specification as broad as possible in terms of the acceptable state changes at this level to avoid unnecessarily constraining yourself down the line. I think this is especially important given what is stated in 4.2.
I don't think pending to pending is necessary, as you can sub-state this to indicate any internal pending state transitions. Good point on running to pending ... maybe we should consider this one? How about failed to pending, or finished to pending?
vi) 4.2 - State Specialization really seems to be indicating that this specification makes no assumptions with respect to sub-states that may be incorporated within an implementation but that such sub-states are acceptable as long as they do not introduce new state transitions between the standard, specified states. It would be very helpful to simply state this before all of the examples.
Yes ... this should be made very clear. It's definitely time for another BES conference call..... -- Chris
participants (2)
-
Christopher Smith -
Hiro Kishimoto