not really, it would produce the same result as today, the node would remain on OFFLINE state
On Fri, Jul 19, 2013 at 12:43 PM, kishore g <[email protected]> wrote: > 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? > > > > > > > > > >
