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/>*