Bug 1050014 - Cannot deploy bundle to EAP domain mode

Lukas Krejci lkrejci at redhat.com
Tue Jun 10 13:37:07 UTC 2014


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. 
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



More information about the rhq-devel mailing list