Automatically binding to ancestors

[Gary Bressler]

Hi team,

Component manager currently implements behavior where, if you bind to a component, it will automatically bind to all its ancestors. This is a holdover from when we held that parents should always run if one of their children is running. But since then, we have added features that discard this principle (e.g., `use from child`, in which case the parent may be stopped before the child). I uploaded a change that removes this behavior and ran it through CQ without any problems. Are there any reasons we can think of not to do this? Or any known places relying on this behavior which are not caught by tests?

[Adam Barth]

+1 to not automatically binding ancestors.

On Thu, Oct 7, 2021 at 3:47 PM 'Gary Bressler' via component-framework-dev <component-f...@fuchsia.dev> wrote:

Hi team,

Component manager currently implements behavior where, if you bind to a component, it will automatically bind to all its ancestors. This is a holdover from when we held that parents should always run if one of their children is running. But since then, we have added features that discard this principle (e.g., `use from child`, in which case the parent may be stopped before the child). I uploaded a change that removes this behavior and ran it through CQ without any problems. Are there any reasons we can think of not to do this? Or any known places relying on this behavior which are not caught by tests?

--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
You received this message because you are subscribed to the Google Groups "component-framework-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to component-framewo...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAK1yh2kd6re-C4xMgaLTjUZoGTwuZ%2BZt7rJBEvoPkbTOibmW5A%40mail.gmail.com.

[Justin Mattson]

Are eager children of the ancestor still started? I'm pretty sure there are places that rely on this behavior.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAP%3D28cexy58AsYZKajg9K76bSx6v_TGsTECutf_L1wmV9igF0g%40mail.gmail.com.

[Gary Bressler]

If it's the direct parent that's bound to, then yes. But in a situation like this:

    A

   / \e

  B   C

Currently if you bind to `B`, `C` will get auto-bound, but not with the new behavior. If you know of any places that rely on this, please do tell (CQ didn't find them!)

[Justin Mattson]

system-update-committer I think used to rely on this behavior. Looking through the code today it doesn't seem like this will still be needed, but the SWD team probably knows for sure.

Cheers,

Justin

[Bryan Henry]

This seems like a fine thing to do, but I don't think I would assume a green CQ run tells you much in this case. This is the type of change that would most likely only manifest problems in integration/E2E tests or on the actual product, whereas we of course currently lean heavily on smaller hermetic tests. For example, missing the impact to system-update-committer would not have manifested as a user-observable change in behavior until the device rebooted 7 times and then switched back to the previous slot because the new one never got marked healthy.

It seems like you'd need to look at all the places we use eager today, or at least those under program-less components (like bootstrap, core, etc.)

Bryan Henry |

Software Engineer |

bryan...@google.com |

650-214-2312

On Thu, Oct 7, 2021 at 8:47 AM 'Gary Bressler' via component-framework-dev <component-f...@fuchsia.dev> wrote:

Hi team,

Component manager currently implements behavior where, if you bind to a component, it will automatically bind to all its ancestors. This is a holdover from when we held that parents should always run if one of their children is running. But since then, we have added features that discard this principle (e.g., `use from child`, in which case the parent may be stopped before the child). I uploaded a change that removes this behavior and ran it through CQ without any problems. Are there any reasons we can think of not to do this? Or any known places relying on this behavior which are not caught by tests?

--

[Gary Bressler]

Actually, without binding to core, it seems system-update-committer gets started anyway. Turns out it exposes a protocol so the eager isn't necessary? But you're right Bryan: it's not safe to just rely on CQ, and we should audit the uses of eager to be careful (although ideally I'd hope we'd have E2E test coverage for this). Fortunately there aren't many of these, and on an initial glance it appears that core is the only one that creates an issue.