Re: [virgo-dev] Virgo & p2 use cases

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

 Hi Glyn, 

The difference among the Virgo deliverables is only the list of initial artifacts specified in userregion.properties? 
Currently which are the config files which are expected to be modified by hand after the uzip? 

The second use case should be just initial provisioning of Virgo. Here we still don't have p2 inside it. 
I mean the zip content and the result of p2 installation should be the same so there is nothing specific/new in starting Virgo (no p2 to delegate the startup to).
Here you can consider initial p2 installation as an alternative to uzip. For the end user there won't be a difference in terms of functionality between these two use cases, 
he will just have two options for "downloading" Virgo to his local machine.

The third use case is having p2 inside Virgo - as soon as the server is started p2 is used to install the additions or updates if there are such. 
Here p2 should update the Virgo config files. The questions above are related to this use case. So are Pascal's questions I guess. 

My point is that the initial provisioning is not coupled with the Virgo architecture (whether it uses p2 or not for example).
The end user can decide independently:
 -  how to get Virgo (uzip or installed by p2) and 
 -  what kind of distribution to have (with or without p2 support, kernel/jetty/web, etc) 

Does this make sense?

Thanks,
Katya

> -----Original Message-----
> From: Glyn Normington [mailto:gnormington@xxxxxxxxxx] 
> Sent: Wednesday, February 16, 2011 10:49 AM
> To: Pascal Rapicault
> Cc: Virgo Project; Todorova, Katya; Stanev, Georgi
> Subject: Re: Virgo & p2 use cases
> 
> Hi Pascal
> 
> On 16 Feb 2011, at 04:23, Pascal Rapicault wrote:
> 
> > In this description, what is "Virgo"? The container and the 
> application, or just the container?
> 
> For these use cases there are currently three Virgo 
> deliverables that we should take into account:
> 
> Virgo web server includes the container and some 
> pre-installed applications: the splash screen, web admin 
> console, and hosted repository server.
> 
> Virgo kernel includes just the container and no apps.
> 
> Virgo Jetty server includes the container and some pre-installed apps.
> 
> > 
> > Where does the use case of "the user downloads virgo, 
> starts it and install an application using p2" fit?
> 
> That's a good use case, but not one that I need to draw to 
> people's attention as it is already high on the list from a 
> Virgo & p2 perspective.
> 
> > 
> > How much flexibility is there in terms of changing the 
> layout of the actual runtime to maybe make it more 
> "manageable" from a p2 standpoint and still accommodate the 
> two scenarios?
> 
> Quite a lot, some of which has been tried already. We simply 
> need to ensure that the user's tasks in these use cases is 
> not made more difficult. In particular we need to ensure that 
> configuration is not duplicated and that configuration is 
> documented as well, and edited as easily, as today's property files.
> 
> Regards,
> Glyn
> 
> > 
> > On 2011-02-15, at 10:33 AM, Glyn Normington wrote:
> > 
> >> Following last week's discussion of p2, I would like to 
> ensure that the following use cases work when we eventually 
> integrate Virgo and p2:
> >> 
> >> 1. Unzip and go - the user downloads and unzips Virgo, 
> edits config files, and runs a startup script, much like in 
> 2.1.0. No need to invoke p2, although it is acceptable for p2 
> to run under the covers.
> >> 
> >> 2. Provision Virgo via p2 - the user uses p2 to provision 
> and start Virgo.
> >> 
> >> 3. "Hybrid" - the user uses p2 to provision Virgo, edits 
> config files, and runs a startup script, the latter two steps 
> much like in 2.1.0.
> >> 
> >> Regards,
> >> Glyn
> >> 
> > 
> 
>