Open Stack

Hi, Kai,
It is needed to sync stack in periodic tasks even if the bay status is
UPDATE_COMPLETE in my solution.

Thanks

Regards,
Wanghua

On Thu, Aug 13, 2015 at 3:42 PM, Kai Qiang Wu <wkqwu at cn.ibm.com> wrote:

> hi Hua,
>
> My comments in blue below. please check.
>
> Thanks
>
>
> Best Wishes,
>
> --------------------------------------------------------------------------------
> Kai Qiang Wu (吴开强  Kennan）
> IBM China System and Technology Lab, Beijing
>
> E-mail: wkqwu at cn.ibm.com
> Tel: 86-10-82451647
> Address: Building 28(Ring Building), ZhongGuanCun Software Park,
>         No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
> 100193
>
> --------------------------------------------------------------------------------
> Follow your heart. You are miracle!
>
> [image: Inactive hide details for 王华 ---08/13/2015 03:32:53 PM---Hi Kai
> Qiang Wu, I have some comments in line.]王华 ---08/13/2015 03:32:53 PM---Hi
> Kai Qiang Wu, I have some comments in line.
>
> From: 王华 <wanghua.humble at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: 08/13/2015 03:32 PM
> Subject: Re: [openstack-dev] [magnum]problems for horizontal scale
> ------------------------------
>
>
>
> Hi Kai Qiang Wu,
>
> I have some comments in line.
>
> On Thu, Aug 13, 2015 at 1:32 PM, Kai Qiang Wu <*wkqwu at cn.ibm.com*
> <wkqwu at cn.ibm.com>> wrote:
>
>    Hi Hua,
>
>    I have some comments about this:
>
>    A>
>     remove heat poller can be a way, but some of its logic needs to make
>    sure it work and performance not burden.
>    1) for old heat poller it is quick loop, with fixed interval, to make
>    sure stack status update quickly can be reflected in bay status
>    2) for periodic task running, it seems dynamic loop, and period is
>    long, it was added for some stacks creation timeout, 1) loop exit, this 2)
>    loop can help update the stack and also conductor crash issue
>
>
>  It is not necessary to remove heat poller, so we can keep it.
>
>
>
>
>    It would be ideal to put in one place for looping over the stacks, but
>    periodic tasks need to consider if it really just need to loop
>    IN_PROGRESS status stack ? And what's the interval for loop that ?
>    (60s or short, loop performance)
>
>
> It is necessary to loop IN_PROGRESS status stack for conductor crash issue.
>
>
>
>    Does heat have other status transition  path, like delete_failed -->
>    (status reset) --> become OK.  etc.
>
>
>  It needs to be made sure.
>
>
>
>
>
>    B> For remove db operation in bay_update case. I did not understand
>    your suggestion.
>    bay_update include update_stack and poll_and_check(it is in heat
>    poller), if you removed heat poller to periodic task(as you said in your
>    3). It still needs db operations.
>
>
> Race conditions occur in periodic tasks too.  If we save the stack params
> such as node_count in bay_update and race condition occurs, then the
> node_count in db is wrong and the status is UPDATE_COMPLETE. And there is
> no way to correct it.
> If we save stack params in periodic tasks and race condition occurs, the
> node_count in db is still wrong and status is UPDATE_COMPLETE. We can
> correct it in the next periodic task if race condition does not occur. The
> solution I proposed can not promise the data in db is always right.
>
>
>    *  Yes, it can help some, when you talked periodic task,  I checked
>    that,*
>
>    *                filters = [bay_status.CREATE_IN_PROGRESS,*
>
> *                       bay_status.UPDATE_IN_PROGRESS,*
> *                       bay_status.DELETE_IN_PROGRESS]*
> *            bays = objects.Bay.list_all(ctx, filters=filters)*
>  *  If UPDATE_COMPLETE, I did not find it would sync it in this task. Do
> you mean add that status check in this periodic task ?*
>
>
>
> C> For allow admin user to show stacks in other tenant, it seems OK. Does
> other projects try this before? Is it reasonable case for customer ?
>
> Nova allow admin user to show instances in other tenant. Neutron allow
> admin user to show ports in other tenant, nova uses it to sync up network
> info for instance from neutron.
>    *That would be OK, I think*
>
>
> Thanks
>
>
> Best Wishes,
>
> --------------------------------------------------------------------------------
> Kai Qiang Wu (吴开强  Kennan）
> IBM China System and Technology Lab, Beijing
>
> E-mail: *wkqwu at cn.ibm.com* <wkqwu at cn.ibm.com>
> Tel: 86-10-82451647
> Address: Building 28(Ring Building), ZhongGuanCun Software Park,
>         No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
> 100193
>
> --------------------------------------------------------------------------------
> Follow your heart. You are miracle!
>
> [image: Inactive hide details for 王华 ---08/13/2015 11:31:53 AM---any
> comments on this? On Wed, Aug 12, 2015 at 2:50 PM, 王华 <wan]王华
> ---08/13/2015 11:31:53 AM---any comments on this? On Wed, Aug 12, 2015 at
> 2:50 PM, 王华 <*wanghua.humble at gmail.com* <wanghua.humble at gmail.com>> wrote:
>
> From: 王华 <*wanghua.humble at gmail.com* <wanghua.humble at gmail.com>>
> To: *openstack-dev at lists.openstack.org*
> <openstack-dev at lists.openstack.org>
> Date: 08/13/2015 11:31 AM
> Subject: Re: [openstack-dev] [magnum]problems for horizontal scale
>
>    ------------------------------
>
>
>
>
>    any comments on this?
>
>    On Wed, Aug 12, 2015 at 2:50 PM, 王华 <*wanghua.humble at gmail.com*
>    <wanghua.humble at gmail.com>> wrote:
>       Hi All,
>
>       In order to prevent race conditions due to multiple conductors, my
>       solution is as blew:
>       1. remove the db operation in bay_update to prevent race
>       conditions.Stack operation is atomic. Db operation is atomic. But the two
>       operations together are not atomic.So the data in the db may be wrong.
>       2. sync up stack status and stack parameters(now only node_count)
>       from heat by periodic tasks. bay_update can change stack parameters, so we
>       need to sync up them.
>       3. remove heat poller, because we have periodic tasks.
>
>       To sync up stack parameters from heat, we need to show stacks using
>       admin_context. But heat don't allow to show stacks in other tenant. If we
>       want to show stacks in other tenant, we need to store auth context for
>       every bay. That is a problem. Even if we store the auth context, there is a
>       timeout for token. The best way I think is to let heat allow admin user to
>       show stacks in other tenant.
>
>       Do you have a better solution or any improvement for my solution?
>
>       Regards,
>       Wanghua
>
>    __________________________________________________________________________
>    OpenStack Development Mailing List (not for usage questions)
>    Unsubscribe:
>    *OpenStack-dev-request at lists.openstack.org?subject:unsubscribe*
>    <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*
>    <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>    __________________________________________________________________________
>    OpenStack Development Mailing List (not for usage questions)
>    Unsubscribe:
>    *OpenStack-dev-request at lists.openstack.org?subject:unsubscribe*
>    <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*
>    <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150813/e90308d2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150813/e90308d2/attachment.gif>