Sure, I can have a go at it. Time wise it will most likely be something I'll do on Monday as well, so perhaps I can send you something towards the end of the day so we can briefly sync this before we meet on Tuesday?
Greetings, Marcel On 6 Jul 2011, at 15:51 , Bram de Kruijff wrote: > Hi Marcel, > > thanks for the response and feedback. Would be great if you could work > this into an estimate for next week ;) Right now I am in holiday only > to return next monday. > > grz from Budapest > Bram > > On Fri, Jul 1, 2011 at 9:58 AM, Marcel Offermans > <[email protected]> wrote: >> Hello Bram, >> >> On 29 Jun 2011, at 14:01 , Bram de Kruijff wrote: >> >>> Hi list, >>> >>> to explore the Amdatu Platform M1 scope and wrote down an analysis of >>> what we have to do based on my expectations. It extends on the wiki >>> description [1] and once I get an initial round of feedback I'll copy >>> it back. Please give it a thorough review as we are expected to come >>> up with a highlevel workbreakdown and planning at the next f2f. >>> >>> Milestone 1 - Amdatu Platform Provisioning >>> >>> Milestone 1 will add provisioning support to the Amdatu Platform based >>> on an integration with Apache ACE. This will provide a working >>> mechanism for managing multiple Amdatu nodes from a centralized >>> provisioning server based on the current Apache ACE feature set and >>> WebUI. The result will be a initial provisioning mechanism against >>> which Amdatu subprojects and others can start building. >> >>> From this description I don't read anything about the REST API. Is that in >>> our out for M1? >> >>> demo scenario: >>> >>> First, John starts an Amdatu cluster running 3 instances of Amdatu >>> OpenSocial. >> >> I would leave out the word "cluster" here and stick to just 3 instances for >> now. >> >>> Second, John develops a custom gadget and deployes it onto the 3 instances >>> >>> 1) John dowloads and launches an Amdatu AMS distribution >>> alt1: John downloads and start an AMA launcher that gets auto >>> provisioned with AMS components from repository.amdatu.org >> >> When we currently run ACE in the cloud, it already contains a launcher in >> its OBR that you can also manually download and launch. Where this launcher >> gets its software from can be configured using a command line parameter. The >> launcher is always just an OSGi framework plus management agent and I think >> that's also how we should bootstrap our Amdatu AMS distribution. >> >>> 2) John configures the AMS by adding Amdatu Opensocial bundles, >>> groups, licenses through a command line REST client >>> alt1: John configures the AMS by adding bundles, groups, licenses >>> through the ACE webui >> >> I would go with alt1 as the default step for now. >> >>> alt2: John provisions the bundle, group, license configuration of >>> Amdatu OpenSocial from an upstream repository (eg >>> repository.amdatu.org) >>> alt3: An AMS auto provisions the bundle, group, license >>> configuration of official Amdatu artifacts automatically from an >>> upstream repository (eg repository.amdatu.org) >>> 3) John launches 3 AMA nodes that report in with the AMS >>> 4) John links licenses to the new AMA targets through a command line REST >>> client >>> alt1: John links licenses to the new AMA targets through teh ACE webui >> >> Again, I'd prefer alt1 to be the default for M1. >> >> Btw, licenses have been renamed in ACE and are now called "distributions". >> Does it make sense to stick with that terminology here as well? >> >>> alt2: The AMAs get launched with a profile ID that the AMS can >>> match to licenses and thus auto provision >> >> This can easily be done by pre-registering the IDs in the web UI. >> >>> 5) John fires up Eclipse and develops an Amdatu OpenSocial gadget >>> alt1: John uses an archetype to get a flying start >>> 6) John configures the AMS by adding his gadget bundle, group, >>> licenses, target through a command line REST client >>> alt1: John configures the AMS by adding his gadget bundle, group, >>> licenses, target through the ACE webui >>> alt2: AMS autobinds (new) bundles to a development license reducing >>> manual labor >>> 7) John (re)deployes the gadget bundle from Maven or Eclipse (via AMS >>> REST interface) >>> 8) Jonh refreshed het browser windows and sees his (lastest) gadget running >>> 9) John is happy >> >> If John is happy, I am happy. :) >> >>> use-cases: >>> 1) Ability to launch an AMS with ACE server capabilities >>> 2) Ability to launch multiple AMAs that connects to an AMS >>> 3) Ability to manage artifacts to AMS via REST >>> 4) Ability to manage groups in AMS via REST >> >> Called "features" now. >> >>> 5) Ability to manage licenses in AMS via REST >> >> Called "distributions" now. >> >>> 6) Ability to manage targets in AMS via REST >>> 7) Ability to trigger AMA update via REST >>> 7) Ability to deploy bundle from maven/eclipse >>> >>> Workbreakdown: >>> >>> 1) Add REST interface to manage ACE server domain (AMDATU-390) >>> 2) Add REST interface to wakepup ACE client (AMDATU-xxx) >>> 3) Allow Amdatu Web to consume 3rd party servlets (AMDATU-xxx) >> >> Can you explain this task? >> >>> 4) Create initial Amdatu AMS with ACE server (AMDATU-xxx) >>> 5) Create initial Amdatu launcher based on ACE (AMDATU-xxx) >> >> We already have a single, startable JAR that can be launched from the >> command line with a few parameters. I don't think we need more, unless we >> also want to start offering WAR files that can be deployed inside legacy >> application servers. >> >>> 6) Convert Amdatu platform config to metatype (AMDATU-xxx) >>> 7) Make Amdatu OpenSocial provisionable (AMDATU-xxx) >> >> We're deliberately not yet making the rest of Amdatu provisionable here yet, >> right? That would be next on the roadmaps of the individual subprojects as >> soon as we have this working. >> >>> 8) Integrate Eclipse/Maven/ACE REST interface (AMDATU-xxx) >> >> I would split those up, because they are different integrations: >> >> Create a command line client that talks to the REST API. >> Create Eclipse IDE plugin that integrates with any type of project that can >> produce bundles. >> Create a Maven extension that talks to the REST API. >> >> And we would still need to figure out exactly what these should all do in >> terms of features (unless that is only defined by the use cases we describe >> here). >> >>> x) Allow initial AMS provisioning form upstream server? >> >> See 5, I think that's enough. Unless you mean something else. >> >>> x) Allow AMS Amdatu releases provisioning from upstream server? >> >> Greetings, Marcel >> >> >> _______________________________________________ >> Amdatu-developers mailing list >> [email protected] >> http://lists.amdatu.org/mailman/listinfo/amdatu-developers >> > > _______________________________________________ > Amdatu-developers mailing list > [email protected] > http://lists.amdatu.org/mailman/listinfo/amdatu-developers > _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
