Committed an integration test to verify the scenario of IaaS properties
getting properly picked and overridden when spawning instances. Commit
ids: 28e65f2bf9c9b2f8f62173160b773368ac3b88f1
and 516609907b76b0078c0b0eef0c768793a8239720.
On Wed, Nov 18, 2015 at 9:27 AM, Isuru Haththotuwa <isu...@apache.org>
wrote:
> Hi Akila,
>
> Thanks for the suggestion.
>
> On Wed, Nov 18, 2015 at 12:15 AM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Isuru,
>>
>> I'm seeing the following log continously;
>>
>> INFO {org.apache.stratos.cloud.controller.context.CloudControllerContext}
>> - New IaaSProvider object is equal to the cached one, no need to re-build
>>
>> Shall we print a log for cached object unequal to new one case in which
>> re-build will take place. Because two objects being equal will be the most
>> common case, and this looks verbose. wdyt?
>>
> A log is already there for the re-building. I have changed log level of
> the above message to debug.
>
>>
>> Thanks.
>>
>> On Mon, Nov 16, 2015 at 11:51 AM, Isuru Haththotuwa <isu...@apache.org>
>> wrote:
>>
>>> Hi Akila,
>>>
>>> On Mon, Nov 16, 2015 at 11:41 AM, Akila Ravihansa Perera <
>>> raviha...@wso2.com> wrote:
>>>
>>>> Hi Isuru,
>>>>
>>>> Shall we compare the cached IaasProvider object with latest values
>>>> before building the jclouds template as an improvement? This will avoid
>>>> unnecessary API calls to build the object.
>>>>
>>> +1, excellent suggestion.
>>>
>>>>
>>>> Also we will have to check the cached objects at Stratos server startup
>>>> and build forcefully if there are changes to cloud-controller.xml IaaS
>>>> properties.
>>>>
>>> IMHO we do not have to do this at startup. At instance startup we can do
>>> the same, and then if there are no changes to the object, we do not have to
>>> build again.
>>>
>>>>
>>>> Thanks.
>>>>
>>>> On Mon, Nov 16, 2015 at 10:40 AM, Isuru Haththotuwa <isu...@apache.org>
>>>> wrote:
>>>>
>>>>> One limitation of this approach is that JClouds will do a API call to
>>>>> validate the information that is provided to build the template each when
>>>>> spawning an instance. But, since we are re-doing it only at instance
>>>>> startup, IMHO it should not be a issue. Please share your thoughts.
>>>>>
>>>>> On Mon, Nov 16, 2015 at 10:27 AM, Anuruddha Liyanarachchi <
>>>>> anurudd...@wso2.com> wrote:
>>>>>
>>>>>> Building new IaasProvider objects is done when there is a need to
>>>>>>> spawn instances. Then the new IaasProvider object is cached. So the
>>>>>>> cache would not be re-built when the CC is restarted, but only when
>>>>>>> instances are actually getting spawned. The main reason for
>>>>>>> approach is that a cartridge validation/network partition validation can
>>>>>>> happen at anytime; so if we build the IaasProvider before starting an
>>>>>>> instance, we can use all the updates available from
>>>>>>> cloud-controller.xml, policies and cartridgde definitions. WDYT?
>>>>>>
>>>>>>
>>>>>> +1.
>>>>>> This will also resolve the issue; having to delete and recreate
>>>>>> application, each time cartridge is updated.
>>>>>>
>>>>>> On Fri, Nov 13, 2015 at 4:44 PM, Isuru Haththotuwa <isu...@apache.org
>>>>>> > wrote:
>>>>>>
>>>>>>> Hi Akila,
>>>>>>>
>>>>>>> On Fri, Nov 13, 2015 at 4:04 PM, Akila Ravihansa Perera <
>>>>>>> raviha...@wso2.com> wrote:
>>>>>>>
>>>>>>>> Hi Isuru,
>>>>>>>>
>>>>>>>> Yes, this has been a troublesome experience for users when updating
>>>>>>>> CC configs. I've few concerns;
>>>>>>>>
>>>>>>>> - What if cartridge definition is updated after caching the built
>>>>>>>> IaaSProvider object?
>>>>>>>> - Is the cache is getting invalidated if cartridge definition is
>>>>>>>> updated?
>>>>>>>> - Is the whole cache re-built when Stratos is restarted? Otherwise
>>>>>>>> CC config changes won't take effect ryt?
>>>>>>>>
>>>>>>> Building new IaasProvider objects is done when there is a need to
>>>>>>> spawn instances. Then the new IaasProvider object is cached. So the
>>>>>>> cache
>>>>>>> would not be re-built when the CC is restarted, but only when instances
>>>>>>> are
>>>>>>> actually getting spawned. The main reason for approach is that a
>>>>>>> cartridge
>>>>>>> validation/network partition validation can happen at anytime; so if we
>>>>>>> build the IaasProvider before starting an instance, we can use all the
>>>>>>> updates available from cloud-controller.xml, policies and cartridgde
>>>>>>> definitions. WDYT?
>>>>>>> Thanks.
>>>>>>>
>>>>>>> On Fri, Nov 13, 2015 at 2:03 PM, Isuru Haththotuwa <
>>>>>>> isu...@apache.org> wrote:
>>>>>>>
>>>>>>>> Hi Devs,
>>>>>>>>
>>>>>>>> $subject.
>>>>>>>>
>>>>>>>> This is happening because after initial information model is built
>>>>>>>> (IaasProvider object), it does not get re-built to detect any changes.
>>>>>>>> The
>>>>>>>> mail thread [1] also describes a similar issue, where if we do not
>>>>>>>> specify
>>>>>>>> image id in cloud-controller.xml, the instance not spawning in the
>>>>>>>> selected
>>>>>>>> partition.
>>>>>>>>
>>>>>>>> As a fix we can do the following:
>>>>>>>>
>>>>>>>> - When an instance need to be spawned, build a new IaasProvider
>>>>>>>> object with the latest available configurations, and the caching
>>>>>>>> the object
>>>>>>>> in the maps
>>>>>>>> - Consider the following order in building the IaasProvider
>>>>>>>> object:
>>>>>>>> 1. IaaS provider information defined in cloud-controller.xml
>>>>>>>> 2. IaaS provider information defined in cartridge definition
>>>>>>>>
>>>>>>>> This ordering will ensure that any information defined in the
>>>>>>>> cloud-controller.xml can be overridden by information in the cartridge
>>>>>>>> definition.
>>>>>>>>
>>>>>>>> WDYT?
>>>>>>>> [1]. [EC2] Removing the Image Id from CC Results in instances
>>>>>>>> Spinning in Wrong Zones
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thanks and Regards,
>>>>>>>>
>>>>>>>> Isuru H.
>>>>>>>> +94 716 358 048* <http://wso2.com/>*
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Akila Ravihansa Perera
>>>>>>> WSO2 Inc.; http://wso2.com/
>>>>>>>
>>>>>>> Blog: http://ravihansa3000.blogspot.com
>>>>>>>
>>>>>>> --
>>>>>>> <http://ravihansa3000.blogspot.com>
>>>>>>> <http://ravihansa3000.blogspot.com>
>>>>>>> Thanks and Regards,
>>>>>>>
>>>>>>> Isuru H.
>>>>>>> <http://ravihansa3000.blogspot.com>
>>>>>>> +94 716 358 048 <http://ravihansa3000.blogspot.com>*
>>>>>>> <http://wso2.com/>*
>>>>>>>
>>>>>>>
>>>>>>> * <http://wso2.com/>*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Thanks and Regards,*
>>>>>> Anuruddha Lanka Liyanarachchi
>>>>>> Software Engineer - WSO2
>>>>>> Mobile : +94 (0) 712762611
>>>>>> Tel : +94 112 145 345
>>>>>> a <thili...@wso2.com>nurudd...@wso2.com
>>>>>>
>>>>>> --
>>>>>> <nurudd...@wso2.com>
>>>>>> <nurudd...@wso2.com>
>>>>>> Thanks and Regards,
>>>>>>
>>>>>> Isuru H.
>>>>>> <nurudd...@wso2.com>
>>>>>> +94 716 358 048 <nurudd...@wso2.com>* <http://wso2.com/>*
>>>>>>
>>>>>>
>>>>>> * <http://wso2.com/>*
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Akila Ravihansa Perera
>>>> WSO2 Inc.; http://wso2.com/
>>>>
>>>> Blog: http://ravihansa3000.blogspot.com
>>>>
>>>> --
>>>> <http://ravihansa3000.blogspot.com>
>>>> <http://ravihansa3000.blogspot.com>
>>>> Thanks and Regards,
>>>>
>>>> Isuru H.
>>>> <http://ravihansa3000.blogspot.com>
>>>> +94 716 358 048 <http://ravihansa3000.blogspot.com>*
>>>> <http://wso2.com/>*
>>>>
>>>>
>>>> * <http://wso2.com/>*
>>>>
>>>>
>>>>
>>
>>
>> --
>> Akila Ravihansa Perera
>> WSO2 Inc.; http://wso2.com/
>>
>> Blog: http://ravihansa3000.blogspot.com
>>
>> --
>> <http://ravihansa3000.blogspot.com>
>> <http://ravihansa3000.blogspot.com>
>> Thanks and Regards,
>>
>> Isuru H.
>> <http://ravihansa3000.blogspot.com>
>> +94 716 358 048 <http://ravihansa3000.blogspot.com>* <http://wso2.com/>*
>>
>>
>> * <http://wso2.com/>*
>>
>>
>>
--
Thanks and Regards,
Isuru H.
+94 716 358 048* <http://wso2.com/>*
