Bug 1050014 - Cannot deploy bundle to EAP domain mode

Thomas Segismont tsegismo at redhat.com
Tue Jun 10 13:06:45 UTC 2014


With the two solutions *below* ...

Le 10/06/2014 15:04, Thomas Segismont a écrit :
> We thought about that one but did not keep it: it is possible to write
> some specific ANT tasks, but you'll need to give the credentials and
> server url somehow (hardcoded or with bundle input properties). With the
> two solutions above, we benefit from the plugin component being aware of
> how to connect to the management interface. Is SSL active? Is it
> password protected? Or is it client certificate protected? Which port is
> it running on? ... you get the idea ;)
>
>
> Le 10/06/2014 14:57, John Mazzitelli a écrit :
>> What about a third option :)
>>
>> Could we add new ANT tasks the bundle writer can use? We'd write ANT
>> tasks that can talk to EAP over the CLI (using http perhaps, or
>> ModelController) so the recipe can have ANT tasks in the post-deploy
>> target? So they could write in the recipe something like <eap-deploy
>> ....>
>>
>> Just a thought. This would be limited to an EAP only solution, which
>> is a con.
>>
>> ----- Original Message -----
>>> Hi everyone,
>>>
>>> I'm writing to talk about a feature request: Bug 1050014 - Cannot deploy
>>> bundle to EAP domain mode [1]
>>>
>>> The problem is that the ANT and FileTemplate bundle types are file
>>> based, and domain deployments are only possible through the management
>>> API or the EAP CLI.
>>>
>>> The requirements of this RFE are as follows:
>>> * being able to deploy an application archive to a domain controller
>>> * being able to execute EAP CLI scripts
>>> * the implementation should work with standalone servers
>>>
>>> The solution should take into account that we are also trying to solve
>>> the EAP patching problem (see Bug 1069547 - Support EAP 6.2/6.3 style
>>> patching [2] and PR39 on GitHub [3]).
>>>
>>> We discussed the RFE with Lukas and Jay some time ago but I wasn't able
>>> to write up the conclusions until now. So here it goes.
>>>
>>>
>>>
>>>
>>>
>>>
>>> 1. Extend ANT bundle type to communicate with resource components
>>>
>>> Resource component would implement a new facet (name to be defined), and
>>> the methods of this facet would let the user pass some content. The
>>> resource component would do whatever it needs to and the bundle agent
>>> plugin wouldn't try to lay down this content on the system.
>>>
>>> Here's how an ANT bundle would look like:
>>>
>>> <rhq:deployment-unit name="xxxxxx">
>>>    <rhq:file name="myapp.war" handover="deploy"/>
>>>    <rhq:file name="myscript.cli" handover="executeCLI"/>
>>> </rhq:deployment-unit>
>>>
>>> or
>>>
>>> <rhq:deployment-unit name="xxxxxx">
>>>    <rhq:file name="patch-eap-6.xxx" handover="patch"/>
>>> </rhq:deployment-unit>
>>>
>>>
>>> See? The key here is the new "handover" attribute that users could add
>>> to rhq:file, rhq:url-file, rhq:archive and rhq:url-archive.
>>>
>>> Pros:
>>> * General purpose solution, could be applied to EAP patching as well
>>>
>>> Cons:
>>> * For patching, a recipe and bundle file would have to be created
>>> instead of just the patch zip file
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2. Create a new bundle type
>>>
>>> This is what Lukas started when he wrote his pull request for EAP
>>> patching  support
>>>
>>> Pros:
>>> * The concept is already proven by PR39
>>>
>>> Cons:
>>> * Yet another bundle type, and only applicable to a specific resource
>>> type
>>> * Less powerful than an ANT bundle: users will be able to deploy apps
>>> and execute CLI scripts but nothing else
>>>
>>>
>>>
>>>
>>>
>>>
>>> We'd be very happy to hear from you on this topic. Which solution do you
>>> prefer? Hopefully you don't find both solutions ugly...
>>>
>>> Regards,
>>> Thomas
>>>
>>>
>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1050014
>>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1069547
>>> [3] https://github.com/rhq-project/rhq/pull/39
>>> _______________________________________________
>>> rhq-devel mailing list
>>> rhq-devel at lists.fedorahosted.org
>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list