more specific bundle targets

Jay Shaughnessy jshaughn at redhat.com
Tue Mar 22 13:19:06 UTC 2011


Does it really require plugin meta-data declaration and a fixed 
directory for the type?  Or could we beef up bundle destinations and 
make the deploy directory relative to a property on the destination's 
group type?

On 3/22/2011 8:46 AM, John Mazzitelli wrote:
> 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