Hi all, I read the provided documentation in order to check if this implementation covers the BlueConic case, this is my feedback:
Amdatu Provisioning Requirements [2] The requirements are on a very high level. With some assumptions they seem to cover the use cases we have in mind for BlueConic. I have included these use cases so we can verify this. Amdatu Provisioning Use Cases [3]: - It isn't clear for all Use cases what is in scope for 1.0. If there is agreement in the discussion, please remove the discussion and update the description and indication of the scope. Amdatu Provisioning Design [4]: Amdatu Management Server (AMS) - Components * Is the OBR/software repository an internal storage engine or is it accessed directly? - Security and trust Is there documentation and some out of the box support for securing communication based on public/private certificates? Is the identity of the AMA in this solution based on a client certicate? If so, how is the mapping between this client certificate and the target implemented? If not, how can we prevent the AMA's from different customers from being able to download eachother's distributions? - REST interfaces Ace Client REST API ( https://cwiki.apache.org/confluence/display/ACE/Client+REST+API): * The objectification of associations between entities ("Artifact2Feature", "Distribution2Target") seem strange to me, maybe because I'm not familiar with Ace. The way I understand it, the properties of "artifact2feature" objects could also be moved to "feature" objects. * "Artifact" has properties " artifactName" and " artifactDescription", for " Feature" and "Distribution" the properties "name" and "description" are used. * In general it's easier to read documentation on http response codes if the response message is also included (e.g. 409 Conflict or 400 Bad request). * Is the content of all responses in Json format? * Checkout and commit: - 404 Not Found responses should be added in case the working copy doesn't exist (anymore). - 401 Unauthorized / 403 Forbidden responses should be added to all methods. - DELETE /work/ID The response code for a successful delete is missing. - POST /work/ID I'm not sure, but perhaps a PUT method should be used instead. POST suggests that a working copy can be create here with an arbitrary id. * Repositories and objects - In general: 401 Unauthorized / 403 Forbidden responses should be added to all methods. - GET /work/ID: Maybe the response should include links the the subresources instead of only the id's, this would require less knowledge about the application from the client (HATEOAS). - GET /work/ID/feature: Is there a paging/filtering/sorting mechanism to cope with large datasets? Even more relevant for artifacts. Are links to the individual features included in the response? At GX we use a guideline to use the plural form for the resource base for collections, since a GET request to /work/ID/feature returns multiple features. - POST /work/ID/feature Can there be multiple versions of features or artifacts or do these have a different featureID? - Documentation for the other entities is missing. Amdatu Management Agent - REST interfaces: Is communication between the AMA and AMS RESTful? Amdatu Provisioning Scenarios[5] - TODO BlueConic provisioning Use Cases: Actors & roles ============ Actor Description System Administrator Responsible for managing low level infrastructure, which includes adding and removing of compute resources. Software manager Responsible for releasing new versions of software components. Application manager Responsible for managing the application on a higher level. This includes deployment of new software, assigning tenants and composites to (multiple) compute resources. Use cases ======== The UI in these use cases is not part of the scope of Amdatu Core, but is should be possible to implement this using the REST API's. 1. Release new version of software: - [Software manager] creates new artifacts by uploading jar and configuration templates in a UI, based on the AMS REST API. These artifacts are grouped into a feature, e.g. "BlueConic 2.0.0". - [Application manager] can select the features for assignment to distributions and deployment to targets. 2. Initial installation: - [System Administrator] installs an AMA on a new compute node (including some verifiable identity token?). - The new target becomes visible in a UI, bases on the AMS REST API. - In the same UI, a distribution consisting the following features is configured and is assigned to the target by [Application manager]: o BlueConic release o Target specific configuration - The AMA downloads and installs the distribution - [Application manager] can monitor the deployment status in the UI, bases on the AMS REST API. 3. Installation of distribution with automatical deployment - [Application manager] assigns features to a distribution which is assigned to a target in a UI, bases on the AMS REST API. - The AMA downloads the the distribution and automatically deploys it. - [Application manager] can monitor the deployment status in the UI. 4. Installation of distribution with manual deployment - [Application manager] assigns features to a distribution which is assigned to a target in a UI, bases on the AMS REST API. - BlueConic can query the availability of a new distribution through a Java API of the AMA. - BlueConic requests download and installation of the new distribution through a Java API of the AMA. - The AMA downloads the the distribution and automatically deploys it. - [Application manager] can monitor the deployment status in the UI. 5. Update configuration - [Application manager] uploads a new version of configuring artifacts to the AMS, assigns it to a feature, distribution and target. - The AMA downloads the distribution and deploys it (In case of automatical deployment). - Other targets don't receive the new version of the configuration artifacts. 6. Monitor status of targets - [System Administrator] can monitor the status of all targets in a UI, based on the AMS REST API. For each target, this includes: o Details of current deployment, including versions o Pending deployment updates o Log messages o Basic metrics - BlueConic can add application specific logging through a Java API of the AMA. The custom logging can be retrieved through the REST API of the AMS. 7. Removing a target - [System Administrator] removes a compute resource. System no longer receives status updates from the target. - [Application manager] can monitor the target status in the UI and can remove the target from the AMS. 8. Local development - A (BlueConic) developer should be able to build (snapshots of) bundles and configuration files and deploy them to a local AMA using Maven. - It should be possible to clean up the local repository. General requirements: - The REST API of the AMS must be secured. - Identification of the AMA and communication with the AMA must secure. - On premise installation behind a firewall must be possible. General remarks and questions: - A "rolling update" for multiple servers should be possible, but is covered by the cases above. - Is there a description of the use of configuration template based on properties of a target? - Is it possible to restart a target from the AMS? - Is it possible/desirable to maintain some of the configuration files on the target (by a local System Administrator)? Regards, Dion -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bram de Kruijff Sent: vrijdag 16 maart 2012 10:54 To: [email protected]; [email protected] Subject: [Amdatu-users] Amdatu Platform Provisioning model feedback/reviews wanted Hi list, over the last weeks we have been working on a revised Provisioning model for Amdatu Platform 1.0. This included (partially offline) discussions on what we will and wont cover as well as how we will implement it. In a nutshell, we will cover software/configuration provisioning and use Apache ACE as our software provisioning engine with an off the shell UI and fully manageable trough REST interfaces. The results are covered in the pages listed below providing an architectural overview [0][1], requirements [2], use-cases [3] and a more detailed design[4]. Note that there is also a still rather empty scenarios page [5] that is intended to describe some possible high level use cases and map them to the solution. This is work inn progress and feel free to add a scenario that you would like to see so we can discuss it. This is not the end and it is not a done deal as over the next couple of weeks we will spend some more iterations to refine, implement and proof the model. Therefore at this point we would very much appreciate feedback from the community and specifically anyone interested in Provisioning. Do you feel requirements and use cases cover your needs? Do the design and proposed implementation make sense? Any feedback will be most valuable to our end goal, which is to come up with a stable future proof model for 1.0! Thanks and greetz, Bram [0] http://www.amdatu.org/confluence/display/Amdatu/Provisioning [1] http://www.amdatu.org/confluence/display/Amdatu/Amdatu+Provisioning [2] http://www.amdatu.org/confluence/display/Amdatu/Amdatu+Provisioning+Requirements [3] http://www.amdatu.org/confluence/display/Amdatu/Amdatu+Provisioning+Use+Cases [4] http://www.amdatu.org/confluence/display/Amdatu/Amdatu+Provisioning+Design [5] http://www.amdatu.org/confluence/display/Amdatu/Amdatu+Provisioning+Scenarios _______________________________________________ Amdatu-users mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-users _______________________________________________ Amdatu-users mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-users
