> Amdatu Provisioning Scenarios[5] > - TODO Ok.
> BlueConic provisioning Use Cases: > > Actors & roles > ============ > 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. The AMS will feature fine grained permissions. You can define your own roles and map them to these permissions yourself. In general these seem to map reasonably well to the roles that ACE defines [1]. [1] http://ace.apache.org/dev-doc/requirements/roles.html > 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". Definitely possible, both with the REST API and the ACE UI. > - [Application manager] can select the features for > assignment to distributions and deployment to targets. Yup. > 2. Initial installation: > - [System Administrator] installs an AMA on a new compute > node (including some verifiable identity token?). You can either use the ACE UI for that, and automatically create and launch a target on a new compute node, or do it by hand. A single executable JAR file is enough for bootstrapping. The identity can be provided as a parameter. Identity is pluggable though, if you want to create an AMA that does this differently, you can implement an Identification interface yourself. > - The new target becomes visible in a UI, bases on the AMS REST API. Yup. > - 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 If the configuration is target specific (and not a template that is the same for all targets) you need a distribution that is specific for each target as well. > - The AMA downloads and installs the distribution It downloads and installs a deployment package, which is the union of all artifacts that are contained in all distributions that are associated with it. In other words, a target can have multiple distributions. > - [Application manager] can monitor the deployment status in > the UI, bases on the AMS REST API. All life cycle changes to a target are captured in its “audit log”. This log is available on the AMS and exposed via all client APIs. > 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. Anything you assign to a target, gets deployed as soon as the change is approved (or automatic approval for that target is turned on). > - [Application manager] can monitor the deployment status in the UI. Yes, as noted earlier. > 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. Yes, one of the REST calls an AMA can do is obtain a list of available versions. A new version of the software is created whenever something in the union of artifacts changes (which can be triggered by adding a new distribution). We are currently designing a Java API (OSGi service) to do this. > - BlueConic requests download > and installation of the new distribution through a Java API of the AMA. Yes, this is another call you can do to the AMA. > - The AMA downloads the the distribution and automatically deploys it. Yup. > - [Application manager] can monitor the deployment status in the UI. Yup. > 5. Update configuration > - [Application manager] uploads a new version of > configuring artifacts to the AMS, assigns it to a feature, distribution and > target. As long as “something changes” to the overall union of artifacts, this will trigger the creation of a new version of the software for the relevant targets. > - The AMA downloads the distribution and deploys it (In case of > automatical deployment). Yup. > - Other targets don't receive the new version of > the configuration artifacts. Only if the artifacts are assigned to a target and the update is approved, will it go there. >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 All possible, as long as you build that UI yourself. Incidentally, all of this is already visible in the current web UI. > - 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. Yes, the mechanisms behind the “audit log” allow for both extending that log and adding new logs. > 7. Removing a target > - [System Administrator] removes a > compute resource. System no longer receives status updates from the target. You can remove a registered target. As long as it does not “poll” the server anymore, you won’t see new updates from it. However, if it does, you will see it again as an unregistered target. Note that currently, all targets that have ever sent audit log data to the server will show up as unregistered targets, no matter if they were “removed” (or rather unregistered). For now, just filter them from your view if you don’t want to see them. As explained above, we can currently start/stop Amazon EC-2 compute nodes automatically. > - [Application manager] can monitor the target status in the UI and can > remove the target from the AMS. Yup. > 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. This is possible. Note the mismatch between OSGi and Maven versioning though. OSGi, and therefore ACE, *needs* a new version for every new snapshot you build, so make sure your bundle versions end up with some “timestamp based qualifier” instead of the word “SNAPSHOT”. > - It should be possible > to clean up the local repository. rm -rf * :) _______________________________________________ Amdatu-users mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-users
