> General requirements: > - The REST API of the AMS must be secured.
I fundamentally disagree. Security in a modular architecture should be an optional component that you either deploy, or not. > - Identification of the AMA and communication with the AMA must secure. Same here, security is optional. > - On premise installation behind a firewall must be possible. Can you please elaborate this requirement? In general, all communication is HTTP(S) based and goes in the direction of the server (AMS). So as long as the server is accessible to all targets (AMAs), it will work. Is that what you mean? > General remarks and questions: > - A "rolling update" for multiple servers should be possible, but > is covered by the cases above. Amdatu has no notion or support for clustering, yet. > - Is there a description of the use of configuration template > based on properties of a target? Not at this moment. I’ve created ACE-251 to provide that documentation. In short, they are Velocity templates, and they take their parameters from all properties and tags of entities that are (in)directly associated with the target the template is associated with. A popular way to use it is to add specific tags to a target and use parameters in the template for those. - Is it possible to restart a target from the AMS? No. There is only unidirectional communication from target to AMS. Therefore, the target is responsible for managing its own life cycle. The cloud support in ACE (through jclouds, currently only implemented for Amazon EC-2 instances) does allow you to manage the lifecycle of an entire node (which can contain one or more targets) but we decided not to focus on that yet for Amdatu Platform 1.0 (but what was already implemented is still available). > - Is it possible/desirable to maintain some of the configuration files on the > target (by a local System Administrator)? >From an Amdatu perspective that is neither supported nor desirable. However, >applications building on Amdatu can of course implement their own support for >this. I would advise you to keep using ConfigurationAdmin as the abstraction >for that, and I would not provide a specific configuration both via the AMS >and via a local mechanism (to prevent any conflicts). However, I would instead >try to design a mechanism where a local system administrator can provide >configurations that will subsequently be provisioned by the AMS. That way you >always have a copy of this configuration in case a target loses all data, or >you want to locally reproduce the exact configuration that a customer has. _______________________________________________ Amdatu-users mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-users
