[New Architecture] Topology Domain Model - V1

[Imesh Gunaratne <im...@apache.org>]

Hi,

Please find the initial version of proposed Topology Domain Model below. I
have now added this model to org.apache.stratos.messaging component and
committed to git.

[image: Inline image 2]

I'm currently working on improving the model where clusters/members are
connected to different Clouds (IaaSs), Regions and Zones. Once it's done I
will send another update.

Please feel free to add your thoughts.

Thanks
Imesh

Re: [New Architecture] Topology Domain Model - V1

[Nirmal Fernando <ni...@apache.org>]

On Tue, Oct 15, 2013 at 8:43 AM, Nirmal Fernando <ni...@apache.org>wrote:

>
> [Resending since it got bounced for some weird reason.]
>
> On Tue, Oct 15, 2013 at 7:25 AM, Nirmal Fernando <ni...@gmail.com>wrote:
>
>>
>> On Oct 14, 2013 11:27 PM, "Imesh Gunaratne" <im...@apache.org> wrote:
>> >
>> > Hi Nirmal,
>> >
>> > It's a pleasure! Thanks for the quick feedback. Please find the updated
>> diagram below:
>> >
>> >
>> >
>> > Feedback
>> > 1. Service: serviceName, domainName
>> > My idea was to use service domain name to map the incoming requests to
>> their services when serving requests in the load balancer.
>> > Example: Request URL: http://a1.tomcat.foo.org/xyz/abc, Service Domain
>> Name: tomcat.foo.org
>> > Do we have a better option?
>> I think you got confused with service and a cluster. Service is really
>> the cartridge type and it's a virtual concept for grouping purposes eg:
>> PHP. A cluster should have a host name like your example but not service.
>>
>> >
>> > 2. MemberStatus: Starting, Activated, Suspended, Terminated
>> > I thought if the Cloud Controller set the member status to Starting
>> when an instance is booting up, if the application is faulty and did not
>> get activated, the system could identify that using this status.
>> > WDYT?
>>
>> Imesh, I think the problem is from which perspective we're thinking here.
>> I wonder whether going for a common model across all the Stratos components
>> is necessary and correct, cause IMO each of those different components need
>> a unique information model.
>>
> It appears that this is required for de-serializing topology message by
each component. So, we (Imesh and myself) thought the best way is that each
component should build up its own information model by keeping references
to the topology model (i.e. on top of this topology model).

This topology model is designed from the perspective of CC.

>
>> >
>> > Clouds, Regions, Zones
>> > The above diagram illustrates the relationships between Cluster, Cloud,
>> Region and Zone. Cluster -> Zone might be 1: 0,1. Which means zones could
>> be used if available in given IaaS, otherwise Clouds and Regions could be
>> used.
>> >
>> >
>> > Thanks
>> > Imesh
>> >
>> >
>> > On Mon, Oct 14, 2013 at 7:22 PM, Nirmal Fernando <
>> nirmal070125@gmail.com> wrote:
>> >>
>> >> Imesh,
>> >>
>> >> Thanks for bringing this up.
>> >>
>> >> Few suggestions;
>> >>
>> >> 1. serviceId, domainName, name why we need those? IMO we just need
>> serviceName.
>> >> 2. service can have set of properties.
>> >> 3. clusterId, domainName - IMO we just need clusterId which will be
>> used to uniquely identify a service cluster.
>> >> 4. CartridgeType == serviceName, hence I don't think we need it in the
>> cluster model.
>> >> 5. Again, cluster can have a set of properties.
>> >> 6. In Port; /s/name/protocol
>> >> 7. I don't think the life cycle of a Member is correct. A member would
>> never subscribe/unsubscribe. Member cannot be in a Starting state, cause it
>> is the member itself let Stratos know that it is started and then only we
>> should add a Member to the model. Hence, IMO member's life cycle states
>> would be Active, Suspended, Terminated.
>> >> 8. I don't think the cardinality is correct in any of these. 1 --> n
>> should be in all of them other than 'Member -> MemberStatus'.
>> >>
>> >>
>> >>
>> >> On Mon, Oct 14, 2013 at 5:32 PM, Imesh Gunaratne <im...@apache.org>
>> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> Please find the initial version of proposed Topology Domain Model
>> below. I have now added this model to org.apache.stratos.messaging
>> component and committed to git.
>> >>>
>> >>>
>> >>>
>> >>> I'm currently working on improving the model where clusters/members
>> are connected to different Clouds (IaaSs), Regions and Zones. Once it's
>> done I will send another update.
>> >>>
>> >>> Please feel free to add your thoughts.
>> >>>
>> >>> Thanks
>> >>> Imesh
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Best Regards,
>> >> Nirmal
>> >>
>> >> Nirmal Fernando.
>> >> PPMC Member & Committer of Apache Stratos,
>> >> Senior Software Engineer, WSO2 Inc.
>> >>
>> >> Blog: http://nirmalfdo.blogspot.com/
>> >
>> >
>>
>>
>

Re: [New Architecture] Topology Domain Model - V1

[Nirmal Fernando <ni...@apache.org>]

[Resending since it got bounced for some weird reason.]

On Tue, Oct 15, 2013 at 7:25 AM, Nirmal Fernando <ni...@gmail.com>wrote:

>
> On Oct 14, 2013 11:27 PM, "Imesh Gunaratne" <im...@apache.org> wrote:
> >
> > Hi Nirmal,
> >
> > It's a pleasure! Thanks for the quick feedback. Please find the updated
> diagram below:
> >
> >
> >
> > Feedback
> > 1. Service: serviceName, domainName
> > My idea was to use service domain name to map the incoming requests to
> their services when serving requests in the load balancer.
> > Example: Request URL: http://a1.tomcat.foo.org/xyz/abc, Service Domain
> Name: tomcat.foo.org
> > Do we have a better option?
> I think you got confused with service and a cluster. Service is really the
> cartridge type and it's a virtual concept for grouping purposes eg: PHP. A
> cluster should have a host name like your example but not service.
>
> >
> > 2. MemberStatus: Starting, Activated, Suspended, Terminated
> > I thought if the Cloud Controller set the member status to Starting when
> an instance is booting up, if the application is faulty and did not get
> activated, the system could identify that using this status.
> > WDYT?
>
> Imesh, I think the problem is from which perspective we're thinking here.
> I wonder whether going for a common model across all the Stratos components
> is necessary and correct, cause IMO each of those different components need
> a unique information model.
>
> >
> > Clouds, Regions, Zones
> > The above diagram illustrates the relationships between Cluster, Cloud,
> Region and Zone. Cluster -> Zone might be 1: 0,1. Which means zones could
> be used if available in given IaaS, otherwise Clouds and Regions could be
> used.
> >
> >
> > Thanks
> > Imesh
> >
> >
> > On Mon, Oct 14, 2013 at 7:22 PM, Nirmal Fernando <ni...@gmail.com>
> wrote:
> >>
> >> Imesh,
> >>
> >> Thanks for bringing this up.
> >>
> >> Few suggestions;
> >>
> >> 1. serviceId, domainName, name why we need those? IMO we just need
> serviceName.
> >> 2. service can have set of properties.
> >> 3. clusterId, domainName - IMO we just need clusterId which will be
> used to uniquely identify a service cluster.
> >> 4. CartridgeType == serviceName, hence I don't think we need it in the
> cluster model.
> >> 5. Again, cluster can have a set of properties.
> >> 6. In Port; /s/name/protocol
> >> 7. I don't think the life cycle of a Member is correct. A member would
> never subscribe/unsubscribe. Member cannot be in a Starting state, cause it
> is the member itself let Stratos know that it is started and then only we
> should add a Member to the model. Hence, IMO member's life cycle states
> would be Active, Suspended, Terminated.
> >> 8. I don't think the cardinality is correct in any of these. 1 --> n
> should be in all of them other than 'Member -> MemberStatus'.
> >>
> >>
> >>
> >> On Mon, Oct 14, 2013 at 5:32 PM, Imesh Gunaratne <im...@apache.org>
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Please find the initial version of proposed Topology Domain Model
> below. I have now added this model to org.apache.stratos.messaging
> component and committed to git.
> >>>
> >>>
> >>>
> >>> I'm currently working on improving the model where clusters/members
> are connected to different Clouds (IaaSs), Regions and Zones. Once it's
> done I will send another update.
> >>>
> >>> Please feel free to add your thoughts.
> >>>
> >>> Thanks
> >>> Imesh
> >>
> >>
> >>
> >>
> >> --
> >> Best Regards,
> >> Nirmal
> >>
> >> Nirmal Fernando.
> >> PPMC Member & Committer of Apache Stratos,
> >> Senior Software Engineer, WSO2 Inc.
> >>
> >> Blog: http://nirmalfdo.blogspot.com/
> >
> >
>
>

Re: [New Architecture] Topology Domain Model - V1

[Imesh Gunaratne <im...@apache.org>]

Hi Nirmal,

It's a pleasure! Thanks for the quick feedback. Please find the updated
diagram below:

[image: Inline image 3]

*Feedback*
1. Service: serviceName, domainName
My idea was to use service domain name to map the incoming requests to
their services when serving requests in the load balancer.
Example: Request URL: http://a1.tomcat.foo.org/xyz/abc, Service Domain
Name: tomcat.foo.org
Do we have a better option?

2. MemberStatus: Starting, Activated, Suspended, Terminated
I thought if the Cloud Controller set the member status to Starting when an
instance is booting up, if the application is faulty and did not get
activated, the system could identify that using this status.
WDYT?

*Clouds, Regions, Zones*
The above diagram illustrates the relationships between Cluster, Cloud,
Region and Zone. Cluster -> Zone might be 1: 0,1. Which means zones could
be used if available in given IaaS, otherwise Clouds and Regions could be
used.


Thanks
Imesh


On Mon, Oct 14, 2013 at 7:22 PM, Nirmal Fernando <ni...@gmail.com>wrote:

> Imesh,
>
> Thanks for bringing this up.
>
> Few suggestions;
>
> 1. serviceId, domainName, name why we need those? IMO we just need
> serviceName.
> 2. service can have set of properties.
> 3. clusterId, domainName - IMO we just need clusterId which will be used
> to uniquely identify a service cluster.
> 4. CartridgeType == serviceName, hence I don't think we need it in the
> cluster model.
> 5. Again, cluster can have a set of properties.
> 6. In Port; /s/name/protocol
> 7. I don't think the life cycle of a Member is correct. A member would
> never subscribe/unsubscribe. Member cannot be in a Starting state, cause it
> is the member itself let Stratos know that it is started and then only we
> should add a Member to the model. Hence, IMO member's life cycle states
> would be Active, Suspended, Terminated.
> 8. I don't think the cardinality is correct in any of these. 1 --> n
> should be in all of them other than 'Member -> MemberStatus'.
>
>
>
> On Mon, Oct 14, 2013 at 5:32 PM, Imesh Gunaratne <im...@apache.org> wrote:
>
>> Hi,
>>
>> Please find the initial version of proposed Topology Domain Model below.
>> I have now added this model to org.apache.stratos.messaging component and
>> committed to git.
>>
>> [image: Inline image 2]
>>
>> I'm currently working on improving the model where clusters/members are
>> connected to different Clouds (IaaSs), Regions and Zones. Once it's done I
>> will send another update.
>>
>> Please feel free to add your thoughts.
>>
>> Thanks
>> Imesh
>>
>
>
>
> --
> Best Regards,
> Nirmal
>
> Nirmal Fernando.
> PPMC Member & Committer of Apache Stratos,
> Senior Software Engineer, WSO2 Inc.
>
> Blog: http://nirmalfdo.blogspot.com/
>

Re: [New Architecture] Topology Domain Model - V1

[Nirmal Fernando <ni...@gmail.com>]

Imesh,

Thanks for bringing this up.

Few suggestions;

1. serviceId, domainName, name why we need those? IMO we just need
serviceName.
2. service can have set of properties.
3. clusterId, domainName - IMO we just need clusterId which will be used to
uniquely identify a service cluster.
4. CartridgeType == serviceName, hence I don't think we need it in the
cluster model.
5. Again, cluster can have a set of properties.
6. In Port; /s/name/protocol
7. I don't think the life cycle of a Member is correct. A member would
never subscribe/unsubscribe. Member cannot be in a Starting state, cause it
is the member itself let Stratos know that it is started and then only we
should add a Member to the model. Hence, IMO member's life cycle states
would be Active, Suspended, Terminated.
8. I don't think the cardinality is correct in any of these. 1 --> n should
be in all of them other than 'Member -> MemberStatus'.



On Mon, Oct 14, 2013 at 5:32 PM, Imesh Gunaratne <im...@apache.org> wrote:

> Hi,
>
> Please find the initial version of proposed Topology Domain Model below. I
> have now added this model to org.apache.stratos.messaging component and
> committed to git.
>
> [image: Inline image 2]
>
> I'm currently working on improving the model where clusters/members are
> connected to different Clouds (IaaSs), Regions and Zones. Once it's done I
> will send another update.
>
> Please feel free to add your thoughts.
>
> Thanks
> Imesh
>



-- 
Best Regards,
Nirmal

Nirmal Fernando.
PPMC Member & Committer of Apache Stratos,
Senior Software Engineer, WSO2 Inc.

Blog: http://nirmalfdo.blogspot.com/