[
https://issues.apache.org/jira/browse/ACE-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13821292#comment-13821292
]
Marcel Offermans commented on ACE-169:
--------------------------------------
With the complete rewrite of the management agent, this issue needs some new
thought.
The original description already highlights the dangers of taking the route of
using multiple, isolated deployment packages. This has not changed. However,
our new agent is much more "configurable" and even though we don't directly
support instantiating it more than once, such a feature can quite easily added
by using for example multi-tenancy (multiple, isolated deployment packages
coming from different sources sounds like a typical use case for a multi-tenant
setup of an agent). Whilst ACE itself provides no way to run a multi-tenant
agent, the Amdatu project does. A description for that module can be found
here: http://amdatu.org/components/multitenancy.html
I therefore propose to resolve this issue, and its related sub-issues in a way
that enables others to run the agent in a multi-tenant way, but not
implementing this in the ACE codebase itself.
> Refactor the management agent so support running multiple instances
> -------------------------------------------------------------------
>
> Key: ACE-169
> URL: https://issues.apache.org/jira/browse/ACE-169
> Project: ACE
> Issue Type: Task
> Components: Management Agent
> Reporter: Marcel Offermans
> Assignee: Marcel Offermans
>
> Currently, there can be only one instance of a management agent in an OSGi
> framework. For a couple of use cases it makes sense to support multiple
> instances, each with their own identity, talking to their own discovered
> server(s). One use case is to have multiple management agents each deploy
> subsets of software that are completely isolated from each other (respecting
> the constraints that having multiple deployment packages impose). Of course
> there are downsides to this use case, as conflicts can arise that can never
> be detected beforehand on the server, so using multiple instances in this use
> case is strongly discouraged unless you can be sure you won't run into these
> issues. Another use case is when a management agent is being used to "import"
> software from one provisioning server to another, and you want to get
> software from multiple sources. This can be used in scenarios where you want
> to have a controlled merge between software from multiple sources, giving you
> control over how they are merged and allowing validation before sending the
> result to a target.
> In short, changes that need to be made are converting everything that is
> currently implemented as a "singleton" service into a managed service
> factory, adding a property to each service that can be used to identify the
> management agent it belongs to, and filtering the audit logs in such a way
> that each log sees the difference between "their" deployment package and
> "other" deployment packages.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
