Hi Devs,

I have almost completed refactoring the publisher classes. Current publisher class structure is shown below:


As next step I'm going to modify thrift-client-config.xml so that thrift configuration for CEP and DAS can be read from the same file. Also I plan to set InstanceMetadata for Mock and Kubernetes IaaS since currently they don't have them. During the next week I'm going to work on this two tasks.

This is the progress summary on $subject.

TaskStatus
1Integrating DAS for MeteringIn-Progress
1.1 Creating Publisher classes to publish member_info, member_status and scaling_decisionsCompleted
1.2 Publishing member info data from Stratos to DASCompleted
1.3 Publishing member status data from Stratos to DASCompleted
1.4 Publishing scaling decisions from Stratos to DASIn-progress
1.5 Adding DAS artifacts to persist data in DASCompleted
2Refactoring thrift client configuration and thrift publisher
3Setting InstanceMetadata for Mock IaaS
4Setting InstanceMetadata for Kubernetes IaaS

Once the first task completed, I will send a P/R for the changes.

Thanks.

On Tue, Aug 4, 2015 at 1:03 PM, Thanuja Uruththirakodeeswaran <thanujau@wso2.com> wrote:
Hi Reka,

Yes, It's true that we don't need different factory classes for each publisher class. We will have a publisher factory class per component and use that for creating different publishers within the component as we discussed.

Thank you.

On Tue, Aug 4, 2015 at 12:02 PM, Reka Thirunavukkarasu <reka@wso2.com> wrote:
Hi Thanuja,

The decision to create different types of data publisher based on ThriftStatisticsPublisher is good. In that way, we can create own publishers with different streams as we need. I'm having few concerns on the factory classes here. Why do we need to have different factory classes to create datapublsihers? Also in order to just to create one type of data publisher, do we need to use factory class?

Thanks,
Reka

On Tue, Aug 4, 2015 at 11:01 AM, Thanuja Uruththirakodeeswaran <thanujau@wso2.com> wrote:
Hi Devs,

I have started to work on $subject. For the metering service,

1. I'm going to use three different streams which are member_lifecycle, member_info and scaling_decisions as discussed in the review. The streams will have attributes as mentioned below:
  • member_lifecycle: time_stamp, member_id, cluster_id, cluster_instance_id, network_partition_id, partition_id, service_name, status
  • member_info: memberId, hostname, hypervisor, cpu, ram, iaas, imageId, instance_type, login_port, os_name;os_version, is_os_64bit, scaling_id, is_multi_tenant, private_ip, public_ip, allocated_ips
  • scaling_decision: time_stamp, scaling_id, cluster_id, min_instance_count, max_instance_count, rif_predicted, rif_threshold, rif_required_instances, mc_predicted, mc_threshold, mc_required_instances, la_predicted, la_threshold, la_required_instances, required_instance_count, active_instance_count, additional_instance_count, scaling_reason
2. Also I'm going to use three publisher classes: DASMemberStatusPublisher, DASMemberInformationPublisher and DASScalingDecisionPublisher instead of using a single class (BAMUsageDataPublisher) as shown below: (Here I've renamed WSO2CEPStatisticsPublisher to ThriftStatisticsPublisher)


3. Instead of reading uname, pwrod form cloud-controller.xml, I'm going to use das-thrift-client-config.xml file and renaming the existing thrift-client-config.xml file to cep-thrift-client-config.xml.

Please share your thoughts about this implementation.

Thank you.
​​
--
Thanuja Uruththirakodeeswaran
Software Engineer
WSO2 Inc.;http://wso2.com
lean.enterprise.middleware




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





--
Thanuja Uruththirakodeeswaran
Software Engineer
WSO2 Inc.;http://wso2.com
lean.enterprise.middleware




--
Thanuja Uruththirakodeeswaran
Software Engineer
WSO2 Inc.;http://wso2.com
lean.enterprise.middleware

mobile: +94 774363167