Bug 1050014 - Cannot deploy bundle to EAP domain mode

Thomas Segismont tsegismo at redhat.com
Tue Jun 10 13:42:47 UTC 2014


Le 10/06/2014 15:37, Lukas Krejci a écrit :
> Well, with different bundle type, you can try to reuse the work done in PR#39
> to pass over the plugin config but I'm not sure you could easily get all the
> bells and whistles from the ant bundle handler? Or would that be possible,
> too?
>
> If you can spin up an augmented ant bundle handler then I think that could be
> the easiest option.
>
> Otherwise I really do like the generality of the "handover" approach. At the
> same time the work on ant bundle handler side would be minimal, there would
> have to be some small new plumbing inside plugin container for this and then
> we have a lot of code to reuse in AS7 plugin where we already do deployments.

... and CLI script execution

> So in the end I hope it would not have to be that difficult to do either.
>
>
> On Tuesday, June 10, 2014 09:16:02 John Mazzitelli wrote:
>> I would say the second option - another bundle type. I mean, that IS why we
>> designed it with multiple bundle types - to support different ways to
>> deploy things. So that would probably be my first attempt at this. It
>> probably would be easier to implement too.
>>
>> ----- Original Message -----
>>
>>> 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
>>
>> _______________________________________________
>> 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