Return-Path: X-Original-To: apmail-airavata-dev-archive@www.apache.org Delivered-To: apmail-airavata-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8AF7611441 for ; Sat, 24 May 2014 08:40:26 +0000 (UTC) Received: (qmail 87704 invoked by uid 500); 24 May 2014 08:40:25 -0000 Delivered-To: apmail-airavata-dev-archive@airavata.apache.org Received: (qmail 87650 invoked by uid 500); 24 May 2014 08:40:25 -0000 Mailing-List: contact dev-help@airavata.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@airavata.apache.org Delivered-To: mailing list dev@airavata.apache.org Received: (qmail 87643 invoked by uid 99); 24 May 2014 08:40:25 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 24 May 2014 08:40:25 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of samindaw@gmail.com designates 209.85.217.177 as permitted sender) Received: from [209.85.217.177] (HELO mail-lb0-f177.google.com) (209.85.217.177) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 24 May 2014 08:40:20 +0000 Received: by mail-lb0-f177.google.com with SMTP id s7so3212091lbd.22 for ; Sat, 24 May 2014 01:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=xhn8KgBVNv2cWcZxgGuE1UlZP7OqbBWkE8nAjsrMuF0=; b=DRCfX464EsYGotv4UPEkZSuBr/EsE9PbDAtcx8dcj6fwdkbYw0aCDNKKiE0o4yfstS 6s7gGyP+B/jcU3qRwRKcEL2vNHlfyY7C+MY9OSISVFDXTyH2Raqljl9Hqha+/AUObuxz sVRVT316VG7eDph7vENYI3wcfDr3u3Mg+/borN48cTRsmZ9c9MNz6dDBpIDHk5sgDJQu Kd6kItpcSTmBsKPab5W27+IkWjrW95uk6Jw3WELLQE5KRK4ZRcQ3FNey2LScQlQkwAoI MSkjbL9949sDV40zoIZK1h0c/OI212xmA4kAPVpCxT10Gs2cnk0oi5nl0gmoBGYTTF6/ LclQ== X-Received: by 10.112.85.167 with SMTP id i7mr7010840lbz.32.1400920798917; Sat, 24 May 2014 01:39:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.58.130 with HTTP; Sat, 24 May 2014 01:39:38 -0700 (PDT) In-Reply-To: References: From: Saminda Wijeratne Date: Sat, 24 May 2014 01:39:38 -0700 Message-ID: Subject: Re: Administrative API for Airavata To: dev Content-Type: multipart/alternative; boundary=001a11346dde93fa8804fa214a6f X-Virus-Checked: Checked by ClamAV on apache.org --001a11346dde93fa8804fa214a6f Content-Type: text/plain; charset=UTF-8 Thanks Nadeem for starting a discussion this. I see 2 perspectives for an Administrative API, (1) Administrative API for setting up/configuring gateways: for example, - adding/updating/removing/disabling a new gateway - setting up authentication for a gateway to use Airavata - setup gateway users for a gateway - enable/disable users/resources for a gateway - setup community credentials/certificates for gateway - etc. Some of these can be mitigated to the gateway itself. But I do not think we need to draw the line at this stage. (2) Administrative API for configuring Airavata: (we are probably not ready for this yet) I'd think this will include managing most of the settings we have in the airavata-server.properties and configurations supporting future implementations of load-balancing, scaling, fault tolerance, policy management etc. On Sat, May 24, 2014 at 1:09 AM, Nadeem Anjum wrote: > Hi All, > > We are planning to have an administrative API for airavata. Some features > could include authorizing users for gateways, loading the required data as > a service rather than having to do it manually. > > We need to compile a list of required features. Please post your > suggestions on this thread. > > Thanks, > Nadeem. > ----------------------------------- > Sent from my Nexus 4 > --001a11346dde93fa8804fa214a6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Nadeem for starting a discussion this.
I see 2 perspectives for an Administrative API,

(1) Admi= nistrative API for setting up/configuring gateways:
for example,
  • adding/updating/removing/disabling a new gateway
  • setting up aut= hentication for a gateway to use Airavata
  • setup gateway users for a= gateway
  • enable/disable users/resources for a gateway
  • setup community credentials/certificates for gateway
  • etc.
  • =

    Some of these can be mitigated to the gateway itself. But I do not think= we need to draw the line at this stage.

    (2) Administrative API for= configuring Airavata:
    (we are probably not ready for this yet) I'd think this will incl= ude managing most of the settings we have in the airavata-server.properties= and configurations supporting future implementations of load-balancing, sc= aling, fault tolerance, policy management etc.

    --001a11346dde93fa8804fa214a6f--