Home » Eclipse Projects » P2 » Shared install vs. bundle pooling
|
Re: Shared install vs. bundle pooling [message #901500 is a reply to message #901465] |
Mon, 13 August 2012 07:37 |
Roland Tepp Messages: 36 Registered: July 2009 |
Member |
|
|
Yes, I second this question.
I consider myself a fairly advanced Eclipse user, but every single time
I have tried to set up bundle pooling on my machine, I've basically hit
a brick wall of all kinds of unhelpful noise.
I think the bundle pooling scenario should definitely get much more love
from both - documentation and tooling side. The final choice to
ultimately use or not use bundle pooling should end up with the user,
but it should imho be made much more approachable to those who want to
muck aroud with this.
I think the main usage scenarios from the top of my head that should be
covered should be following:
* Installing a common bundle pool (an installation manager product?)
* Installing an eclipse product (Classic, JDT, CDT, EE, etc) to/from
bundle pool.
* Installing new features/plugins in a pooled product
* Uninstalling a feature/plugins in a pooled product
12.08.2012 21:34, Stephan Herrmann kirjutas:
> The resurrection of https://bugs.eclipse.org/281510 reminds me that
> shared install is not as powerful as people would like to think (in
> short: working on top of a shared install users can not update any
> installed bundles which includes installation of a patch feature --
> software like Object Teams or Groovy-Eclipse simply doesn't work in this
> scenario!).
>
> OTOH, I remember people saying that since we have p2 we have a much more
> powerful concept: bundle pooling.
>
> My question is: what can we do to promote bundle pooling for ordinary
> users and to fade out shared installs?
>
> Currently, I'm not aware of a HowTo that tells you how to leverage
> bundle pooling without needing to become a p2 wizard first. Shared
> installes, OTOH, "just happen" if you follow the convention that any
> software shall initially be installed by admin/root. If you do so and
> just add more plugins during regular usage as a regular user you'll
> automatically end up with a "shared install".
>
> IMHO, this situation should be reversed: bundle pooling should be
> actively offered and shared installs should be discouraged. I understand
> that both concepts address partly different requirements, but they
> overlap in the capability for sharing installed software.
>
> BTW, I'm also fine if users would be globally advised to install Eclipse
> using regular user permissions and entirely avoid the sharing issue. I'm
> sure everybody has the disk space to do so.
>
> best,
> Stephan
|
|
|
Re: Shared install vs. bundle pooling [message #901915 is a reply to message #901465] |
Wed, 15 August 2012 02:25 |
Pascal Rapicault Messages: 333 Registered: July 2009 Location: Ottawa |
Senior Member |
|
|
I'm glad that you are bringing up this discussion.
Bundle pooling and shared installs are orthogonal to each others as they each provide different capabilities addressing different use cases. Here is below a description of each
- Shared install refers to an installation that resides in a read-only folder. This is not a concept of p2 itself, but rather describe the mode in which p2 is running when it encounters such a situation. Note that this situation occurs as soon as the running the user does not have the permission to write in the install folder of eclipse. This most notably happens on linux when eclipse is installed by the super user or on windows when eclipse is installed in the program files folder.
So what does the shared install "mode" imply? Shared install mode enforces immutability of the base (what is in the read only folder). This means that when the end user tries to install something in such an install, the software being installed will not be able to install or uninstall plugins that are in the base. All the IUs constituting the base are locked. This explains why feature patches can't be installed by the user in such a scenario.
Could this be changed? Yes. Back in 3.5, the locking was done differently and it allowed plugins to be changed. However this was a bug and caused problems to people relying on this immutability.
Could we change the code to work better for patches? probably.
- Bundle pooling refers to the idea of sharing files on disk between multiple installations of eclipse. The motivations for this support are: faster install (since you don't redownload the common pieces), saved disk space, possibly faster startup with VMs doing sharing. This is a fully supported mode of eclipse and it has been put into production by EclipseSource in their Yoxos offering.
The difficulty with this mode is that you can't just go to eclipse.org and download a distro with bundle pooling since the idea is that you would for example put your plugins in c:\bundle_pool\ and your install in c:\epp-jee (the install folder). For non sophisticated users, this means using an installer that you then run. However this makes the obtention of eclipse a bit more complex than the simple unzip and run steps that people are used to, and it also makes the installation process to the mercy of network issues, etc.
For sophisticated users, you can use the director with the -bundlepool option to the location of your choice instead http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fp2_director.html&resultof=%22bundlepool%22.
Know that bundle pooled installs come with certain restrictions: you can't just move the install folder around anymore, deleting the install folder will not immediately reclaim the disk space, busting the bundle_pool will kill all of your install
On top of that you can mix and match the two to get a shared install where the bundles are pooled
HTH
Pascal
|
|
|
Re: Shared install vs. bundle pooling [message #902082 is a reply to message #901915] |
Wed, 15 August 2012 18:46 |
Stephan Herrmann Messages: 1853 Registered: July 2009 |
Senior Member |
|
|
Hi Pascal,
thanks for your explanations. I think we're pretty much on the same page, although I wouldn't go as far as saying
Pascal Rapicault wrote on Wed, 15 August 2012 04:25
Bundle pooling and shared installs are orthogonal to each others ...
"Orthogonal" would say that projecting one onto the other would create an image of size zero, whereas people only interested in saving disk space might draw benefit from either approach, so I do see some overlap, but lets conclude, yes: these are different concepts.
Quote:
- Shared install refers to an installation that resides in a read-only folder. This is not a concept of p2 itself, but rather describe the mode in which p2 is running when it encounters such a situation.
Well, p2 seems to accept the challenge by allowing people to install software on top of a read-only install. From here on, I'd call it a mode of p2
The most consistent (but truely draconic) behavior would be: if the install is read-only "Install new software..." is completely disabled. I'm not advocating this but mention this to illustrate what I mean be "accept the challenge".
Quote:
So what does the shared install "mode" imply? Shared install mode enforces immutability of the base (what is in the read only folder). This means that when the end user tries to install something in such an install, the software being installed will not be able to install or uninstall plugins that are in the base. All the IUs constituting the base are locked.
Since p2 defines what "install or uninstall" means, the above is already based on a design decision that I wouldn't consider inevitable. I believe p2 could still override things from the read-only area (think inheritance: don't edit the super-class but add a sub-class). I agree that uninstalling things might be unexpected for users, but I don't see conceptual blockers for overriding.
Quote:
Could this be changed? Yes. Back in 3.5, the locking was done differently and it allowed plugins to be changed. However this was a bug and caused problems to people relying on this immutability.
I'm not sure I understand the expectation of those people: is that, a boss wants control over what software her employees use? As long as a developer still has the option to install his own copy of Eclipse in a private location, that control is void, no?
Quote:
- Bundle pooling refers to the idea of sharing files on disk [...].
The difficulty with this mode is that you can't just go to eclipse.org and download a distro with bundle pooling
Exactly.
Quote:For non sophisticated users, this means using an installer that you then run. However this makes the obtention of eclipse a bit more complex than the simple unzip and run steps that people are used to, and it also makes the installation process to the mercy of network issues, etc.
I think these are difficulties (some) users are used to. Question is: does such in installer exist? Is it being promoted for use?
So, apart from minor interpretations we can agree on most of what you wrote.
The reason I brought this up is: IMHO it is too easy to unknowingly get into a situation that later turns out to be a dead end, marked by: "game over, insert a new coin to try again", meaning:
- you follow "best practice" to install Eclipse in a "protected" way (making it read-only)
- you start installing your initial favorite 99 plug-ins and configure everything to your taste
- later you try to install item 100 from your list and find that this doesn't work on a shared install (either because a patch is included, or a dependency on a newer version of s.t. already installed).
I say "game over" because indeed you have to start over installing, not only if you insist on installing item 100, but also because the failed installation attempt breaks p2 to the degree that any future install actions are refused.
In its new form bug 281510 adds insult to injury: p2 no longer tells that anything went wrong.
I don't mean to fall back into the habit of p2 bashing (honestly, p2 has much improved since those days), but I do see the need for action, e.g.:
1. bug 281510 should be fixed
2. when invoking "Install new software" on top of a shared install, a warning could be shown, explaining the limitations of what can be installed - right when you begin to enter this alley, not just at its end
3. alternatively, installing on top of a shared install could open an authentication dialog in order to install into the protected install actually.
I have no idea if option (3) is feasible, but I guess this would cause least surprise. As a bonus, users might want to mix private additions and updates into the protected install - might be confusing though, not sure.
If none of these are adopted, I'd urge Eclipse to put up highly visible signs of warnings that read-only installations are not recommended. I'd be fine with that, too.
Giving choice to users is good, making it easy to unknowingly run into a dead end is not. Either fix the alley so it's no longer a dead end, or put up signs, right?
cheers,
Stephan
|
|
|
Re: Shared install vs. bundle pooling [message #902503 is a reply to message #902082] |
Sat, 18 August 2012 01:09 |
Pascal Rapicault Messages: 333 Registered: July 2009 Location: Ottawa |
Senior Member |
|
|
>Well, p2 seems to accept the challenge by allowing people to install software on top
>of a read-only install. From here on, I'd call it a mode of p2 Smile
>The most consistent (but truely draconic) behavior would be: if the install is
>read-only "Install new software..." is completely disabled. I'm not advocating this
>but mention this to illustrate what I mean be "accept the challenge".
I may have forgotten, but p2 indeed supports addition on top of the base. This was a must have scenario such that people who are using eclipse distributed with their OS could to extend it without having to force the OS vendors to package every plugin of the ecosystem.
There are three main reasons to enforce immutability of the base are:
1) not all software installed in the base can actually be replaced. This is either because the software expects a certain layout on disk and installing new versions as a user would not respect this and would make it look like it worked when it did not. And yes developers of the IU could annotate, but in reality nobody knows or think to care about this used case and p2 would be blamed. The most immediate case that comes in mind if the platform itself.
2) control of a basic environment. Many corporations goes through great length to make sure that everybody uses the same version of eclipse. By allowing eclipse to be installed in a base and locked, then they have a minimal guarantee, and yes some ppl remove the UI. In addition to that, allowing everybody to run from the same install allows for easy update of all my developers.
3) match with the semantics of the OS.
The installer has been promoted a bit at the beginning of p2 but we took it down since almost nobody used it.
> later you try to install item 100 from your list and find that this doesn't work
>on a shared install (either because a patch is included, or a dependency on a newer
>version of s.t. already installed).
>I say "game over" because indeed you have to start over installing, not only if you
>insist on installing item 100, but also because the failed installation attempt
>breaks p2 to the degree that any future install actions are refused.
This is news to me. If you have steps where you end up completely busted without the possibility to revert, please lmk.
>3. alternatively, installing on top of a shared install could open an authentication dialog in order to install into the protected install actually.
We have been looking into this in the past (https://bugs.eclipse.org/bugs/show_bug.cgi?id=322477 / https://bugs.eclipse.org/bugs/show_bug.cgi?id=343768). This is the best way to solve this whole issue, but nobody has the time or interest to investigate how to do process elevation.
>bug 281510 should be fixed
agreed
|
|
|
Re: Shared install vs. bundle pooling [message #902583 is a reply to message #902503] |
Sat, 18 August 2012 16:09 |
Stephan Herrmann Messages: 1853 Registered: July 2009 |
Senior Member |
|
|
Pascal Rapicault wrote on Sat, 18 August 2012 03:09 There are three main reasons to enforce immutability of the base are:
The reasons per se make sense, but I simply don't understand why people are so keen on an enforcement that's so easy to bypass: users just have to unzip their private copy of Eclipse.
I think compared to this kind of prohibition, positive techniques are much more effective:
- provide company wide mirrors of selected software (versions)
- provide per-team / per-department composite features, etc.
Such steps make it easy for developers to stay in sync with a recommended environment, without imposing arbitrary technical barriers. My 2c.
Quote:The installer has been promoted a bit at the beginning of p2 but we took it down since almost nobody used it.
That's a pity. Maybe at the beginning of p2 ppl. where just struggling with other difficulties. Maybe now it would be better embraced ...
Quote:>I say "game over" because indeed you have to start over installing, not only if you
>insist on installing item 100, but also because the failed installation attempt
>breaks p2 to the degree that any future install actions are refused.
This is news to me. If you have steps where you end up completely busted without the possibility to revert, please lmk.
With the scenario of bug 281510 it's easy to get into the situation where its impossible to make any step forward. Frankly, I didn't try going individual steps backwards. Trying this now I see that revert brings me back to what seems to be a good state. But, honestly, as a user it doesn't feel very safe to just go back this one step after p2 got busted so badly
Quote:
>3. alternatively, installing on top of a shared install could open an authentication dialog in order to install into the protected install actually.
We have been looking into this in the past (https://bugs.eclipse.org/bugs/show_bug.cgi?id=322477 / https://bugs.eclipse.org/bugs/show_bug.cgi?id=343768). This is the best way to solve this whole issue, but nobody has the time or interest to investigate how to do process elevation.
Thanks for the pointers. Interesting read. Regarding UI consistency I added https://bugs.eclipse.org/387534 to the bunch.
best,
Stephan
|
|
| | | |
Goto Forum:
Current Time: Wed Dec 11 03:38:07 GMT 2024
Powered by FUDForum. Page generated in 0.03524 seconds
|