Hi Marcel, I left out the items that were clear and added my feedback below:
> > 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. I meant this from the BlueConic point of view. It should be possible to configure the AMS in a way that access to the REST API is restricted to authorized users. > > - 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? Yes, but maybe it should also be possible install a local AMS behind the firewall and deploy BlueConic releases from there. I'll check with Martijn. > > 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. OK, I think this is covered. > > - 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. OK > - 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). OK > > - 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. OK Greetings, Dion _______________________________________________ Amdatu-users mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-users
