You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Imesh Gunaratne <im...@apache.org> on 2015/01/01 21:51:58 UTC
[Discuss] Refining Autoscaler/Cloud Controller Communication
Hi Devs,
This is to discuss $subject. As we found in other mail threads, there is a
fundamental problem in the logic how Autoscaler/Cloud Controller
communication is done in terms of managing the lifecycle of the members.
This problem only affects in certain scenarios when members do not start as
expected.
*InstanceSpawnedEvent:*
Above problem starts with this event: This event name implies that it
should be published soon after instance is spawned by the IaaS. However it
has properties to send IP addresses. These requirements conflicts, IP
addresses will only be available after certain time period once the
instance is spawned.
Inaddition to the above conflicting requirements, Python Agent waits for
this event to initialize the agent instance. If this event is sent soon
after the instance is spawned there is not possibility that agent could
receive this event.
One other problem is that we have used a convention when naming events in
Instance Status topic. All the events under Instance Status topic starts
with the term "Instance" and all corresponding events in the topology topic
starts with the term "Member".
Due to above reasons I think we could introduce two events called
"Member-Created" and "Member-Initialized" as follows:
Thanks
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: [Discuss] Refining Autoscaler/Cloud Controller Communication
Posted by Imesh Gunaratne <im...@apache.org>.
Docker images *stratos/base-image:4.1.0-alpha* and
*stratos/php:4.1.0-alpha* are
now updated in Docker Hub. I'm now investigating health statistics
publishing issue in agent.
Thanks
On Fri, Jan 2, 2015 at 11:10 AM, Imesh Gunaratne <im...@apache.org> wrote:
> With the above change *stratos/php:4.1.0-alpha* docker image in Docker
> Hub has been invalidated, I'm now updating the agent and creating the php
> image again.
>
> Thanks
>
> On Fri, Jan 2, 2015 at 3:30 AM, Imesh Gunaratne <im...@apache.org> wrote:
>
>> I have now done the initial changes to introduce above member events and
>> pushed changes to master branch:
>>
>> - Introduced new events Member-Created and Member-Initialized
>> - Updated messaging component accordingly
>> - Moved member IP addresses properties to Member-Initialized event
>> - Updated Python Agent to initialize its state based on
>> Member-Initialized event
>> - Updated cloud controller logic to terminate the member if member
>> creation process fails in the middle.
>> - Verified mock iaas single-cartridge sample with the above changes.
>>
>> Thanks
>>
>> On Fri, Jan 2, 2015 at 2:27 AM, Imesh Gunaratne <im...@apache.org> wrote:
>>
>>> s/there is not possibility/there is no possibility/g
>>>
>>> On Fri, Jan 2, 2015 at 2:21 AM, Imesh Gunaratne <im...@apache.org>
>>> wrote:
>>>
>>>> Hi Devs,
>>>>
>>>> This is to discuss $subject. As we found in other mail threads, there
>>>> is a fundamental problem in the logic how Autoscaler/Cloud Controller
>>>> communication is done in terms of managing the lifecycle of the members.
>>>> This problem only affects in certain scenarios when members do not start as
>>>> expected.
>>>>
>>>> *InstanceSpawnedEvent:*
>>>> Above problem starts with this event: This event name implies that it
>>>> should be published soon after instance is spawned by the IaaS. However it
>>>> has properties to send IP addresses. These requirements conflicts, IP
>>>> addresses will only be available after certain time period once the
>>>> instance is spawned.
>>>>
>>>> Inaddition to the above conflicting requirements, Python Agent waits
>>>> for this event to initialize the agent instance. If this event is sent soon
>>>> after the instance is spawned there is not possibility that agent could
>>>> receive this event.
>>>>
>>>> One other problem is that we have used a convention when naming events
>>>> in Instance Status topic. All the events under Instance Status topic starts
>>>> with the term "Instance" and all corresponding events in the topology topic
>>>> starts with the term "Member".
>>>>
>>>> Due to above reasons I think we could introduce two events called
>>>> "Member-Created" and "Member-Initialized" as follows:
>>>>
>>>>
>>>> Thanks
>>>>
>>>>
>>>>
>>>> --
>>>> Imesh Gunaratne
>>>>
>>>> Technical Lead, WSO2
>>>> Committer & PMC Member, Apache Stratos
>>>>
>>>
>>>
>>>
>>> --
>>> Imesh Gunaratne
>>>
>>> Technical Lead, WSO2
>>> Committer & PMC Member, Apache Stratos
>>>
>>
>>
>>
>> --
>> Imesh Gunaratne
>>
>> Technical Lead, WSO2
>> Committer & PMC Member, Apache Stratos
>>
>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: [Discuss] Refining Autoscaler/Cloud Controller Communication
Posted by Imesh Gunaratne <im...@apache.org>.
With the above change *stratos/php:4.1.0-alpha* docker image in Docker Hub
has been invalidated, I'm now updating the agent and creating the php image
again.
Thanks
On Fri, Jan 2, 2015 at 3:30 AM, Imesh Gunaratne <im...@apache.org> wrote:
> I have now done the initial changes to introduce above member events and
> pushed changes to master branch:
>
> - Introduced new events Member-Created and Member-Initialized
> - Updated messaging component accordingly
> - Moved member IP addresses properties to Member-Initialized event
> - Updated Python Agent to initialize its state based on Member-Initialized
> event
> - Updated cloud controller logic to terminate the member if member
> creation process fails in the middle.
> - Verified mock iaas single-cartridge sample with the above changes.
>
> Thanks
>
> On Fri, Jan 2, 2015 at 2:27 AM, Imesh Gunaratne <im...@apache.org> wrote:
>
>> s/there is not possibility/there is no possibility/g
>>
>> On Fri, Jan 2, 2015 at 2:21 AM, Imesh Gunaratne <im...@apache.org> wrote:
>>
>>> Hi Devs,
>>>
>>> This is to discuss $subject. As we found in other mail threads, there is
>>> a fundamental problem in the logic how Autoscaler/Cloud Controller
>>> communication is done in terms of managing the lifecycle of the members.
>>> This problem only affects in certain scenarios when members do not start as
>>> expected.
>>>
>>> *InstanceSpawnedEvent:*
>>> Above problem starts with this event: This event name implies that it
>>> should be published soon after instance is spawned by the IaaS. However it
>>> has properties to send IP addresses. These requirements conflicts, IP
>>> addresses will only be available after certain time period once the
>>> instance is spawned.
>>>
>>> Inaddition to the above conflicting requirements, Python Agent waits for
>>> this event to initialize the agent instance. If this event is sent soon
>>> after the instance is spawned there is not possibility that agent could
>>> receive this event.
>>>
>>> One other problem is that we have used a convention when naming events
>>> in Instance Status topic. All the events under Instance Status topic starts
>>> with the term "Instance" and all corresponding events in the topology topic
>>> starts with the term "Member".
>>>
>>> Due to above reasons I think we could introduce two events called
>>> "Member-Created" and "Member-Initialized" as follows:
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> --
>>> Imesh Gunaratne
>>>
>>> Technical Lead, WSO2
>>> Committer & PMC Member, Apache Stratos
>>>
>>
>>
>>
>> --
>> Imesh Gunaratne
>>
>> Technical Lead, WSO2
>> Committer & PMC Member, Apache Stratos
>>
>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: [Discuss] Refining Autoscaler/Cloud Controller Communication
Posted by Imesh Gunaratne <im...@apache.org>.
I have now done the initial changes to introduce above member events and
pushed changes to master branch:
- Introduced new events Member-Created and Member-Initialized
- Updated messaging component accordingly
- Moved member IP addresses properties to Member-Initialized event
- Updated Python Agent to initialize its state based on Member-Initialized
event
- Updated cloud controller logic to terminate the member if member creation
process fails in the middle.
- Verified mock iaas single-cartridge sample with the above changes.
Thanks
On Fri, Jan 2, 2015 at 2:27 AM, Imesh Gunaratne <im...@apache.org> wrote:
> s/there is not possibility/there is no possibility/g
>
> On Fri, Jan 2, 2015 at 2:21 AM, Imesh Gunaratne <im...@apache.org> wrote:
>
>> Hi Devs,
>>
>> This is to discuss $subject. As we found in other mail threads, there is
>> a fundamental problem in the logic how Autoscaler/Cloud Controller
>> communication is done in terms of managing the lifecycle of the members.
>> This problem only affects in certain scenarios when members do not start as
>> expected.
>>
>> *InstanceSpawnedEvent:*
>> Above problem starts with this event: This event name implies that it
>> should be published soon after instance is spawned by the IaaS. However it
>> has properties to send IP addresses. These requirements conflicts, IP
>> addresses will only be available after certain time period once the
>> instance is spawned.
>>
>> Inaddition to the above conflicting requirements, Python Agent waits for
>> this event to initialize the agent instance. If this event is sent soon
>> after the instance is spawned there is not possibility that agent could
>> receive this event.
>>
>> One other problem is that we have used a convention when naming events in
>> Instance Status topic. All the events under Instance Status topic starts
>> with the term "Instance" and all corresponding events in the topology topic
>> starts with the term "Member".
>>
>> Due to above reasons I think we could introduce two events called
>> "Member-Created" and "Member-Initialized" as follows:
>>
>>
>> Thanks
>>
>>
>>
>> --
>> Imesh Gunaratne
>>
>> Technical Lead, WSO2
>> Committer & PMC Member, Apache Stratos
>>
>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: [Discuss] Refining Autoscaler/Cloud Controller Communication
Posted by Imesh Gunaratne <im...@apache.org>.
s/there is not possibility/there is no possibility/g
On Fri, Jan 2, 2015 at 2:21 AM, Imesh Gunaratne <im...@apache.org> wrote:
> Hi Devs,
>
> This is to discuss $subject. As we found in other mail threads, there is a
> fundamental problem in the logic how Autoscaler/Cloud Controller
> communication is done in terms of managing the lifecycle of the members.
> This problem only affects in certain scenarios when members do not start as
> expected.
>
> *InstanceSpawnedEvent:*
> Above problem starts with this event: This event name implies that it
> should be published soon after instance is spawned by the IaaS. However it
> has properties to send IP addresses. These requirements conflicts, IP
> addresses will only be available after certain time period once the
> instance is spawned.
>
> Inaddition to the above conflicting requirements, Python Agent waits for
> this event to initialize the agent instance. If this event is sent soon
> after the instance is spawned there is not possibility that agent could
> receive this event.
>
> One other problem is that we have used a convention when naming events in
> Instance Status topic. All the events under Instance Status topic starts
> with the term "Instance" and all corresponding events in the topology topic
> starts with the term "Member".
>
> Due to above reasons I think we could introduce two events called
> "Member-Created" and "Member-Initialized" as follows:
>
>
> Thanks
>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos