more specific bundle targets

smillidge at c2b2.co.uk smillidge at c2b2.co.uk
Tue Mar 22 20:35:53 UTC 2011


Just my 2cents worth. Don't assume anything about deployment locations for different app server types for example /deploy for JBossAS as these are just convention and easy to change.

For example one best practice for JBoss in large productions is to lock down /deploy for just JBoss stuff make readonly and create another /customdeploy for app deployments. There are many esoteric configurations out there in the field which don't use /deploy for deployments.

Steve
Sent from my BlackBerry® wireless device

-----Original Message-----
From: John Mazzitelli <mazz at redhat.com>
Sender: rhq-devel-bounces at lists.fedorahosted.org
Date: Tue, 22 Mar 2011 08:46:59 
To: <rhq-devel at lists.fedorahosted.org>
Reply-To: rhq-devel at lists.fedorahosted.org
Subject: Re: more specific bundle targets

On 03/22/2011 08:06 AM, Lukas Krejci wrote:
> On Tuesday, March 22, 2011 12:43:49 Charles Crouch wrote:
>> Right now the Bundle subsystem lets you deploy a bundle to a group of
>> platforms, if you also specify the absolute path to where you want the
>> bundle to go. What are the technical impediments from opening that up to
>> support deploying a bundle to a group of JBAS servers? e.g. the bundle
>> would by default go into the /deploy folder of each JBAS instance. Maybe
>> you could also provide an additional folder structure beneath /deploy into
>> which the bundle would go

We thought about this before, as a kind of "what if". Nothing formalized 
and no design docs, however, it follows the line of thinking that Lukas 
just posted along with some plugin descriptor special sauce.

First, the plugin descriptor must have a <bundle-destination> tag. This 
metadata tells us this resource can accept a bundle deployment inside 
it. It can optionally tell us where its bundle destination directory is, 
if it can be specified in the XML descriptor. For example, a plugin 
configuration setting might have the value of the destination directory, 
in which case, this is nice because a) no Java code needs to be added to 
the plugin and b) the user can customize the location (if the plugin 
config property is readOnly="false". For example:

<bundle-destination>
    <plugin-configuration-property name="deployDirectory"/>
</bundle-destination>

If there is no plugin config setting that can be used, we just mark this 
resource as bundle-ready via <bundle-destination /> - that just tells us 
the plugin can be a bundle destination, but we'd have to write some Java 
code next. We add a agent plugin facet class, BundleDestinationFacet, 
that tells us where its "bundle deployable" directory is. e.g. the 
JBossAS plugin returns the /deploy directory; the Tomcat plugin would 
return its /webapps directory. So when we go to deploy the bundle, we 
have to first ask the agent where is deploy directory is, and use that 
to create our BundleDestination during bundle deployment.

Everything else is the same - once we have the bundle destination 
directory, we create the BundleDestination entity (if it doesn't already 
exist), then we push out the Bundle normally.

Of course, this is just off the top of my head and I'm sure there are 
100 things that have to be refactored to get all of this to work :) 
Like, we now must accept compatible groups of non-platforms, we have to 
add code to call out to the agent to get the destination directory and 
what if the resource is down? How do we show this bundle relationship to 
the agent resources in the UI (we don't show anything today with 
relationship to plugins). And so on and so on.

>> Couple of issues spring to mind
>> 1) I recall seeing in a BZ that we can't deploy two bundles to one path
>> (which makes sense if the bundle is going to "own" that leaf folder) but
>> this makes deploying multiple apps (bundles) into /deploy problematic.

Not just problematic, it just won't work unless we refactor and enhance 
the deploy code so it can store .rhqdeployments metadata in separate 
directories or areas - one for each bundle. This would be a big change 
and would require some thinking to make it backward compatible with 
bundles that have already been deployed using the current way.

>> 2)
>> JBAS7 is going to support a much more centralized deployment model, e.g.
>> you talk to the domain controller not the individual nodes to do
>> deployment. I know that Bundles are not resource type specific, but is
>> there anyway we could make these two concepts play nicely?

Have a "JBossAS 7 Domain Controller" resource and tag it as bundle 
deployable with the <bundle-destination> metadata tag in the descriptor? 
This assumes we can just lay down files in some directory and have the 
DC push it out a-la the /farm directory stuff in JBossAS 4.
_______________________________________________
rhq-devel mailing list
rhq-devel at lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list