| 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.
> > >> If bundles.txt is missing from the user's workspace then it needs
> > to
> > >> be populated with the shared bundles.txt.
> > > Why can't it just run from the shared bundles.txt?
> > Ahh. That was a bad paraphrase of what I thought you indicated. So if
> > you load the shared bundles.txt how do you get a user's bundle.txt?
> > How long do you use the shared?
>
> I envision shared stuff being in the shared bundles.txt and
> user-specific stuff being the user bundles.txt. They don't overlap.
This works for me if I can find the bundles.txt referenced by a profile/rootIU (not sure which) and the bundles.txt is just a core and does not represent an entire sdk or whatever. This solves the problem of how to replace a defective provisioning core and also how to always use the latest core. This guarantees it will run. If the provisioning core has a problem building the final configuration it will have logs and all that gorp. In some ways this is a subset of your case. We have a smaller bundles.txt and we do not explode artifacts all over the drive.
> > >> 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?
> > >> The act of provisioning the bundles also allows for the
> > >> unfolding/customizing of additional artifacts related to specific
> > >> bundles. An example of additional work would be creating user
> > ICONs,
> > >> setting environmental variables.
> > >>
> > >> What we are really talking about is running only a configuration
> > phase
> > >> to get the user's bundle.txt up to the latest. The phases collect,
> > and
> > >> install are not wanted.
> > >
> > > This is not ideal for the Linux distribution case. We want things
> > to be
> > > completely ready to go after the user installs the packages.
> > .desktop
> > > files and other metadata is just shipped in the package and put in
> > the
> > > right place upon installation so there's no need for additional
> > > configuration in this case.
> > It is nice that you can still do that. That is far from ideal for us.
>
> That's unfortunate :( .
It just means that we have to be flexible to be successful. Our product is the core of Notes 8, Sametime, and LWI. And of course external customers build on it also. Actually we may not be that far apart. Maybe some of our cases do not conflict.
> > 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.
- During the configure phase we are customizing the setup for the specific user and his specific workspace. These actions do not require admin authority but user authority. In my use case for shared install all we would be doing is configuring the admins workspace. In your use case we would be configuring the shared bundles.txt. These 2 use cases could be special cases of a more general case. For your case we are just storing the user(admin) data in the shared tree so that it can be used by all users.
- 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? Here is how it would be managed in our use cases
- after the install is complete, no libpath change yet.
- user initiates product start
- launcher detects that this is a first launch (or could be a modified profile)
- launcher initiate a provisioning cycle.
- changes are reconciled. In this case each bundle gets configured.
- during the configure of the libpath bundle, a libpath property is written to the user's launcher property file.
- at the end of the provisioning phase a restart of the platform is initiated.
- launcher restarts and sets the libpath env for process.
- If the libpath bundle is upgraded, the unconfigure would remove the libpath property and the configure would write the new libpath property.
So basically all that has to happen is for the libpath bundle developer to describe the property in his bundle and the correct things happen when a bundle is configured or unconfigured.
A more complicated case is the JVM. What I am going to describe is how we do it now. No doubt it would need to be refactored to suite the new p2. If I only had more time :>(. 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. The path chosen was to keep the JVM properties needed for launch with the bundle. On launch the launcher reads this file and adds the values to the launch args. It also adds the user specific JVM properties. This solution has some hair. The problem is that the Xargs and vmargs are wildly unstructured. The end result is that one can provision upgrades to a JVM or even provision different JVMs on the fly (with a restart). The downside is that they have to be packaged. It is also possible to run with a system installed JVM but this loses the JVM preconfiguration. To obtain the ability to provision totally different JVMs we structured each JVM as a child feature of a parent. We assigned a major version number for each JVM. This meets the definition of major number holding incompatible products. It could cause problems if you always assume the highest version should be installed.
> > 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?
> > Are you saying that an admin will only upgrade the shared install
> > through rpm and the update UI can not be used?
>
> The admin UI *can* be used, but in the Linux distribution case, I
> envision people will largely use their packages. That's what people
> (including me) want to do :) .
> > >> Materialize profile from running bundles.txt
> > >> I am suggesting it is better to materialize bundles.txt from the
> > >> profile.
> > >
> > > It's difficult and fragile to do profile manipulation with headless
> > > package installation. I'm specifically talking about the
> > installation
> > > of additional bundles here: CDT, Mylyn, etc. Pascal mentioned that
> > he
> > > has some in-progress code that will allow the materialization of
> > > bundles.txt from the running instance and a set of root IUs.
> > I am not sure why it should be harder. One way or another we have to
> > have a profile/profile(s) that represents the configuration that the
> > user will run with.
>
> It's harder for a few reasons:
>
> 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.
Creating a bundles.txt from root IUs is provisioning in its simplest form. Aren't root IUs described in the profile?
>
> 2) the order of laying down new files and deleting old files and trigger
> scripts (ex. %post, %postun of old and new) doesn't really lend itself
> to profile modification. If one of these scripts fails, it'll kill the
> entire transaction -- including a fresh installation. If we try to trap
> failures, we may end up with a non-runnable state. I want to keep
> things as simple as possible for package-based installations where we
> just lay down the bits and the runtimes does The Right Thing.
> > So after CDT is installed it seems that we would still need profiles
> > and rootIUs that represent the installation or we will not be able to
> > make decisions about updates. If we start driving from both ends it
> > has to be harder.
>
> I was talking about root IUs with Pascal and he thinks we can use local
> metadata repos for this.