Re: [p2-dev] Subsystem provisioning

["Todorova, Katya" <katya.todorova@xxxxxxx>]

Hi, 

You can find answers inlined. 
I hope this conversation will help us gather a consistent list of requirements and will let us come up with a reasonable concept covering that topic. 

Thanks for you comments, 
Katya 

 > -----Original Message-----
> From: p2-dev-bounces@xxxxxxxxxxx 
> [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Pascal Rapicault
> Sent: Monday, January 24, 2011 9:18 PM
> To: P2 developer discussions
> Subject: Re: [p2-dev] Subsystem provisioning
> 
> I'm not completely familiar with Virgo or the fwk hooks, but 
> the first thing that comes to mind when I hear subsystem is 
> "isolation" and "conflicting dependencies", in the sense that 
> each subsystem is relatively isolated from each other, and 
> can therefore have dependencies that are conflicting with 
> each others (e.g. two different version of the same 
> singletons). Is this correct?

Yes, subsystems are about isolation at runtime - they can be considered as different systems which are able to communicate to each other by sharing resources (packages, services, properties, etc). 
So the problem with conflicting dependencies when you install two different versions of singletons in one OSGi framework wouldn't exist if you install them in two subsystems. (Of course, it depends 
on how you define the visibility rules) 
 
> Consequently, when I look at this from a p2 standpoint, the 
> first question that comes to mind is how are we going to do 
> dependency resolution? Also in a more advanced scenario how 
> do the two subsystem evolve?

The dependency resolution mechanism should be aware somehow that installed artifacts are part of different subsystems and resolve against corresponding framework state. Currently in p2 there is 
one profile per installation, so a naive solution could be introducing a flag in the profile format and filter its content depending on that flag during resolution. Or for example sub profiles could be 
created to reflect existing subsystems. A lot of questions pop up - how would you trigger installation in a particular subsystem, would the profiles be isolated or would they share some pieces of information, etc.  
There are many possible solutions, all with their benefits and drawbacks. The challenge is to find the one which best fits in the p2 architecture.  
What do you think, from p2 point of view, what means "isolation"? 

> The second question that I have is more closely related to 
> the runtime in the sense that how does the framework know 
> what to put in each "subsystem" ? Does each subsystem need to 
> be in its own bundles.info file, or should they actually be 
> merged in one? Where does the description on how to configure 
> come from?

As far as I know the decision what to put in different subsystem (or what part of the framework is seen by each of the subsystems) is responsibility of the system "owner" and could be defined via 
configuration or programmatically. There are several open questions here: when do these visibility rules become active, could they change at runtime and what they have to do with p2 profiles (which are the ground for p2 resolving) 
I don't think we have strict requirements how many bundles.info file we have as long as the OSGi framework is presented in a consistent way. In my opinion, it's easy and straightforward to map 
one bundles.info to one OSGi framework and leave the hooks to deal with visibility (resolving) at runtime. In that sense subsystems and p2 will complement one another without any conflicts.
Of course this is just one piece of the problem and should be considered in the whole context of profile isolation. 

> Finally what is interesting about this usecase is that, 
> though the runtime aspect seems to relate to OSGi and fwk 
> hooks, the more general usecase goes around how to describe / 
> provision multiple applications (e.g. if I wanted to install 
> m2e and maven in one shot, or if I wanted to install all of 
> RAD that is composed of multiple small apps at once).

While the upper questions address the installation part, I think here we talk about publishing and associating an adequate meta information with the IUs.  Since both p2 repository and profile are used for 
dependency resolution they need to be in sync of what a subsystem is. No idea how the magic metadata looks like though:)

> All that said, though these scenarios have been discussed in 
> the past, I don't have a solution in mind :)
> 
> On 2011-01-24, at 8:38 AM, Todorova, Katya wrote:
> 
> > Hi, 
> > 
> > As subsystems are getting more and more used nowadays, here 
> comes the logical question how to provision them in a standard way. 
> > Eclipse Virgo using subsystems to model its runtime is one 
> example. Currently, it is very hard to install and even 
> harder to update a particular Virgo subsystem with existing p2 tools.
> > Subsystem concept (rfc152) is not supposed to define 
> initial provisioning process. Do you think p2 should be aware 
> of subsystem existence and could fill that "gap"? 
> > 
> > Thanks in advance for your comments, 
> > Katya
> > 
> > _______________________________________________
> > p2-dev mailing list
> > p2-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/p2-dev
> 
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/p2-dev
>