On Sat, Nov 16, 2013 at 10:10 AM, Nirmal Fernando <[email protected]>wrote:

>
>
>
> On Sat, Nov 16, 2013 at 9:59 AM, Lahiru Sandaruwan <[email protected]>wrote:
>
>> Ah.. We had a lot of discussions with you, Lakmal, Imesh, and Reka. What
>> i had my mind was the final outcome. Sorry that i didn't remember...
>>
>> Anyway let's discuss the best solution here... :)
>>
>> On Sat, Nov 16, 2013 at 9:31 AM, Nirmal Fernando 
>> <[email protected]>wrote:
>>
>>> I brought the same concern out, in an offline discussion with you, since
>>> cloud-controller no more decides the information on where the instance
>>> would get spawned, it is best to keep those information in Autoscaler.
>>>
>>> Please come up with a two separate config files and let's discuss them
>>> here and come to a consensus.
>>>
>>
>> You mean the cartridge.xml and partition.xml ?
>>
>
>> I think cartridge.xml can be kept in the cloud controller.
>>
>
> Yes.
>
>>
>>> Hint: You should think carefully, how to map these two effectively. :)
>>>
>>
>> I felt like we do not need a mapping here. Do we?
>> Basically cartridge.xml is having account details of IaaS providers,
>> instance types etc(what we had before).
>>
>> partition.xml is defined in Autoscaler side and when the Autoscaler
>> decides to spawn/ terminate instance, it will pass the complete "Partition"
>> object with the request to cloud controller.
>>
>> Then CC just get the information and do the needful.
>>
>
> Well, who selects the IaaS? It's the Autoscaler, right? In Cartridge
> definition, you map image ids etc, per IaaS basis. Hence, you need a
> mapping.
>

Yes, Of course we need a validation when the partition.xml is deployed. We
have to check whether the defined IaaSes, Zones etc. actually there in the
IaaS. We can have a simple API from CC for this. Autoscaler pass the
"Partition" object and get it validated.

So after the deployment, what Autoscaler see is just a set of partitions
and it takes decision on them.

Thanks.

>
>> WDYT?
>>
>> Thanks.
>>
>>
>>
>>>
>>>
>>>
>>> On Sat, Nov 16, 2013 at 12:51 AM, Lahiru Sandaruwan <[email protected]>wrote:
>>>
>>>> Hi all,
>>>>
>>>> I've been thinking on the cloud partitions definition in the system.
>>>> Currently we plan to define them in Cloud Controller config and then in the
>>>> cartridge.xml as Reka also explained above.
>>>> In this design, we have to use a cartridge.xml if we want to hot
>>>> deploy. Also the new partition definition is limited to that cartridge.
>>>>
>>>> In a second thought i though of following design,
>>>>
>>>> Define cloud partitions in a separate xml file which is hot deployable
>>>> inside Autoscaler. Then the 'partition' object is passed to Cloud
>>>> Controller which has all the details to spwan the instance in correct
>>>> partition.
>>>>
>>>> Here are the advantages over current plan.
>>>>
>>>>
>>>>    - Definitions of cloud partitions are used in Autoscaler for making
>>>>    the decision on the capacity planing and the deployment pattern.
>>>>    - This will remove following limitation from the current design.
>>>>
>>>> Defined partition will be limited to a particular cartridge as we
>>>> define it in a cartridge.xml in the current design.
>>>>
>>>>    - Here, all the partition definitions are deployed by the dev-op
>>>>    role(or equal) of the client. So there is no point of limiting a 
>>>> partition
>>>>    definition to a particular cartridge.
>>>>
>>>> Thoughts please.
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Nov 12, 2013 at 12:40 PM, Reka Thirunavukkarasu 
>>>> <[email protected]>wrote:
>>>>
>>>>> Reka, it's good that you followed the same pattern we had in Cartridge
>>>>> design. It's best if you can generate the XSD and validate the definition,
>>>>> if not already done.
>>>>> +1. Will generate and validate against XSD.
>>>>>
>>>>>>
>>>>>> Question:
>>>>>>
>>>>>> * Why we need both type and id?
>>>>>>
>>>>> "id" introduced for a readability purpose. If it is redundant, then we
>>>>> can get rid of the id and go ahead with the type.
>>>>>
>>>>>
>>>>>> * How the policy file and cartridge definition relates? Should one
>>>>>> configure policy file and cartridge definition together?
>>>>>>
>>>>>  Yah. Devop need to configure cartridge definition as well as the
>>>>> policy file together. But still, according to my understanding, policy 
>>>>> file
>>>>> can be generic and independent from the cartridge definition. In this 
>>>>> case,
>>>>> we might not able to apply all the policies to all the cartridge
>>>>> definition. So, it is Stratos Manger's responsibility to validate the
>>>>> cartridge definition against the policy files and display the applicable
>>>>> list of policies to a cartridge.
>>>>>
>>>>> Thanks,
>>>>> Reka
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Reka
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Reka Thirunavukkarasu
>>>>>>> Software Engineer,
>>>>>>> WSO2, Inc.:http://wso2.com,
>>>>>>> Mobile: +94776442007
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best Regards,
>>>>>> Nirmal
>>>>>>
>>>>>> Nirmal Fernando.
>>>>>> PPMC Member & Committer of Apache Stratos,
>>>>>> Senior Software Engineer, WSO2 Inc.
>>>>>>
>>>>>> Blog: http://nirmalfdo.blogspot.com/
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Reka Thirunavukkarasu
>>>>> Software Engineer,
>>>>> WSO2, Inc.:http://wso2.com,
>>>>> Mobile: +94776442007
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> --
>>>> Lahiru Sandaruwan
>>>> Software Engineer,
>>>> Platform Technologies,
>>>> WSO2 Inc., http://wso2.com
>>>> lean.enterprise.middleware
>>>>
>>>> email: [email protected] cell: (+94) 773 325 954
>>>> blog: http://lahiruwrites.blogspot.com/
>>>> twitter: http://twitter.com/lahirus
>>>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>>>
>>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> Nirmal
>>>
>>> Nirmal Fernando.
>>> PPMC Member & Committer of Apache Stratos,
>>> Senior Software Engineer, WSO2 Inc.
>>>
>>> Blog: http://nirmalfdo.blogspot.com/
>>>
>>
>>
>>
>> --
>> --
>> Lahiru Sandaruwan
>> Software Engineer,
>> Platform Technologies,
>> WSO2 Inc., http://wso2.com
>> lean.enterprise.middleware
>>
>> email: [email protected] cell: (+94) 773 325 954
>> blog: http://lahiruwrites.blogspot.com/
>> twitter: http://twitter.com/lahirus
>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>
>>
>
>
> --
> Best Regards,
> Nirmal
>
> Nirmal Fernando.
> PPMC Member & Committer of Apache Stratos,
> Senior Software Engineer, WSO2 Inc.
>
> Blog: http://nirmalfdo.blogspot.com/
>



-- 
--
Lahiru Sandaruwan
Software Engineer,
Platform Technologies,
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

email: [email protected] cell: (+94) 773 325 954
blog: http://lahiruwrites.blogspot.com/
twitter: http://twitter.com/lahirus
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146

Reply via email to