ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bram de Kruijff (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACE-347) Redesign Management Agent
Date Fri, 17 May 2013 19:39:16 GMT

    [ https://issues.apache.org/jira/browse/ACE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13660985#comment-13660985
] 

Bram de Kruijff commented on ACE-347:
-------------------------------------

Thanks for the feedback  guys!

[~wilsib] I can see the value of totally separating the MA from the deployment and, as you
say, being able to update the container as well or even running different containers. Another
approach we discussed before is to let the MA fork an entirely separate process so that, even
when the deployment crashes or exits, the MA lives on and could restart. It would potentially
also allow updating the MA itself without affecting the deployment...

However, there are some cases where we want to punch holes in the isolation. First, the DeploymentAdmin
spec itself requires us to deploy Resource Processors in the deployment and these at least
require deployment admin packages. Second, strictly speaking we should raise appropriate events
during deployment through eventadmin (there are some spec issues here and therefore I do not
really care too much for this one). Finally, I would like it to be possible for the deployment
to talk to MA services (eg. write something in a logstore or trigger/authorize an update)
and I would like the MA to be extensible/customizable (preferably through services)..

The again, as Marcel states, the MA should also be able to deploy as a bundle in a standard
container.. are we talking about one MA that can do it all or different forms of the smae
core logic? I'm not sure yet :)

[~marrs] Agreed.. I can start stripping/simplifying more pending final deliberations on the
discussion above. But getting down to 100k will require some drastic measures :) Wrt eliminating
CM/EA note that only the interface packages are in there. Do you mean even decoupling from
these interfaces?
  

 
                
> Redesign Management Agent
> -------------------------
>
>                 Key: ACE-347
>                 URL: https://issues.apache.org/jira/browse/ACE-347
>             Project: ACE
>          Issue Type: Improvement
>            Reporter: Bram de Kruijff
>            Assignee: Bram de Kruijff
>
> The Managent Agent was made "self-contained" in ACE-232 but there are still some concerns
with regard to complexity and functionality. This issue deals with restructuring the Managent
Agent code to make it easier to maintain, configure and extend. Also see ACE-324 / ACE-324.
> Management Agent code:   
> The MA implementation is setup very modular and it assembled mainly based on CM factories.
Maybe a little too much. The code is scattered over projects making it hard to maintain and
it is violating visibility rules to implementation classes which is nasty in bndtools.
> -> We should centralize the 'dedicated' MA code in the MA project allowing us to clean
up a lot of projects.
> Management Agent config:   
> The fact that we can theoretically reconfigure these services at runtime through CM does
not add much more then a runtime dependency on a CM impl. There is an obvisou catch-22 in
boostrapping and no mechanism to provision these configurations to a private CM and in fact
all configuration is done in code and it is very complex. 
> -> we should centralize configuration in a well documented format with a simple default
case and possible extension.
> Management Agent extension:   
> Bringing in extensions or customization on the bundle classpath is very hard on only
partially possible. There is a mechanism to disabled activators and one to add custom ones.
Theoretically one could also provide services from "user space", but there is no way do do
so in a simple way as there are no visible APIs and the CM catch-22.
> -> We should simplify extension on bundle classpath through a simple factory SPI.
Bringing these on the classpath can be done through wrapping (as launcher does) or maybe also
fragment bundles.
> -> User space extensions could have a real use case in management/monitoring. However,
this means we need to expose some API. Question is whether we want to expose prg.apache.ace.*
(or some subset) so that consumers can talk to for exmaple Log directly or that we should
facade this behind a single ManagementAgent API to keep it more contained.
> Multiple agents:   
> There is code to configure and handle multiple agents. Not sure if it really works as
it is a very exotic and possibly undesirable use-case. There are many conditionals for this
through the CM code.
> -> At least make it simpler and discuss wither we actually want/need this at all.
> Resource Processors:
> RPs need to resolve, typically requiring framework, deploymentadmin (spi) and eventadmin,
but maybe more. In the current situation the MA exports these package with an additional required
attribute (managementagent=true). As a result standard 3rd party RPs will not resolve. Therefore
the MA should be as self-contained as possible but still export these packages without the
attribute and (re)import them with the appropriate range.
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message