Open Stack

Hi Congress folks,

I'm in favor of single process for devstack default. It's easy to check
logs and tests its feature.

best regards,
Masahito

On 2016/09/13 11:00, Tim Hinrichs wrote:
> I'd agree with a single process version of Congress for devstack.  I'd
> say we should even do that for Newton.
>
> Tim
>
> On Mon, Sep 12, 2016 at 6:34 PM Eric K <ekcs.openstack at gmail.com
> <mailto:ekcs.openstack at gmail.com>> wrote:
>
>     Hi all,
>
>     I want to get people’s thoughts regarding what we should set as
>     default devstack deployment config for Ocata.
>     At the moment, it is set to deploy three processes: API, policy, and
>     datasource-drivers.
>
>     I see some potential arguments against that:
>
>      1. For most users installing via devstack, running Congress in
>         three processes bring little benefit, but rather a more complex
>         and less stable user experience. (Even if our code is perfect,
>         rabbitMQ will timeout every now and then)
>      2. It’s not clear that we want to officially support separating the
>         API from the policy engine at this point. The supported
>         deployment options for HAHT do not need it.
>
>     The main argument I see for deploying three processes by default is
>     that we may get more bug reports regarding the multi-process
>     deployment that way.
>
>     Our main options for devstack default are:
>     1. Single-process Congress (with in-mem transport).
>     2. Two-process Congress API+Policy, datasource-drivers. (other
>     breakdowns between two processes are also possible)
>     3. Three-process Congress.
>
>     In the end, I think it’s a trade-off: potentially getting more bug
>     reports from users, at the expense of a more complex and less
>     polished user experience that could make a poor first impression.
>     What does everyone think?
>
>     Personally, I slightly favor defaulting to single process Congress
>     because from a typical devstack user’s perspective, there is little
>     reason to run separate processes. In addition, because it is the
>     first time we’re releasing our complete architecture overhaul to the
>     wild, and it may be a good to default to the least complex
>     deployment for the first cycle of the new architecture.
>     __________________________________________________________________________
>     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
>
>
>
> __________________________________________________________________________
> 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
>


-- 
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539