more specific bundle targets

Jay Shaughnessy jshaughn at redhat.com
Tue Mar 22 15:01:09 UTC 2011



On 3/22/2011 9:49 AM, John Mazzitelli wrote:
> 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".
I thought it had an install directory or something like that that it 
could use to drive off of.  I'm just thinking that a type-specific 
deployment dir could somehow be too restrictive.  What if you wanted to 
provision webapps in one case and start scripts in another.
>
> 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
> _______________________________________________
> 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