Return-Path: X-Original-To: apmail-stratos-dev-archive@minotaur.apache.org Delivered-To: apmail-stratos-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 24C4F17A39 for ; Wed, 1 Oct 2014 05:27:48 +0000 (UTC) Received: (qmail 24581 invoked by uid 500); 1 Oct 2014 05:27:47 -0000 Delivered-To: apmail-stratos-dev-archive@stratos.apache.org Received: (qmail 24534 invoked by uid 500); 1 Oct 2014 05:27:47 -0000 Mailing-List: contact dev-help@stratos.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stratos.apache.org Delivered-To: mailing list dev@stratos.apache.org Received: (qmail 24524 invoked by uid 99); 1 Oct 2014 05:27:47 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Oct 2014 05:27:47 +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 (nike.apache.org: domain of reka@wso2.com designates 209.85.216.50 as permitted sender) Received: from [209.85.216.50] (HELO mail-qa0-f50.google.com) (209.85.216.50) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Oct 2014 05:27:21 +0000 Received: by mail-qa0-f50.google.com with SMTP id w8so54274qac.23 for ; Tue, 30 Sep 2014 22:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=O+99rgaejiANbmCwFXzezI/Aql/rmbNzUqdGRN/JIoQ=; b=cEtMx994ciyySTwu5jn6b76C8HbD+bBcADgEL69NVv8SLndy3rZLZV0zM1NWZytPoy RkRyZ2t2aK6aQuqxQQIYQeEt/FvUxXiDUjEA3P/gqBwPuCVpFF5acEVNwTZ5HTDc03xi 5Sil28qw6cjkZkLPBWK6w2XUywK9eJ5HYLGJI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=O+99rgaejiANbmCwFXzezI/Aql/rmbNzUqdGRN/JIoQ=; b=T4p5lEQwHOuE8MxCUzKhdt3zO7wQdHf6EMA3DFjTkFb39WTRZ+AJ0kpXcokP/TcrSd oyYoIiezZ7VKRzrn8fi+AcSx+mDmFWeoVZLnp9GtqgurXb6H0z20eMb9F1CbRYgM4LAZ kzQpg0V5aJdHpiZPwjj1KmMV1rUJg0SRxPsDKcQllLOHRt2WLxJX1WAbHOSE9ttIDUNz 8idMXVOZbX6Mr5XIav3whtk/FwV8Czz/woFC1WUKn7HjRRNIM8R/xSk+323lIEOGYVfm ulhjdZ0Qcsn+3oZv9Cnq10BGE/t/+igzwBT5g8lK/h2j/sPQW0LELBkA/R03IS578rRC MN4g== X-Gm-Message-State: ALoCoQkKG09zTbbKxsogw9GOwOzgSGx7IjPmZy4NoNxthpu0mQDWStGzATvTcvi3MBkaHe/Z4HVJ X-Received: by 10.224.11.132 with SMTP id t4mr19341669qat.98.1412141239811; Tue, 30 Sep 2014 22:27:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.93.10 with HTTP; Tue, 30 Sep 2014 22:26:59 -0700 (PDT) In-Reply-To: References: <07110D8A7AC60C49AE2432100017A3F62777B7E6@xmb-rcd-x12.cisco.com> <07110D8A7AC60C49AE2432100017A3F62777B879@xmb-rcd-x12.cisco.com> <07110D8A7AC60C49AE2432100017A3F62777B8C0@xmb-rcd-x12.cisco.com> <07110D8A7AC60C49AE2432100017A3F62777C91F@xmb-rcd-x12.cisco.com> <07110D8A7AC60C49AE2432100017A3F62777DBC4@xmb-rcd-x12.cisco.com> From: Reka Thirunavukkarasu Date: Wed, 1 Oct 2014 10:56:59 +0530 Message-ID: Subject: Re: [Discuss] [Grouping] Specifying Dependency Information in Group Definition To: dev Cc: "Martin Eppel (meppel)" Content-Type: multipart/alternative; boundary=001a11c2c20af8d875050455c0c6 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c2c20af8d875050455c0c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi On Wed, Oct 1, 2014 at 10:33 AM, Isuru Haththotuwa wrote: > Hi Martin, > > On Tue, Sep 30, 2014 at 11:32 PM, Martin Eppel (meppel) > wrote: > >> Hi Isuru, >> >> >> >> Please see inline (=E2=80=9CMartin:=E2=80=9D) >> >> >> >> *From:* isuruh@wso2.com [mailto:isuruh@wso2.com] *On Behalf Of *Isuru >> Haththotuwa >> *Sent:* Tuesday, September 30, 2014 4:34 AM >> *To:* dev >> *Subject:* Re: [Discuss] [Grouping] Specifying Dependency Information in >> Group Definition >> >> >> >> For the initial meta data service integration with Service Grouping, I >> thought of following a simple approach: >> >> - Autoscaler will publish information about what is depending on >> which (using cluster ids) in a Application >> >> As i think, from autoscaler we need to publish these dependency information to metadataservice. Then cartridge agent need to get the dependent cluster/group from metadata service and listen on the dependent group/cluster's activated event. Once the activated event received, cartridge agent can retrieve all the information from the metadata service. > >> - >> - The dependency information will be published by the Cartridge Agent >> in the instance, prior to sending the InstanceActivated event >> =E2=80=9CMartin:=E2=80=9D can you clarify this =E2=80=93 does it mea= n the cartridge agent >> instance will receive the dependency information and make it availabl= e to >> the cartridge agent ? >> Is this a new event to publish the dependency ? >> >> Each cartridge agent will be publishing its own information to the meta > data service, so that depending instances in the same application can que= ry > them. This is not a new event, but will be directly publishing to the met= a > data service. > >> >> - >> - Any interested instance (depending instance) can first query its >> dependency cluster ids, and then get the dependency information >> - There will be a extension point so that custom implementation can >> be plugged in >> >> One main reason for doing this in simple way is that there is an ongoing >> effort to write a python based light weight Cartridge Agent. Therefore, = we >> would anyway need to change the publishing code, which is currently in J= ava >> and re-write it using python. Therefore, this implementation will be >> temporary AFAIU. >> >> =E2=80=9CMartin:=E2=80=9D What is the time line for the python based car= tridge agent ? >> > AFAIU, its still under initial stages of development. Will update on the > timeline. > >> >> >> >> >> On Thu, Sep 25, 2014 at 10:26 PM, Martin Eppel (meppel) >> wrote: >> >> Sure, I=E2=80=99ll keep a reference to the commit >> >> >> >> *From:* isuruh@wso2.com [mailto:isuruh@wso2.com] *On Behalf Of *Isuru >> Haththotuwa >> *Sent:* Tuesday, September 23, 2014 11:26 PM >> >> >> *To:* dev >> *Subject:* Re: [Discuss] [Grouping] Specifying Dependency Information in >> Group Definition >> >> >> >> Hi Martin, >> >> Seems this model might not work if there are only cartridges at the >> application without Groups. We can specify an application without Groups= , >> but with multiple single cartridge subscriptions. In that case also, we = may >> need to share some information. >> >> For now, I will revert the commit. Please keep a diff with you so that w= e >> can apply accordingly when we think through this. >> >> >> >> On Wed, Sep 24, 2014 at 10:54 AM, Martin Eppel (meppel) >> wrote: >> >> Sure will do, I=E2=80=99ll check if we have any requirements like this >> >> >> >> Btw, I haven=E2=80=99t added the new fields to the schema yet, >> >> >> >> Regards >> >> >> >> Martin >> >> >> >> *From:* isuruh@wso2.com [mailto:isuruh@wso2.com] *On Behalf Of *Isuru >> Haththotuwa >> *Sent:* Tuesday, September 23, 2014 10:09 PM >> >> >> *To:* dev >> *Subject:* Re: [Discuss] [Grouping] Specifying Dependency Information in >> Group Definition >> >> >> >> That is totally fine. Please do share if you have any ideas for improvin= g >> it so that we can work on them. The main requirement is to expose some >> information from one Group/leaf level subscription so that any depending >> instances can use them to form the connections within the application. >> >> >> >> On Wed, Sep 24, 2014 at 9:47 AM, Martin Eppel (meppel) >> wrote: >> >> Mmmh, I already added it =E2=80=A6 >> >> >> >> *From:* isuruh@wso2.com [mailto:isuruh@wso2.com] *On Behalf Of *Isuru >> Haththotuwa >> *Sent:* Tuesday, September 23, 2014 7:58 PM >> *To:* dev >> *Subject:* Re: [Discuss] [Grouping] Specifying Dependency Information in >> Group Definition >> >> >> >> Hi Martin, >> >> >> >> On Wed, Sep 24, 2014 at 4:44 AM, Martin Eppel (meppel) >> wrote: >> >> Hi Isuru, >> >> >> >> What kind of properties are you referring to where this would be the cas= e >> ? Is there an actual use case for this ? Which code in stratos would >> actually take these properties into account and apply them ? >> >> By properties, I meant just key value pairs. The actual use case is to >> expose information about a particular Group, to a depending Group which >> will be interested in communicating with the former. For an example, tak= e a >> PHP instance and a DB Group. The PHP instance might require the DB's >> endpoint to communicate with it. In that case, DB Group will expose the >> endpoint and PHP can pick it up. So, in the DB group, we should specify = the >> endpoint as a dynamic property in the definition. The static properties = are >> similar to the payload parameters that we currently specify in the >> cartridge definition. >> >> Currently I can't point to a single location to say that these will be >> used from that location of the code. >> >> Also, as per the M1 task list [1] I shared, we might not need this for >> M1. Therefore, maybe we can properly think through before implementing. >> WDYT? >> >> [1]. Planing for Service Grouping - M1 >> >> >> >> Thanks >> >> >> >> Martin >> >> >> >> *From:* isuruh@wso2.com [mailto:isuruh@wso2.com] *On Behalf Of *Isuru >> Haththotuwa >> *Sent:* Sunday, September 21, 2014 1:05 AM >> *To:* dev >> *Subject:* [Discuss] [Grouping] Specifying Dependency Information in >> Group Definition >> >> >> >> Hi Devs, >> >> In Service Grouping, a cartridge that is depending on another might need >> some information (endpoint, etc.) about the latter. AFAIU this informati= on >> will be specific to a Service in a Group. Therefore, I suggest we add th= is >> properties to the cartridges section of the Group definition. I have sho= wn >> a simple Group Definition with the proposed changes [1]. >> >> Here, dynamicProperties contains the names of properties of which values >> should be dynamically picked at the runtime. If a user needs custom >> properties, we should define a abstraction so that a custom implementati= on >> can be loaded at the runtime. The per-defined property name-value pairs = are >> defined in the staticProperties section. >> >> These data can be published to the meta data service. The relevant membe= r >> instances can query them and get the information about the dependencies. >> Handling this information would be done at the instance level (using >> Cartridge Agent, etc.). >> >> >> >> Please share your feedback. >> >> >> [1]. >> { >> "name": "group1", >> "cartridges": [ >> { >> "type": "mysql", >> "dynamicProperties": [ >> "hostname", >> >> "port" >> >> ], >> "staticProperties": [ >> { >> "name": "property1", >> "value": "property1_value" >> }, >> { >> "name": "property2", >> "value": "property2_value" >> } >> ] >> } >> ], >> "dependencies": { >> "killBehaviour": "kill-none" >> } >> } >> >> -- >> >> Thanks and Regards, >> >> Isuru H. >> >> +94 716 358 048 >> >> -- >> <%2B94%20716%20358%20048> >> >> Thanks and Regards, >> >> Isuru H. >> <%2B94%20716%20358%20048> >> >> +94 716 358 048 >> >> -- >> >> <%2B94%20716%20358%20048> >> >> >> >> >> >> *Thanks and Regards, Isuru H. <%2B94%20716%20358%20048>* >> >> >> >> >> >> *+94 716 358 048 -- <%2B94%20716%20358%20048>* >> >> >> >> >> >> *Thanks and Regards, Isuru H. <%2B94%20716%20358%20048>* >> >> >> >> >> >> *+94 716 358 048 -- <%2B94%20716%20358%20048>* >> >> >> >> >> >> *Thanks and Regards, Isuru H. <%2B94%20716%20358%20048>* >> >> >> >> >> *+94 716 358 048-- <%2B94%20716%20358%20048>* >> >> >> >> *Thanks and Regards,Isuru H. <%2B94%20716%20358%20048>* >> >> >> >> * +94 716 358 048 <%2B94%20716%20358%20048> * >> >> >> >> * * >> >> --=20 Reka Thirunavukkarasu Senior Software Engineer, WSO2, Inc.:http://wso2.com, Mobile: +94776442007 --001a11c2c20af8d875050455c0c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

On Wed, Oct 1, 2014 at 10:33 AM, Isuru Haththotuwa <= isuruh@apache.org> wrote:
Hi M= artin,

<= span class=3D"">On Tue, Sep 30, 2014 at 11:32 PM, Martin Eppel (meppel) <me= ppel@cisco.com> wrote:

Hi Isuru,

=C2=A0

Please see inline (=E2=80= =9CMartin:=E2=80=9D)

=C2=A0

From: isuruh@wso2.com [mailto:<= a href=3D"mailto:isuruh@wso2.com" target=3D"_blank">isuruh@wso2.com] On Behalf Of Isuru Haththotuwa
Sent: Tuesday, September 30, 2014 4:34 AM
To: dev
Subject: Re: [Discuss] [Grouping] Specifying Dependency Information = in Group Definition

=C2=A0

For the initial meta data service integration with S= ervice Grouping, I thought of following a simple approach:

  • Autoscaler will publish information about what is depending on which (using= cluster ids) in a Application
As i think, from autosc= aler we need to publish these dependency information to metadataservice. Th= en cartridge agent need to get the dependent cluster/group from metadata se= rvice and listen on the dependent group/cluster's activated event. Once= the activated event received, cartridge agent can retrieve all the informa= tion from the metadata service.
  • = The dependency information will be publish= ed by the Cartridge Agent in the instance, prior to sending the InstanceAct= ivated event
     =E2=80=9CMartin:=E2=80=9D =C2=A0can you clarify this =E2=80=93 does it mean= the cartridge agent instance will receive the dependency information and m= ake it available to the cartridge agent ?
    Is this a new event to publish the dependency ?
<= /div>
Each cartridge agent will be publishing its o= wn information to the meta data service, so that depending instances in the= same application can query them. This is not a new event, but will be dire= ctly publishing to the meta data service.
=

  • Any interested instance (depending instance) can first query its dependency= cluster ids, and then get the dependency information
  • There will be a extension point so that custom implementation can be plugge= d in

One main reason for doing this in simple way is that there is an ongoing= effort to write a python based light weight Cartridge Agent. Therefore, we= would anyway need to change the publishing code, which is currently in Jav= a and re-write it using python. Therefore, this implementation will be temporary AFAIU.

=E2=80=9CMartin:= =E2=80=9D What is the time line for the python based cartridge agent ?

AFAIU, its still under ini= tial stages of development. Will update on the timeline.=C2=A0

=C2=A0

=C2=A0

On Thu, Sep 25, 2014 at 10:26 PM, Martin Eppel (mepp= el) <meppel@cisco.= com> wrote:

Sure, I=E2=80=99ll keep a= reference to the commit

=C2=A0

From: isuruh@wso2.com [m= ailto:isuruh@wso2.com<= /a>] On Behalf Of Isuru Haththotuwa
Sent: Tuesday, September 23, 2014 11:26 PM


To: dev
Subject: Re: [Discuss] [Grouping] Specifying Dependency Information = in Group Definition

=C2=A0

Hi Martin,

Seems this model migh= t not work if there are only cartridges at the application without Groups. = We can specify an application without Groups, but with multiple single cart= ridge subscriptions. In that case also, we may need to share some information.

For now, I will revert the commit. Please keep a dif= f with you so that we can apply accordingly when we think through this.

=C2=A0

On Wed, Sep 24, 2014 at 10:54 AM, Martin Eppel (mepp= el) <meppel@cisco.= com> wrote:

Sure will do, I=E2=80=99l= l check if we have any requirements like this

=C2=A0

Btw, I haven=E2=80=99t ad= ded the new fields to the schema yet,

=C2=A0

Regards<= /u>

=C2=A0

Martin

=C2=A0

From: isuruh@wso2.com [m= ailto:isuruh@wso2.com<= /a>] On Behalf Of Isuru Haththotuwa
Sent: Tuesday, September 23, 2014 10:09 PM


To: dev
Subject: Re: [Discuss] [Grouping] Specifying Dependency Information = in Group Definition

=C2=A0

That is totally fine. Please do share if you have an= y ideas for improving it so that we can work on them. The main requirement = is to expose some information from one Group/leaf level subscription so that any depending instances can use them to form th= e connections within the application.

=C2=A0

On Wed, Sep 24, 2014 at 9:47 AM, Martin Eppel (meppe= l) <meppel@cisco.c= om> wrote:

Mmmh, I already added it = =E2=80=A6

=C2=A0

From: isuruh@wso2.com [m= ailto:isuruh@wso2.com<= /a>] On Behalf Of Isuru Haththotuwa
Sent: Tuesday, September 23, 2014 7:58 PM
To: dev
Subject: Re: [Discuss] [Grouping] Specifying Dependency Information = in Group Definition

=C2=A0

Hi Martin,

=C2=A0

On Wed, Sep 24, 2014 at 4:44 AM, Martin Eppel (meppe= l) <meppel@cisco.c= om> wrote:

Hi Isuru,

=C2=A0

What kind of properties a= re you referring to where this would be the case ? Is there an actual use case for this ? Which code in stratos would actually take these properties= into account and apply them ?

By properties, I mean= t just key value pairs. The actual use case is to expose information about = a particular Group, to a depending Group which will be interested in commun= icating with the former. For an example, take a PHP instance and a DB Group. The PHP in= stance might require the DB's endpoint to communicate with it. In that = case, DB Group will expose the endpoint and PHP can pick it up. So, in the = DB group, we should specify the endpoint as a dynamic property in the definition. The static properties are similar= to the payload parameters that we currently specify in the cartridge defin= ition.

Currently I can't point to a single location to = say that these will be used from that location of the code.

Also, as per the M1 task list [1] I shared, we might not need this for M1. = Therefore, maybe we can properly think through before implementing. WDYT?
[1]. Planing for Service Grouping - M1

=C2=A0

Thanks

=C2=A0

Martin

=C2=A0

From: isuruh@wso2.com [m= ailto:isuruh@wso2.com<= /a>] On Behalf Of Isuru Haththotuwa
Sent: Sunday, September 21, 2014 1:05 AM
To: dev
Subject: [Discuss] [Grouping] Specifying Dependency Information in G= roup Definition

=C2=A0

Hi Devs,

In Service Grouping, = a cartridge that is depending on another might need some information (endpo= int, etc.) about the latter. AFAIU this information will be specific to a S= ervice in a Group. Therefore, I suggest we add this properties to the cartridges secti= on of the Group definition. I have shown a simple Group Definition with the= proposed changes [1].

Here, dynamicProperti= es contains the names of properties of which values should be dynamically p= icked at the runtime. If a user needs custom properties, we should define a= abstraction so that a custom implementation can be loaded at the runtime. The per-defi= ned property name-value pairs are defined in the staticProperties section.

These data can be published to the meta data service= . The relevant member instances can query them and get the information abou= t the dependencies. Handling this information would be done at the instance level (using Cartridge Agent, etc.).=

=C2=A0

Please share your feedback.


[1].
{
=C2=A0 "name": "group1",
=C2=A0 "cartridges": [
=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "type": "mysql",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "dynamicProperties": [
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "hostname",<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "por= t"

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ],
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "staticProperties": [
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "name": &q= uot;property1",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "value": &= quot;property1_value"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "name": &q= uot;property2",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "value": &= quot;property2_value"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ]
=C2=A0=C2=A0=C2=A0 }
=C2=A0 ],
=C2=A0 "dependencies": {
=C2=A0=C2=A0=C2=A0 "killBehaviour": "kill-none"
=C2=A0 }
}

--

<= /div>
=



--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:= http://wso2.com,
Mobile: +94776442007


--001a11c2c20af8d875050455c0c6--