more specific bundle targets

John Mazzitelli mazz at redhat.com
Tue Mar 22 13:49:02 UTC 2011


you would be assuming there is a property on the destination group type 
that corresponds to the destination directory, which you can't assume.

Even the JBossAS type doesn't have a property that points to the /deploy 
directory - so there has to be something specific on the type that 
declares a "deployment directory".


On 03/22/2011 09:19 AM, Jay Shaughnessy wrote:
>
> 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
>>
> _______________________________________________
> 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