Core shards need to be generalized?

[Shai Barack]

Assuming the reader is familiar with core_shard aka RFC-0089.

This change basically introduced an appmgr shard:

https://fuchsia-review.googlesource.com/c/fuchsia/+/533901

I can get away without all the build-time support because this component is in base, so there isn't really variability involved. But at some point we're going to see routes from core to appmgr's realm that only exist in some variants but not others.

Thoughts?

[Shai Barack]

"Sys shards"?

What happens after we've organized core into sub-realms, and then those sub-realms start varying?

[Shai Barack]

I know that RFC-0089 was an intentional compromise where we decided not to solve beyond core. I'm saying maybe it's time to plan the next step.

[Gary Bressler]

I think it makes sense to generalize RFC 89 to a select set of manifests other than core.

At the least, appmgr (for the reasons you mentioned) and session_manager (for routing between Modular and SFW).

--
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/CAK0PkCHhQQxekVUy%3D5iL%3DU5ZyRbyhNzNxq8ELQTwb2AvWT1p1g%40mail.gmail.com.

[Adam Barth]

I'm concerned about scaling up this mechanism.  When we discussed RFC-0089, the context was explicitly that this mechanism was a near-term solution that would need to be replaced.  Rather than scaling up this mechanism, we should consider replacing it.

Adam

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAK1yh2kEm-8RxzeCvQWB3q3ZOe-QG39TbGnY_Ov21HA%2BuN4MMw%40mail.gmail.com.

[Shai Barack]

The general problem may be more tractable if we break up the core realm into sub realms, as we've been considering for some time now. I think we should look in that direction for a general solution.

For the specific problem of varying sys in a manner that's consistent with how we've come to vary core, I think it's worth discussing whether the appmgr.cml variation problem is close enough, or coupled enough, with the core.cml variation problem to merit extending the core shards solution to also cover appmgr.

In a manner of speaking appmgr.cml is almost a direct extension of core.cml, or "core but for v1 stuff".

[Gary Bressler]

Continuing that train of thought, it may be possible to merge appmgr.cml and core.cml. core is currently non-executable so we can easily make it run a binary. With `use from child` landed we can now have core use capabilities from its children. This would also cut down on the routing.

That still leaves open the problem of how to vary subrealms, like network.cml (which isn't variable yet but is likely to be at some point). At least to start off, we could try to solve that by defining different packages for the network realm and varying core to select which network.cml package is included.

[Shai Barack]

Oh, merging the appmgr component with the core realm into one instance sounds interesting. Though we'd still want to organize it as multiple cml files, even if just for readability.

Will it let us get rid of those weak routes? What are some other pros and cons? 

[Gary Bressler]

We can definitely still use shards to improve the file organization. I don't think it would change any of the weak routes. A weak offer from core->appmgr would turn into a weak use (although I don't think those uses should be weak in general).

The only con I can think of is if we want to make core run another executable, it precludes that possibility (e.g., the component supervisor that was proposed before). But such responsibilities could just as well be combined with appmgr's binary.

[Justin Mattson]

Having 'core' run appmgr mixes concerns. In my conception the job of the core realm is to provide some level of organization in the form of various sub-realms and to define how those relate to each other. Over time things like "network", "bluetooth", etc. Mixing this organizational responsibility together with executing the v1 runtime I think creates confusion.

I think the base problem we have is that we need to provide flexibility about what is or is not included in the system. I don't think the best solution to this is to merge realms so that we can exploit the one place we've created the ability to vary things. Also, (as already observed) this only works once. As soon as there exists a product configuration with unique bluetooth profiles that something outside the BT realm needs, we're back where we are today.

That still leaves open the problem of how to vary subrealms, like network.cml (which isn't variable yet but is likely to be at some point). At least to start off, we could try to solve that by defining different packages for the network realm and varying core to select which network.cml package is included.

It makes more sense to me, again from separation of concerns, to use this strategy with all sub-realms, including appmgr. Is there some way in which appmgr is more special?

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAK1yh2kZw8mEZw%2BP8%2BTaOqKOxwqed-98S1OG0CMZ_WQ4G1sHsw%40mail.gmail.com.

[Adam Barth]

One strategy I could imagine for the CFv2 migration is to push CFv1 "down" the component hierarchy.  In this approach, we might have leaves of the component topology that are still running in CFv1 environments even if they view the rest of the system through CFv2.  At the moment, we have one big CFv1 leaf, but you could imagine splitting that apart and having multiple CFv1 leaves that eventually get pushed down the hierarchy and out of existence.

Welding appmgr into core would preclude that approach because CFv1 would be coupled to the "top" of the component hierarchy.

Adam

[Gary Bressler]

I don't think an architecture that merges appmgr with core is something we need to commit to long term, but it could be an answer for now if we accept the constraint that RFC-0089 may only be applied to core.

In practice, core and appmgr are closely coupled, since together they act as the system's nexus of capabilities. It's pretty uncommon to have a protocol that is only used in v2, and as the migration proceeds it will become less and less common to have a protocol only used in v1. Merging them into the same component would be a reflection of this reality. Topologically, it has basically isomorphic semantics.

[Adam Barth]

On Thu, Jul 8, 2021 at 10:18 PM Gary Bressler <g...@google.com> wrote:

I don't think an architecture that merges appmgr with core is something we need to commit to long term, but it could be an answer for now if we accept the constraint that RFC-0089 may only be applied to core.

In practice, core and appmgr are closely coupled, since together they act as the system's nexus of capabilities.

More precisely, it's core and sysmgr that are closely coupled in this way.

 

It's pretty uncommon to have a protocol that is only used in v2, and as the migration proceeds it will become less and less common to have a protocol only used in v1. Merging them into the same component would be a reflection of this reality. Topologically, it has basically isomorphic semantics.

I wonder if it makes more sense to consider sysgmr as the component that's being merged into core.  In this view, appmgr is something like a "runner" that adapts the CFv1 sysmgr into a CFv2 component that's tightly integrated with core.

In this view, you could imagine other islands of CFv1 components that use their own instances of appmgr to adapt into a CFv2 container.  The ability to divide-and-conquer the migration could be powerful.

[Shai Barack]

You're both right. We're just slightly conflating appmgr with appmgr.cml.

Separating "v1 sys" from "rest of v1" is an option. 

[Aaron Wood]

I agree with Adam on this, and I'm working on the early drafts of the RFC that would be used to supersede RFC-0089.  From my PoV, the sub-assemblies project is the expected replacement for RFC-0089, with RFC-0089 only happening because we needed _something_ while the groundwork for the next thing was being laid down (ie. RFC-0072 needed to be implemented before we could implement a replacement for RFC-0089).

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

[Shai Barack]

I don't mind waiting for that! 

[Gary Bressler]

I think Adam's idea sounds promising, but I'm somewhat fuzzy on how it would work. The current architecture bakes in the assumption that appmgr is a singleton. In particular, there's a bespoke integration between diagnostics platform and appmgr. The only place we create a separate instance of appmgr is a couple integration tests.

One idea is to have a single instance of the appmgr runner, but multiple components using that runner -- maybe this is what you had in mind? Each 'v1 island' is a v2 component that corresponds to a sub-environment, e.g. `sys`, `modular`, `test-env`.

Open question: how do the v1 environments get assembled in this design? Are they a flat hierarchy under `root`, and the routing between environments happens through v2? Or is it possible somehow to declare a v1 environment hierarchy in the manifest somehow?

[Adam Barth]

On Thu, Jul 8, 2021 at 10:56 PM Gary Bressler <g...@google.com> wrote:

I think Adam's idea sounds promising, but I'm somewhat fuzzy on how it would work. The current architecture bakes in the assumption that appmgr is a singleton. In particular, there's a bespoke integration between diagnostics platform and appmgr. The only place we create a separate instance of appmgr is a couple integration tests.

We used to run many copies of appmgr.  I'm not too surprised to learn we've grown a dependency on it being a singleton, however.  From what you've written, it sounds like they might be difficult to untangle.

One idea is to have a single instance of the appmgr runner, but multiple components using that runner -- maybe this is what you had in mind?

I literally had in mind running multiple instances of appmgr, but the single-instance approach you suggest might be the better way.

 

Each 'v1 island' is a v2 component that corresponds to a sub-environment, e.g. `sys`, `modular`, `test-env`.

Open question: how do the v1 environments get assembled in this design? Are they a flat hierarchy under `root`, and the routing between environments happens through v2?

The idea is to break apart the v1 world.  To get the benefit, we'd need to make sure the v1 islands interact only via v2 routing.  That way, each can be refactored internally to use more and more v2 machinery without changing its external interactions with the rest of the system.

 

Or is it possible somehow to declare a v1 environment hierarchy in the manifest somehow?

From the point of view of v2, each v1 island is just a single component (with unknown internal structure).

[Gary Bressler]

+crjohns and +yeg because I see applications of this idea to sessionmgr and hybrid testing. The current plan of record is to route the fuchsia.sys.Environment protocol from appmgr to the v2 realm. In a hybrid test, this means that a non-hermetic test gets services from two places: for v1 components, from sys, and for v2 from test_manager. If we created a sub-environment as a v2 component we could avoid the need to route the Environment protocol and route the same bundle of capabilities to the v1 and v2 environments.

[Shai Barack]

The idea being a nested appmgr in mixed test environments? Then yes, very interesting. 

[Gary Bressler]

Yes -- possibly, a component representing an environment within appmgr runner. There could be either one per test, or one nested under test_manager that creates sub-environments for each test.

[Aaron Wood]

On Fri, Jul 9, 2021 at 10:31 AM 'Gary Bressler' via component-framework-dev <component-f...@fuchsia.dev> wrote:

Yes -- possibly, a component representing an environment within appmgr runner. There could be either one per test, or one nested under test_manager that creates sub-environments for each test.

On Fri, Jul 9, 2021 at 9:44 AM Shai Barack <sha...@google.com> wrote:

The idea being a nested appmgr in mixed test environments? Then yes, very interesting. 

On Fri, Jul 9, 2021, 12:19 PM Gary Bressler <g...@google.com> wrote:

+crjohns and +yeg because I see applications of this idea to sessionmgr and hybrid testing. The current plan of record is to route the fuchsia.sys.Environment protocol from appmgr to the v2 realm. In a hybrid test, this means that a non-hermetic test gets services from two places: for v1 components, from sys, and for v2 from test_manager. If we created a sub-environment as a v2 component we could avoid the need to route the Environment protocol and route the same bundle of capabilities to the v1 and v2 environments.

On Thu, Jul 8, 2021 at 5:16 PM Adam Barth <aba...@google.com> wrote:

On Thu, Jul 8, 2021 at 10:56 PM Gary Bressler <g...@google.com> wrote:

I think Adam's idea sounds promising, but I'm somewhat fuzzy on how it would work. The current architecture bakes in the assumption that appmgr is a singleton. In particular, there's a bespoke integration between diagnostics platform and appmgr. The only place we create a separate instance of appmgr is a couple integration tests.

We used to run many copies of appmgr.  I'm not too surprised to learn we've grown a dependency on it being a singleton, however.  From what you've written, it sounds like they might be difficult to untangle.

+Justin Mattson and I were talking about something related last week, while talking about the v1 -> v2 migration and product assembly impacts:  Can we host v1 components in individual appmgr instances, and route the appropriate capabilities into each?  

 

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