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