Hi Martijn, > Feedback etc is welcome ofcourse.
Great! My first impressions, ideas and questions: > Persona in the Use Case: > Leon is System Administrator > Dion is developer of Educa I think we will soon have to add a 'deployment role'. A developer should not be concerned with any particular install and a system administrator should not be concerned with application specific packing and deployment. I'm actually curious how ACE defines roles. > Dion has uploaded a set of OSGi bundles and other resources > Dion has finished Educa 1.1 and uploads a new distribution to the > provisioning server To elaborate on the previsou point. I think the developer 'deploys' a set of artifacts (bundles and other recources) to the maven repository / OBR. After that it is up to de packaging / deployment roles in Amdatu/ACE to define deployment packages and deploye them to any target. > Leon presses update on the first server Again, I think the sysop should be concerned with updates of the Amdatu platform itself, but the applications are the concern of the deployment role (and there could possibly be multiple persons having that role eg. per tenant)??) > Leon chooses a node, and selects the distribution 'Educa 1.0' to install on > that node. > Next to the already created Educa instance, a '+' button is shown, Leon > presses the button > Leon goes back to the gadget and web based provisioning server and presses > the '-' button All these actions asume that an application is one composite which could be perfectly vaild for Educa. However I think we should consider the possibility where a complex/large application is constructed from multiple composites and one wants to partition the software topology (and thus the service topology) allowing dynamic horizontal and/or vertical scaling. > Leon presses update on the first server > Leon presses update on the second server, Hmmm diffent software versions running together.. that is always a very tricky one :) In general it may work in some cases where versions only differ on 'implementation details' but will fail in many other cases where (REST) apis change, datamodel changes or persistence model changes. We can think about schemes that may work (and maybe very labor intensive for developers), but in general I think the developer should declare how upgradeable an update is and the deployer must decide based on the information and the specific deployment topology what upgrade strategy to folow. 2 cents! Regards, Bram ________________________________________ From: amdatu-developers-bounces at amdatu.org [amdatu-developers-bounces at amdatu.org] On Behalf Of Martijn van Berkum [[email protected]] Sent: Monday, October 11, 2010 6:27 PM To: amdatu-developers at amdatu.org Subject: [Amdatu-developers] Use Cases Hi all, I rewrote parts of the Cloud Deployment Use Cases, see them here: http://www.amdatu.org/confluence/display/Amdatu/Amdatu+-+Cloud+Deployment+Use+Case Highlights of the changes: ? Simplifying clustering (just press ?+? or ?-? to manage your cluster) ? In bold the actions, the rest is context (which should clarify the ?real? steps) ? Added remark sections with thoughts about architectural requirements Feedback etc is welcome ofcourse. Martijn GX | Martijn van Berkum | Directeur | Wijchenseweg 111 | 6538 SW Nijmegen | The Netherlands | T +31(0)24 - 388 82 61 | F +31(0)24 - 388 86 21 | M +31(0)6 - 15 05 08 53 | martijn.vanberkum at gxsoftware.com<mailto:martijn.vanberkum at gxsoftware.com> | www.gxsoftware.com<http://www.gxsoftware.com/> | twitter.com/GXSoftware<http://twitter.com/GXSoftware/> | twitter.com/njitram<http://twitter.com/njitram>
