So a change for controller to fire transitions only when participant has registered a state model should work right. It wont explicitly put the node in error state but avoids sending the transition.
Putting into ERROR state is little extreme. On Fri, Jul 19, 2013 at 8:27 AM, Santiago Perez <[email protected]>wrote: > We use configuration to mark nodes to support different statemodels. so it > can be the case that a pre-existing ideal state had node A assigned to > resource B which used statemodel C but the node now only supports > statemodel D. This is a human error and we want to make it explicit with an > error state rather than hiding it behind a transition never starting > (specially because we have transitions that take up to 10hs). > > Thanks > Santi > > > On Fri, Jul 19, 2013 at 11:45 AM, kishore g <[email protected]> wrote: > > > it would probably be better to change the controller to not send any > > transition message until a statemodel is registered. > > > > Controller can treat it as this node is disabled for this state model. > > > > Can you give more info on when would this happen in your usecase. Is > there > > a case where you connect but then fail to register statemodel? > > > > thanks, > > Kishore G > > > > On Thu, Jul 18, 2013 at 1:14 PM, Santiago Perez <[email protected] > > >wrote: > > > > > By default, if a transition is sent to a participant and it has no > state > > > model registered it will wait until such model is registered. It would > be > > > nice if based on some attribute of the state model def, one could force > > the > > > node to go into error state if such situation arises. > > > > > > What do you think? > > > > > >
