stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nirmal Fernando <nirmal070...@gmail.com>
Subject Re: Cloud Controller - Create an extension point to attach different configuration (topology) publishers
Date Sat, 17 Aug 2013 19:19:53 GMT
On Thu, Aug 15, 2013 at 6:20 PM, Isuru Perera <chrishantha@gmail.com> wrote:

>
>
>
> On Thu, Aug 15, 2013 at 3:11 AM, Nirmal Fernando <nirmal070125@gmail.com>wrote:
>
>>
>>
>>
>> On Wed, Aug 14, 2013 at 7:58 PM, Isuru Perera <chrishantha@gmail.com>wrote:
>>
>>>
>>> On Wed, Aug 14, 2013 at 7:02 PM, Nirmal Fernando <nirmal070125@gmail.com
>>> > wrote:
>>>
>>>>
>>>> On Aug 14, 2013 4:55 AM, "Isuru Perera" <chrishantha@gmail.com> wrote:
>>>> >
>>>> > Well, if we support other Message Brokers with extension points,
>>>> there is no need to start internal MB with Cassandra data store.
>>>> >
>>>> > I just need to decouple Message Broker from Cloud Controller since it
>>>> brings lot of dependencies. As a result, I cannot proceed with jclouds
>>>> upgrade due to dependency issue with guava libraries. (I mentioned this in
>>>> another thread)
>>>> >
>>>>
>>>> Well, there should be another way to solve the original problem you
>>>> have, instead of chosing the lazy path :-)
>>>>
>>> I agree that removing MB features is just an easy path to solve the
>>> original problem! But you cannot call it lazy, since I also plan to
>>> implement a workaround! :-)
>>>
>>> Besides, the problem is with external features and I'm just trying to
>>> solve it within Stratos code base.
>>>
>>>>  > Since you started the discussion on supporting external topology
>>>> publisher, I think it would a good starting point to remove MB features.
>>>> Even running a message broker externally would be okay since this is a PaaS
>>>> and it is just another process in the system.
>>>> >
>>>>
>>>> Topic resides in whatever the message broker is of utmost importance
>>>> for Apache Stratos to function properly. If we remove the default embedded
>>>> MB, what would we ship by default?
>>>>
>>>> Initially we used an external MB, but why we decided to get only
>>>> necessary MB related features was to minimize the # of JVMs and make it
>>>> easily configurable.
>>>>
>>> My point is that we do not need to bundle a Message Broker with Cloud
>>> Controller. We can initially support Apache ActiveMQ and WSO2 MB. We will
>>> provide detailed configuration steps in Cloud Controller for both. There is
>>> nothing to configure in Message Broker. Then users can choose a Message
>>> Broker of their choice without any complexity. Adding an extra JVM process
>>> in to the system is not an issue in my opinion.
>>>
>>
>> Well, if I am new to Apache Stratos and wanna try it out, I surely don't
>> want to do all those manual configurations etc.
>>
>> We should think from the user perspective as well and should not
>> discourage new users IMO.
>>
> I don't understand how this discourages new users. As I mentioned earlier,
> we will be providing all the required configurations with docs.
>

You'll realize it eventually.

>   > If I understand correctly, your extension point is about adding
>>>> another class. That is good if the new MB topology publisher is completely
>>>> different, but we can simply support many more message brokers with a
>>>> single class by providing relevant parameters, such as
>>>> java.naming.factory.initial
>>>> >
>>>>
>>>> Well this is an improvement that one could make. You have the
>>>> foundation built, play wisely.
>>>>
>>> I'm working on the improvement. :)
>>>
>>
>> While you are trying to make a single class to support multiple
>> providers, you're making CC hard to configure.
>>
>> For an example currently to configure topology publisher, you only need
>> following:
>>
>>
>>    <topologySync enable="true">
>>         <!-- properties related to topology syncher -->
>>         <property name="className"
>> value="org.apache.stratos.cloud.controller.ABC"/>
>>         <property name="mbServerUrl" value="localhost:5674"/>
>>         <property name="cron" value="1 * * * * ? *"/>
>>     </topologySync>
>>
>> But if you make this change, a user need to have something like following
>> configuration:
>>
>>
>>      <topologySync enable="true">
>>         <!-- properties related to topology syncher -->
>>         <property name="className"
>> value="org.apache.stratos.cloud.controller.ABC"/>
>>          <property name="connectionfactory.qpidConnectionfactory"
>> value="amqp://admin:admin@clientID
>> /carbon?brokerlist='tcp://localhost:5674'"/>
>>
>>         <property name="cron" value="1 * * * * ? *"/>
>>          <property name="java.naming.factory.initial"
>> value="org.wso2.andes.jndi.PropertiesFileInitialContextFactory"/>
>>     </topologySync>
>>
> This is much more cleaner to me than just specifying some class with all
> configuration details hidden.  I'm thinking of a similar configuration for
> subscriber also.
>
> I think the current way of configuring the subscriber is also really
> confusing. There are two different ways to configure the subscriber in SC
> and ELB. For ELB you need to edit the loadbalancer.conf and for SC you have
> to use a startup parameter. As I remember, For ELB it's mb_server_url and
> for SC it's mb.server.ip. SC also has the same config in
> cartridge-config.properties as well and user need to have same config in
> both places
>
> We need to fix these inconsistencies.
>
>
Yes, yes. Any Software should be evolved by time, you can't hold a release
till it reach perfection (if you do hold, you will never able to do a
release).

This is my last email to this thread, I've more important work than arguing
here.

>
>> Let the community decide the best approach.
>>
> +1. May be we can start a new discussion thread.
>
>>    (I personally am not familiar with those other MBs in town.)
>>>>
>>> > For example, see [1] and [2]. Apache Axis2 uses only JMSListener class
>>>> to support multiple message brokers.
>>>> >
>>>> > This is what I expect in the context of Apache Stratos also. As a
>>>> start we can test Apache ActiveMQ and WSO2 Message Broker.
>>>> >
>>>> > I added https://issues.apache.org/jira/browse/STRATOS-52 to track
>>>> this.
>>>> >
>>>> > [1]
>>>> http://docs.wso2.org/wiki/display/ESB470/Configuring+JMS+Transport
>>>> > [2] http://axis.apache.org/axis2/java/transports/jms.html
>>>> >
>>>> >
>>>> > On Wed, Aug 14, 2013 at 4:31 PM, Nirmal Fernando <
>>>> nirmal070125@gmail.com> wrote:
>>>> >>
>>>> >>
>>>> >> On Aug 10, 2013 7:14 AM, "Isuru Perera" <chrishantha@gmail.com>
>>>> wrote:
>>>> >> >
>>>> >> > Hi all,
>>>> >> >
>>>> >> >
>>>> >> > On Thu, Aug 8, 2013 at 9:13 AM, Isuru Perera <
>>>> chrishantha@gmail.com> wrote:
>>>> >> >>
>>>> >> >> Hi,
>>>> >> >>
>>>> >> >> +1 for the approach!
>>>> >> >>
>>>> >> >> I think this is a good start to remove Message Broker features
in
>>>> Cloud Controller eventually.
>>>> >> >>
>>>> >> >> Perhaps we could modify the default implementation to be
more
>>>> generic as we could use AMQP.
>>>> >> >
>>>> >> > I would like to start working on this. (I think it's better
to
>>>> remove MB features from Cloud Controller and make it more light-weight.
>>>> Right now it takes about 1 minute to start).
>>>> >> >
>>>> >>
>>>> >> This is a PaaS and you do not do frequent restarts etc. Hence, IMO
>>>> server start up time isn't a that critical concern.
>>>> >>
>>>> >> > We can then allow users to use any MB. Let's see whether we
can
>>>> use ActiveMQ and RabbitMQ
>>>> >> >
>>>> >>
>>>> >> Your statement is misleading. We don't need to remove WSO2 MB
>>>> features from CC in order to support other MBs.
>>>> >>
>>>> >> In fact the sole purpose of the email of mine was to introduce this
>>>> extension point.
>>>> >> IMO for the time being we just need to focus on using this extension
>>>> point and provide support to other MBs.
>>>> >>
>>>> >> > I think this will not be a considerable effort.
>>>> >> >
>>>> >> > Suggestions?
>>>> >> >>
>>>> >> >>
>>>> >> >> As you said, we could also have generic subscriber in ELB
and
>>>> Stratos Controller.
>>>> >> >>
>>>> >> >> I would like to see the code in Apache Git. :)
>>>> >> >>
>>>> >> >> Thanks!
>>>> >> >>
>>>> >> >> Best Regards,
>>>> >> >>
>>>> >> >>
>>>> >> >> On Wed, Aug 7, 2013 at 10:35 PM, Nirmal Fernando <
>>>> nirmal070125@gmail.com> wrote:
>>>> >> >>>
>>>> >> >>> Hi All,
>>>> >> >>>
>>>> >> >>> I worked on the $subject as and when I got time. And
believe
>>>> that I clearly separated out and provided an extension point to add any
>>>> custom topology publisher.
>>>> >> >>>
>>>> >> >>> While doing this I had to change the current configuration
of
>>>> topology publisher as below:
>>>> >> >>>
>>>> >> >>>     <topologySync enable="true">
>>>> >> >>>         <!-- properties related to topology syncher
-->
>>>> >> >>>         <property name="className"
>>>> value="org.apache.stratos.cloud.controller.ABC"/>
>>>> >> >>>         <property name="mbServerUrl" value="localhost:5674"/>
>>>> >> >>>         <property name="cron" value="1 * * * * ?
*"/>
>>>> >> >>>     </topologySync>
>>>> >> >>>
>>>> >> >>>
>>>> >> >>> If you want to plug a new implementation instead of
using the
>>>> default implementation (WSO2MBTopologyPublisher), you should extend the
>>>> following abstract class and configure it using a property (eg: <property
>>>> name="className" value="org.apache.stratos.cloud.controller.ABC"/>).
>>>> >> >>>
>>>> >> >>> package org.apache.stratos.cloud.controller.interfaces;
>>>> >> >>>
>>>> >> >>> /**
>>>> >> >>>  * All custom implementations of Topology Publisher
should
>>>> extend this abstract class.
>>>> >> >>>  */
>>>> >> >>> public abstract class TopologyPublisher {
>>>> >> >>>
>>>> >> >>>     /**
>>>> >> >>>      * This operation will be called once in order
to initialize
>>>> this publisher.
>>>> >> >>>      */
>>>> >> >>>     public abstract void init();
>>>> >> >>>
>>>> >> >>>     /**
>>>> >> >>>      * When a message is ready to be published to a
certain
>>>> topic, this operation will be called.
>>>> >> >>>      * @param topicName name of the topic to be published.
>>>> >> >>>      * @param message message to be published.
>>>> >> >>>      */
>>>> >> >>>     public abstract void publish(String topicName,
String
>>>> message);
>>>> >> >>>
>>>> >> >>>     /**
>>>> >> >>>      * Cron expression which explains the frequency
that the
>>>> topology publishing happens.
>>>> >> >>>      * @return cron expression
>>>> >> >>>      */
>>>> >> >>>     public abstract String getCron();
>>>> >> >>>
>>>> >> >>> }
>>>> >> >>>
>>>> >> >>> You have the freedom to get any necessary parameters
for your
>>>> custom topology publisher implementation, due to the nature of the
>>>> configuration shown above. Any number of properties are allowed and those
>>>> can be retrieved via the object model.
>>>> >> >>>
>>>> >> >>> eg:
>>>> >> >>>
>>>> >> >>>         TopologyConfig config =
>>>> FasterLookUpDataHolder.getInstance()
>>>> >> >>>                 .getTopologyConfig();
>>>> >> >>>         String cron =
>>>> config.getProperty(CloudControllerConstants.CRON_ELEMENT);
>>>> >> >>>
>>>> >> >>> With this extension point in hand, you can easily make
Cloud
>>>> Controller to publish topology information into another topic provider
>>>> (Qpid etc.).
>>>> >> >>>
>>>> >> >>> I invite you to leverage this capability and help Apache
Stratos
>>>> to be compatible with other message broker implementations.
>>>> >> >>>
>>>> >> >>> Thanks.
>>>> >> >>>
>>>> >> >>> PS: We need the same kind of extensibility in the subscriber
>>>> side. I will have a look on to it too.
>>>> >> >>>
>>>> >> >>> --
>>>> >> >>> Best Regards,
>>>> >> >>> Nirmal
>>>> >> >>>
>>>> >> >>> C.S.Nirmal J. Fernando
>>>> >> >>> Senior Software Engineer,
>>>> >> >>> WSO2 Inc.
>>>> >> >>>
>>>> >> >>> Blog: http://nirmalfdo.blogspot.com/
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >> --
>>>> >> >> Isuru Perera
>>>> >> >> about.me/chrishantha
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > --
>>>> >> > Isuru Perera
>>>> >> > about.me/chrishantha
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Isuru Perera
>>>> > about.me/chrishantha
>>>>
>>>
>>>
>>>
>>> --
>>> Isuru Perera
>>> about.me/chrishantha
>>>
>>
>>
>>
>> --
>> Best Regards,
>> Nirmal
>>
>> C.S.Nirmal J. Fernando
>> Senior Software Engineer,
>> WSO2 Inc.
>>
>> Blog: http://nirmalfdo.blogspot.com/
>>
>
>
>
> --
> Isuru Perera
> about.me/chrishantha
>



-- 
Best Regards,
Nirmal

C.S.Nirmal J. Fernando
Senior Software Engineer,
WSO2 Inc.

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

Mime
View raw message