Re: [virgo-dev] p2 & Virgo

[Dmitry Sklyut <dmitry@xxxxxxxxxxx>]

Just thinking out loud here:

With my _VERY LIMITED_ knowledge of p2 (reading
http://wiki.eclipse.org/Equinox/p2 now) ==>  p2 kind off replaces
Quasi phases.  That is p2 is not just another type of repository.  It
knows much much more about managed artifacts and has knowledge of
wiring and dependencies between them.  It basically replaces current
concept of repositories with a single p2 composite repository .

As a developer I would really like to keep concept of "pickup"/hot
deploy.  Restarting Virgo after each modification like Eclipse is not
something I am really looking forward to.  Can p2 "dropins" concept be
extended to support hot deploy semantics?  I would also really like to
keep "watched" repository concept where artifacts can be dropped into
after server start up and be ready for deployment when plan drops in
hot deploy directory.

I am going to read up on p2 now. Thanks!



On Wed, Mar 23, 2011 at 10:48 AM, Glyn Normington
<gnormington@xxxxxxxxxx> wrote:
> Hi Dmitry
>
> Thanks for joining in the discussion. This is a hard nut to crack, so your questions are invaluable!
>
> Please note Katya is taking the lead on the p2 aspects of the design with consultation from Pascal, so best to copy them on this thread. The SAP Virgo committers will be looking after the Virgo changes with assistance and advice from the other committers. I'm only just starting to understand the issues, so please take my comments with a pinch of salt. But here goes...
>
> Yesterday we were focussing on the use case of completely managing the contents of the user region via p2. At the other end of the spectrum is the current Virgo use case with mutable repositories and hot and manual deployment.
>
> There certainly are intermediate points in the spectrum, like you point out.
>
> I think to mix a p2 Repository with repository/ext, repository/usr and hot and manual deployment would require warm start to redeploy everything as today. So in this use case, p2 acts as a "normal" Repository and also initiates the deployment of some artifacts on cold start.
>
> We want to try and avoid multiple kernel builds, so somehow the position on the spectrum will need to be reflected in kernel configuration. I think the install stages, particularly QuasiInstall, QuasiResolve, and Commit stages, of the deployment pipeline probably need to be reworked or replaced in the "fully managed" warm start.
>
> Regards,
> Glyn
> PS. Katya and Pascal: please let us know if you are subscribed to virgo-dev so we can then avoid manually copying you.
>
> On 23 Mar 2011, at 06:41, Dmitry Sklyut wrote:
>
>> Few questions:
>>
>> 1. Is p2 an exclusive repository in this case?  i.e. can it coexist
>> with existing /usr/  /ext?
>> 2. no hot deploy with p2?
>>
>> Thanks
>> Dmitry
>>
>> On Wed, Mar 23, 2011 at 8:29 AM, Glyn Normington <gnormington@xxxxxxxxxx> wrote:
>>> I attach the notebook pages from yesterday's meeting as a memory-jogger.
>>>
>>> I have addressed this to virgo-dev to keep others in the loop. This was a meeting to discuss the p2 support in Virgo 3.0 while most of the committers (all except Dmitry) and some p2 experts (copied) were at EclipseCon.
>>>
>>> Here are some ideas I've had following the meeting. What do you think?
>>>
>>> I think we can configure the kernel to have a "managed user region" by starting it with a Repository (the Virgo type) backed by p2 instead of the usual repository/ext and repository/usr. The p2 Repository (sorry if this term is confusing!) could internally represent its physical artifacts in a p2-oriented manner as we discussed and then reconstitute them into the form that Virgo understands today when the artifacts are returned to Virgo from Repository accesses.
>>>
>>> The crucial property of a p2 Repository is that it is constant across warm starts of Virgo, so we have the possibility of recovering the runtime state rather than having to re-deploy everything. (The reason we have to re-deploy everything on warm restart today is because repository/ext, repository/usr, and pickup may have been changed while Virgo was down.)
>>>
>>> We also need the Virgo p2 support to drive the deployer API during cold start to deploy the relevant applications. (Note that this is applications plural since the web support is an application that we'll need in addition to the user's application.)
>>>
>>> We also need to control hot deployment in this set up. It may be as simple as turning off the hot deployer.
>>>
>>> Regards,
>>> Glyn
>>>
>>> _______________________________________________
>>> virgo-dev mailing list
>>> virgo-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>>>
>>>
>
>