ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Offermans (JIRA)" <>
Subject [jira] [Updated] (ACE-169) Refactor the management agent so support running multiple instances
Date Wed, 23 Jan 2013 15:50:14 GMT


Marcel Offermans updated ACE-169:

    Component/s: Management Agent
> Refactor the management agent so support running multiple instances
> -------------------------------------------------------------------
>                 Key: ACE-169
>                 URL:
>             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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message