Re: [equinox-dev] [prov] Comments on "Equinox Provisioning Engine" Wiki

[James D Miles <jdmiles@xxxxxxxxxx>]

Most of these questions and requirements center on how to implement a multiuser implementation. I will post information on that in bug 185826 today, hopefully. Then we can continue the discussion as appropriate. Sorry I am so late to the party.

Simon Kaegi <Simon_Kaegi@xxxxxxxxxx>

Simon Kaegi <Simon_Kaegi@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

09/07/2007 09:31 AM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] [prov] Comments on "Equinox Provisioning Engine" Wiki page

equinox-dev-bounces@xxxxxxxxxxx wrote on 09/06/2007 10:28:55 AM:

> Simon thanks for adding the info to the wiki. I have a lot of
> questions and comments but will constrain myself to a few here. Once
> these are clarified I will attack the remainder.
>
> In the section "Engine processing model and phases"
> You list collect, validate, uninstall/unconfigure,...
> Is this the order that an operation is asked if it wants to participate
in?
That's right, the engine will run over the phases in order. The list of
phases provided on the wiki is really a starting point as they fit with the
code we have in the engine.
I'm hoping we will have stable set of phases sooner rather than later as
this can affect operations and also the touchpoint action content in IUs
when we get to that.

> The uninstall/unconfigure is not clear. I view these as separate
> phases. And unconfigure would come first.
> In general I don't know what is meant by the use of the '/' means.
The '/' was meant to denote uncertainty.
Originally I did put in the various associated config phases however when I
actually went to the coding it felt redundant.
e.g. we *always* did the unconfig, migrate, initconfig when doing the
paired up uninstall, update, or install phase. We can look at re-adding the
phases however I'd like to have some rational. Perhaps the logical
separation of the type of work done is sufficient(?)
>
> For the "We should move to a model where we pass a set of operations
> with internal operands." comment.
> Are we saying that we don't want to allow externally specifying the
> phase to stop on? It is not clear to me what we are proposing.
>
In the prior model we had one operation (e.g. install) with many operands
(the IUs)
What has changed is that we now "perform" multiple smaller self contained
operations. e.g. install(IU1), install(IU2), uninstall(IU3).
This gives us some flexibility on the sorts of changes we can apply to a
profile.

The second part where you mention specifying a phase to stop on is
interesting...
It might be easiest to just create an operation that participates in a
smaller set of phases. That's an area open to discussion as originally I
was hoping to have a small set of operations however it looks like we might
have a fixed set of phases so I'm not sure it's as critical. Hmm...

> Is it possible to add 1 or 2 sentence definitions to what is
> performed in each phase? I think that would open up the discussion.
Yes definitely.
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev