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
