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