Re: [openstack-dev] [Magnum] Add periodic task threading for conductor server

2015-06-16 Thread 大塚元央
Hi, folks.

At the last summit, we decided to support pluggable conductor for multi
backend [1].
So, if we choose #3, new service (instance of periodic task) also should
support plugin.
I think this will be a little complicated to implement a plugin.

[1]: https://etherpad.openstack.org/p/liberty-work-abstract-backend

Thanks
-yuanying


2015年6月15日(月) 11:59 Hongbin Lu hongbin...@huawei.com:

  I think option #3 is the most desired choice in performance’s point of
 view, because magnum is going to support multiple conductors and all
 conductors share the same DB. However, if each conductor runs its own
 thread for periodic task, we will end up to have multiple instances of
 tasks for doing the same job (syncing heat’s state to magnum’s DB). I think
 magnum should have only one instance of periodic task since the replicated
 instance of tasks will stress the computing and networking resources.



 Best regards,

 Hongbin



 *From:* Qiao,Liyong [mailto:liyong.q...@intel.com]
 *Sent:* June-14-15 9:38 PM
 *To:* openstack-dev@lists.openstack.org
 *Cc:* qiaoliy...@gmail.com
 *Subject:* [openstack-dev] [Magnum] Add periodic task threading for
 conductor server



 hi magnum team,

 I am planing to add periodic task for magnum conductor service, it will be
 good
 to sync task status with heat and container service. and I have already
 have a WIP
 patch[1], I'd like to start a discussion on the implement.

 Currently, conductor service is an rpc server, and it has several handlers
 endpoints = [
 docker_conductor.Handler(),
 k8s_conductor.Handler(),
 bay_conductor.Handler(),
 conductor_listener.Handler(),
 ]
 all handler runs in the rpc server.

 1. my patch [1] is to add periodic task functions in each handlers (if it
 requires such tasks)
 and setup these functions when start rpc server, add them to a thread
 group.
 so for example:

 if we have task in bay_conductor.Handler() and docker_conductor.Handler(),
 then adding 2 threads to current service's tg. each thread run it own
 periodic tasks.

 the advantage is we separate each handler's task job to separate thread.
 but hongbin's concern is if it will has some impacts on horizontally
 scalability.

 2. another implement is put all tasks in a thread, this thread will run all
 tasks(for bay,k8s, docker etc), just like sahara does see [2]

 3 last one is start a new service in a separate process to run tasks.( I
 think this
 will be too heavy/wasteful)

 I'd like to get what's your suggestion, thanks in advance.

 [1] https://review.openstack.org/#/c/187090/4
 [2]
 https://github.com/openstack/sahara/blob/master/sahara/service/periodic.py#L118

  --

 BR, Eli(Li Yong)Qiao

  __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Magnum] Add periodic task threading for conductor server

2015-06-14 Thread Hongbin Lu
I think option #3 is the most desired choice in performance’s point of view, 
because magnum is going to support multiple conductors and all conductors share 
the same DB. However, if each conductor runs its own thread for periodic task, 
we will end up to have multiple instances of tasks for doing the same job 
(syncing heat’s state to magnum’s DB). I think magnum should have only one 
instance of periodic task since the replicated instance of tasks will stress 
the computing and networking resources.

Best regards,
Hongbin

From: Qiao,Liyong [mailto:liyong.q...@intel.com]
Sent: June-14-15 9:38 PM
To: openstack-dev@lists.openstack.org
Cc: qiaoliy...@gmail.com
Subject: [openstack-dev] [Magnum] Add periodic task threading for conductor 
server

hi magnum team,

I am planing to add periodic task for magnum conductor service, it will be good
to sync task status with heat and container service. and I have already have a 
WIP
patch[1], I'd like to start a discussion on the implement.

Currently, conductor service is an rpc server, and it has several handlers
endpoints = [
docker_conductor.Handler(),
k8s_conductor.Handler(),
bay_conductor.Handler(),
conductor_listener.Handler(),
]
all handler runs in the rpc server.

1. my patch [1] is to add periodic task functions in each handlers (if it 
requires such tasks)
and setup these functions when start rpc server, add them to a thread group.
so for example:

if we have task in bay_conductor.Handler() and docker_conductor.Handler(),
then adding 2 threads to current service's tg. each thread run it own periodic 
tasks.

the advantage is we separate each handler's task job to separate thread.
but hongbin's concern is if it will has some impacts on horizontally 
scalability.

2. another implement is put all tasks in a thread, this thread will run all
tasks(for bay,k8s, docker etc), just like sahara does see [2]

3 last one is start a new service in a separate process to run tasks.( I think 
this
will be too heavy/wasteful)

I'd like to get what's your suggestion, thanks in advance.

[1] https://review.openstack.org/#/c/187090/4
[2] 
https://github.com/openstack/sahara/blob/master/sahara/service/periodic.py#L118


--

BR, Eli(Li Yong)Qiao
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev