Hi Marcel, I left out the items that were clear and added my feedback below:
> > 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 OK, I'll look into that. > > 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. OK, we will have to this for BlueConic. > > - 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. Is the "audit log" an actual logfile containing lines of logmessages or is it accessible through an API? > > 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 * :) :) Greetings, Dion _______________________________________________ Amdatu-users mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-users
