Dependencies

Hi RC -

Good questions.

Elastic Server can be thought of as a "meta packaging" system in that it uses other systems rather than attempting to re-do existing packaging.

In the event of upstream mirror stuff that can be used by apt-get or yum - we let those dependencies kick in. So when we use our admin function to point to a mirror package "foo" then when someone uses "foo" in a bundle - then they get "foo" plus its dependencies.

(In general we have been trying to figure out how to open the upstream mirror pointer functionality in the UI for users besides our admins, as well as let people type in dependencies)

"Bundles" are a form of simple declarative dependency which says "these things should all go together". A good example is rather than having a bundle with just a .WAR file, make a bundle with an appropriate Java, Tomcat and a .WAR. Bundles do not let you specify the order in which those things go in. Which in APT-related things is usually ok - because post-install scripts run after all the installs. In YUM-related things the post-installs run after each individual install, then things can go wrong. In our own usage this has pushed too many things into "run on first boot scripts". This has us thinking about letting you specify an order for the things to install via "loops of loops" if you want.

We have a "can't work together" database which we populate as a result of assembly failures. Things like "Package foo can't work with package bar". We would also like to open this up to other users for their own use.

Our current implementation attempts to bootstrap runtime language artifacts (ruby, java, python, etc) off of the APT and YUM capabilities as a result of the BYO import function basically putting them into a .deb or RPM. This has had mixed results.

The way I deal with Ruby Gems is to import them in a file system tree, then do a post-install script which does a local install. That way I am only getting things that I know I packaged up and I don't have a dependency on an outside mirror which may or may not respond at server assembly time.

Collisions can occur as in your example. Since we can't possibly know all the combinations that can't work - we use our conflict database. So when one user discovers a bad path which won't assemble because of dependency errors we put a rule in the database so the next person who tries those particular packages together gets a message "Foo won't work with Bar, please unselect one of them to proceed with your assembly.

Based on our experiences, and our user's experiences, we are looking at how to put more control in your hands, and to make the system more "URI" based, meaning rather than make you import an upstream package, we should just let you tell us the name, type and location of an artifact and the assembly nodes should then use the native installer for that artifact.

Follow up questions and comments invited. Happy to have a chat as well and hear your ideas in person.

pat k