meeting: bundle deployment to non-platforms

John Mazzitelli mazz at redhat.com
Fri May 27 15:15:12 UTC 2011


> * I'm not sure I like the idea of mixing type knowledge (from the plugin
> descriptor) with recipes.   It just seems like it may open a can of
> worms with respect to upgrades.  And possibly may limit the ability to
> develop other bundle handlers (not that that was really on the horizon,
> though).  Waiting to see what Mazz's design doc revisions come up with
> here...

good points about the possible upgrade issues and the different bundle 
handlers. I'll think about this as I add to the design wiki page.

> * Originally bundles were designed to lay down complete servers (app
> server with apps already in place, etc).   The latest proposal moves
> toward smaller, one-off  deployments.  We may need to work out the
> semantics around when one bundle's deployment dir is a subdir of another
> bundle's deployment dir.  For example, bundle-1 is an app-server and
> bundle-2 is a web-app.  And then bundle-1 gets reverted...

yet another good question - we need to think about this. deploying a 
bundle inside a bundle will be problematic.

> * Question - where is the deployment meta-data kept?  It can't be stored
> under the deploy directory, right?

and yet another good question. We do support the ability to deploy 
bundles in the deploy/ directory (if you enable that new feature where 
the recipe tells us to not fully manage the root dest dir). HOWEVER, you 
can only deploy ONE bundle to it. You can't deploy more than one because 
the metadata will overlap/overwrite each other. So this is something 
else to think about.


More information about the rhq-devel mailing list