Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should get_available_modes be influenced by inference #43

Open
norro opened this issue Sep 15, 2020 · 7 comments
Open

Should get_available_modes be influenced by inference #43

norro opened this issue Sep 15, 2020 · 7 comments

Comments

@norro
Copy link
Collaborator

norro commented Sep 15, 2020

If we know through mode inference, that a certain state or mode of a (sub-)system can't be transitioned to, should get_available_states and get_available_modes of (sub-)systems report accordingly?

Example:

  • Subsystem A contains several nodes, e.g., node B
  • If node B transitions into error_processing, certain states and modes for subsystem A are not available until errors in node B are fixed
  • get_available_states and get_available_modes of subsystem A only report states and modes that allow node B to be in error_processing, e.g., degraded modes
@norro
Copy link
Collaborator Author

norro commented Sep 22, 2020

Proposal after discussion with MROS team:

  • get_available_modes should stay consistent with get_available_states, i.e. returning all modes of a node/system
  • in addition, response of the service should be extended by a list - e.g., termed reachable_modes - that only shows modes that are currently available/reachable
  • reachable_modes can probably be inferred for systems automatically by the mode_manager. Still tbd, what the default is for nodes, i.e. either reachable_modes = [] by default or reachable_modes = available_modes by default, if not explicitly implemented by the node

@norro
Copy link
Collaborator Author

norro commented Sep 30, 2020

When/how can we consider modes to be not reachable by nodes?
Available modes are currently reported by the mode manager based on the SMH file (this is because the lifecycle node itself doesn't have any idea about modes). We could obviously conclude that no mode is reachable when the node is in error-processing, but is this the only thing we know?
@chcorbato Do you have an idea on this?

norro added a commit that referenced this issue Sep 30, 2020
* Introduces additional field reachable_modes to GetAvailableModes
service

#43

Signed-off-by: Arne Nordmann <arne.nordmann@de.bosch.com>
@chcorbato
Copy link

Maybe we could associate the ErrorProcessing transition to the node MODE at that moment, so that only that MODE is considered not reachable.
What do you think? Could the Mode Manager keep track of reachable modes?

@norro
Copy link
Collaborator Author

norro commented Oct 1, 2020

The Mode Manager has to keep track of reachable modes, yes.
So you suggest that all modes are considered reachable when the node is inactive/active and no modes are considered reachable when the node is in error processing? That should be doable.

@chcorbato
Copy link

No, not all modes.
I think we should consider not reachable only those node modes that were active when the node went into ErrorProcessing.
It could be that only specific configurations cause the node to go into error, right?

@norro
Copy link
Collaborator Author

norro commented Oct 2, 2020

Okay, so the mode manager would then keep track of the modes that "made" the nodes transition into error processing and exclude them from the list of reachable modes. Maybe until the node gets reset?

@chcorbato
Copy link

Okay, so the mode manager would then keep track of the modes that "made" the nodes transition into error processing and exclude them from the list of reachable modes. Maybe until the node gets reset?

Sounds reasonable to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants