You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Isuru Haththotuwa <is...@apache.org> on 2015/11/13 09:33:15 UTC
Updates done to CC configuration does not get reflected in spinning
new instances
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/>*
Re: Updates done to CC configuration does not get reflected in
spinning new instances
Posted by Isuru Haththotuwa <is...@apache.org>.
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 <is...@apache.org>
wrote:
> Hi Akila,
>
> Thanks for the suggestion.
>
> On Wed, Nov 18, 2015 at 12:15 AM, Akila Ravihansa Perera <
> ravihansa@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 <is...@apache.org>
>> wrote:
>>
>>> Hi Akila,
>>>
>>> On Mon, Nov 16, 2015 at 11:41 AM, Akila Ravihansa Perera <
>>> ravihansa@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 <is...@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 <
>>>>> anuruddhal@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 <isuruh@apache.org
>>>>>> > wrote:
>>>>>>
>>>>>>> Hi Akila,
>>>>>>>
>>>>>>> On Fri, Nov 13, 2015 at 4:04 PM, Akila Ravihansa Perera <
>>>>>>> ravihansa@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 <
>>>>>>> isuruh@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 <th...@wso2.com>nuruddhal@wso2.com
>>>>>>
>>>>>> --
>>>>>> <nu...@wso2.com>
>>>>>> <nu...@wso2.com>
>>>>>> Thanks and Regards,
>>>>>>
>>>>>> Isuru H.
>>>>>> <nu...@wso2.com>
>>>>>> +94 716 358 048 <nu...@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/>*
Re: Updates done to CC configuration does not get reflected in
spinning new instances
Posted by Isuru Haththotuwa <is...@apache.org>.
Hi Akila,
Thanks for the suggestion.
On Wed, Nov 18, 2015 at 12:15 AM, Akila Ravihansa Perera <ravihansa@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 <is...@apache.org>
> wrote:
>
>> Hi Akila,
>>
>> On Mon, Nov 16, 2015 at 11:41 AM, Akila Ravihansa Perera <
>> ravihansa@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 <is...@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 <
>>>> anuruddhal@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 <is...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Hi Akila,
>>>>>>
>>>>>> On Fri, Nov 13, 2015 at 4:04 PM, Akila Ravihansa Perera <
>>>>>> ravihansa@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 <isuruh@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 <th...@wso2.com>nuruddhal@wso2.com
>>>>>
>>>>> --
>>>>> <nu...@wso2.com>
>>>>> <nu...@wso2.com>
>>>>> Thanks and Regards,
>>>>>
>>>>> Isuru H.
>>>>> <nu...@wso2.com>
>>>>> +94 716 358 048 <nu...@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/>*
>
>
>
Re: Updates done to CC configuration does not get reflected in
spinning new instances
Posted by Akila Ravihansa Perera <ra...@wso2.com>.
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?
Thanks.
On Mon, Nov 16, 2015 at 11:51 AM, Isuru Haththotuwa <is...@apache.org>
wrote:
> Hi Akila,
>
> On Mon, Nov 16, 2015 at 11:41 AM, Akila Ravihansa Perera <
> ravihansa@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 <is...@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 <
>>> anuruddhal@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 <is...@apache.org>
>>>> wrote:
>>>>
>>>>> Hi Akila,
>>>>>
>>>>> On Fri, Nov 13, 2015 at 4:04 PM, Akila Ravihansa Perera <
>>>>> ravihansa@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 <is...@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 <th...@wso2.com>nuruddhal@wso2.com
>>>>
>>>> --
>>>> <nu...@wso2.com>
>>>> <nu...@wso2.com>
>>>> Thanks and Regards,
>>>>
>>>> Isuru H.
>>>> <nu...@wso2.com>
>>>> +94 716 358 048 <nu...@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
Re: Updates done to CC configuration does not get reflected in
spinning new instances
Posted by Isuru Haththotuwa <is...@apache.org>.
Hi Akila,
On Mon, Nov 16, 2015 at 11:41 AM, Akila Ravihansa Perera <ravihansa@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 <is...@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 <
>> anuruddhal@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 <is...@apache.org>
>>> wrote:
>>>
>>>> Hi Akila,
>>>>
>>>> On Fri, Nov 13, 2015 at 4:04 PM, Akila Ravihansa Perera <
>>>> ravihansa@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 <is...@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 <th...@wso2.com>nuruddhal@wso2.com
>>>
>>> --
>>> <nu...@wso2.com>
>>> <nu...@wso2.com>
>>> Thanks and Regards,
>>>
>>> Isuru H.
>>> <nu...@wso2.com>
>>> +94 716 358 048 <nu...@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/>*
>
>
>
Re: Updates done to CC configuration does not get reflected in
spinning new instances
Posted by Akila Ravihansa Perera <ra...@wso2.com>.
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.
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.
Thanks.
On Mon, Nov 16, 2015 at 10:40 AM, Isuru Haththotuwa <is...@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 <
> anuruddhal@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 <is...@apache.org>
>> wrote:
>>
>>> Hi Akila,
>>>
>>> On Fri, Nov 13, 2015 at 4:04 PM, Akila Ravihansa Perera <
>>> ravihansa@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 <is...@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 <th...@wso2.com>nuruddhal@wso2.com
>>
>> --
>> <nu...@wso2.com>
>> <nu...@wso2.com>
>> Thanks and Regards,
>>
>> Isuru H.
>> <nu...@wso2.com>
>> +94 716 358 048 <nu...@wso2.com>* <http://wso2.com/>*
>>
>>
>> * <http://wso2.com/>*
>>
>>
>>
--
Akila Ravihansa Perera
WSO2 Inc.; http://wso2.com/
Blog: http://ravihansa3000.blogspot.com
Re: Updates done to CC configuration does not get reflected in
spinning new instances
Posted by Isuru Haththotuwa <is...@apache.org>.
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 <
anuruddhal@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 <is...@apache.org>
> wrote:
>
>> Hi Akila,
>>
>> On Fri, Nov 13, 2015 at 4:04 PM, Akila Ravihansa Perera <
>> ravihansa@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 <is...@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 <th...@wso2.com>nuruddhal@wso2.com
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048* <http://wso2.com/>*
>
>
> * <http://wso2.com/>*
>
>
>
Re: Updates done to CC configuration does not get reflected in
spinning new instances
Posted by Anuruddha Liyanarachchi <an...@wso2.com>.
>
> 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 <is...@apache.org>
wrote:
> Hi Akila,
>
> On Fri, Nov 13, 2015 at 4:04 PM, Akila Ravihansa Perera <
> ravihansa@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 <is...@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 <th...@wso2.com>nuruddhal@wso2.com
Re: Updates done to CC configuration does not get reflected in
spinning new instances
Posted by Isuru Haththotuwa <is...@apache.org>.
Hi Akila,
On Fri, Nov 13, 2015 at 4:04 PM, Akila Ravihansa Perera <ra...@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 <is...@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/>*
Re: Updates done to CC configuration does not get reflected in
spinning new instances
Posted by Akila Ravihansa Perera <ra...@wso2.com>.
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?
Thanks.
On Fri, Nov 13, 2015 at 2:03 PM, Isuru Haththotuwa <is...@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