| Re: [equinox-dev] [prov] Comments on wiki "Equinox p2 Shared Install Plan" |
> > > On Mon, 2007-12-17 at 13:44 -0600, James D Miles wrote:
> > > > If I was looking at this from the perspective of only RPM for the SDK,
> > > > you would likely be close enough.
> > >
> > > Sorry if it appears that's how I'm looking at it. I'm trying hard not
> > > to. Your comments are helping. And I'm definitely not looking at it
> > > only from the SDK POV.
> >
> > > > >> bundles.txt stored in user home.
> > > > >> YES. I would change that to stored in users workspace or preferable
> > > > >> user's configuration space.
> > > > > Yes, configuration space is more accurate. I just meant the user's
> > > > > writable location (I'm thinking something like ~/.eclipse/p2).
> > > > That is ok as a default maybe. However this decision should be
> > > > deferred until runtime. A user might want to run multiple instances
> > > > with multiple configurations.
> > >
> > > I guess I'm just considering sane defaults here. Are we closing the
> > > door on more exotic configurations?
> > Sorry, I don't understand your question.
>
> You said that decisions about where in a user's home directory stuff
> should be stored should be deferred until runtime. I don't see why
> can't provide sane defaults (like ~/.eclipse or something) but allow
> configurability for more exotic policy decisions. Are we somehow
> stopping your products from making this decision at runtime? I assumed
> it would just be ~/.<productid> or something if that's what you mean by
> "decide at runtime."
I have no problem with sane defaults. However, the true default should be buried in eclipse somewhere.
To provide a sane default that varies depending on the user would seem to mean that you would somehow have to wrapper eclipse native. We have gone through several iterations of controlling this.
- use eclipse defaults or expect a -data arg
- always provide the -data arg for sane defaults but still allow customer to override
- provide a symbolic definition of the data location in the launcher config file. It would look something like rcp.data="">
The last approach has been far superior to any other approach. Each product can have its own sane defaults and the customer can still override on the command line if desired. This implies launcher support for decoding the property.
> > > > >> If you want to populate the user's bundle.txt with sdk in shared
> > > > >> install then in can be driven as a root IU or profile. However this
> > > > is
> > > > >> a policy decision and should not be hard-wired as always happening.
> > > > >I don't know what you mean here.
> > > > One size does not fit all. One user might want bundle A from ABC and
> > > > another user might want bundle A from XYZ. The admin might want to
> > > > provision a limited functionality product for user A. And he might
> > > > want to provision prototype stuff for user B. This can all be driven
> > > > through the profiles/IUs.
> > >
> > > Sure, but I don't see how this is entirely related. Why can't the admin
> > > just use the admin UI or something? What's the advantage of a shared
> > > install if everyone's got a unique installation?
> > - one image for supported bundles or supported profiles.
> > - don't need a completely new image just because someone needs slight
> > variation.
> > If you allow the admin to use the admin UI and modify the rpm artifacts
> > does that cause a problem?
>
> Yes, since it invalidates the ability of rpm to verify contents (the -V
> option). I wasn't planning on explicitly dis-allowing it, but I'm not
> going to recommend it.
> > Actually we may not be that far apart. Maybe
> > some of our cases do not conflict.
>
> I'm glad to hear you say that :)
> > > > We have to be able to maintain our products in many ways, rpm being
> > > > just one. For instance the admin wants to upgrade a few bundles in the
> > > > shared install. One of the bundles may need the libpath modified to
> > > > point to the new native dll. If a bundle and IU can manage itself it
> > > > is a lot easier. We also have to support many platforms besides
> > > > RedHat. By containing/managing bundle artifacts on a bundle basis we
> > > > are much more efficient. Only the bundle developer needs to work on
> > > > the change.
> > >
> > > I'm having trouble understanding what you're trying to say here. You
> > > don't want to run certain phases and I do. What's the problem?
> > Sure I want to run all phases but in this way.
> > - During the collect and install phase we are preparing the image to be
> > used by the user. As you say copying and doing things that can't be
> > broken easily. In the case of shared install this requires admin authority.
>
> Okay.
> > - During the configure phase we are customizing the setup for the
> > specific user and his specific workspace
>
> This is where we differ. We're not doing any per-user or per-workspace
> customization. That is all done by the user.
Actually I think we are in complete agreement on this one. Your approach is different but we have the same goal. In your case you run RPM you have the equivalent configuration that would have been obtained by running the collect and install phases. At that point no user stuff is involved or at least shouldn't be involved. I think you have to do a little more work in this scenario. For instance if a bundle modifies the launcher config file then you have to account for that and any changes between versions. But it can be done.
However there is a config phase to be run even for RPM install. It is just deferred until the user starts the platform. Yes, RPM is not involved in that.
My point in all that is we want the same things and p2 multiuser execution paths are not really that disjoint.
> > For your case we are just
> > storing the user(admin) data in the shared tree so that it can be used
> > by all users.
>
> To what data are you referring here?
I am referring to all of the data that is normally written during the execution of eclipse. In eclipse prior to p2 the modifiable data could be found in the workspace directory (-data location_arg) or the configuration directory (-configuration location_arg). Anything else in the install tree could be assumed to be nonmodifiable (updates excluded). Under that model, we would find the bundles.txt in the configuration directory. In p2 I believe they are separating p2 bundle data out from the configuration area but it could be rolled back in using the eclipse.p2.data.area property. Being able to locate everything on a relative basis has been extremely important.
Have you thought about allowing mounts to your shared install?
> > - In the case of a native bundle that has to have a libpath set in the
> > environment, how would you handle? How would you handle an upgrade?
>
> Well, my knee-jerk reaction is "environment variables are evil and
> should be avoided at all costs" :) If the runtime couldn't find things
> in sane places by default, I guess I'd make some sort of wrapper script
> or something that set variables.
Well if we were writing global environment variables, I would agree. If and when we write them we are only modifying for the current process. And we are not expecting the customer to have to know about them. We are probably unsetting more than we are setting. "libpath" was just an example. We do customize a lot of Java system properties.
> > A more complicated case is the JVM.
>
> In our case we just Require (at the RPM level) a JVM and the rest is
> taken care of automatically.
>
> > Each JVM has a set of properties that
> > it should be launched with. In addition to these, there are properties
> > that each user or more likely a product configurator might add.
>
> Can these product properties go in a per-product file somewhere?
>
> > > > If the user is running multiple workspaces where one workspace uses
> > > > jdk A and one uses jdk B. It will be hard to manage the property
> > > > differences in an rpm.
> > >
> > > Why will the properties be in an RPM? We're (the Linux distros) not
> > > providing RPMs of workspaces -- just the runnable bits.
> > Some products ship with a JVM. In the case of XPD product, we ship with
> > jclDesktop but provide an update site so they can change to J2SE. So in
> > this case the jclDesktop would be in the shared space. How would you
> > reconcile jclDesktop in shared bundles.txt and J2SE in user bundles.txt?
> > Or how would you accommodate jclDesktop and J2SE in the shared space?
>
> This is a situation I was explicitly designing against. Having users
> override shared behaviour significantly reduces the benefits of having a
> shared installation and makes manageability a nightmare.
Fine by me. That is an implementation decision. This should not have an effect on other implementations.
> > > 1) user home directories shouldn't (and sometimes can't) be touched by
> > > an RPM installation
> > I agree. And conversely the user process should not modify the shared.
>
> Of course. They won't be able to in our case due to permissions.
Same here.
> > Creating a bundles.txt from root IUs is provisioning in its simplest
> > form. Aren't root IUs described in the profile?
>
> Yeah, but I'm proposing not having a profile.
I don't see what difference this makes since you are not supporting upgrades except through RPM. If you are allowing the admin to customize (even though it is not recommended) then a profile should be included. I could be wrong here, I don't have a good enough understanding of our profiles and root IUs yet.