more specific bundle targets

John Mazzitelli mazz at redhat.com
Tue Mar 22 20:56:02 UTC 2011


Good point, which lends credence to my suggestion that we make this 
configurable via plugin configuration properties. Out of box, the bundle 
deployment location could be /deploy, but have it a plugin config 
setting that a user can change to /customdeploy if that is where they 
want to deploy bundles.

On 03/22/2011 04:35 PM, smillidge at c2b2.co.uk wrote:
> 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
> _______________________________________________
> 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