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
