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 <[email protected]
<mailto:[email protected]>> 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:
    [email protected]?subject:unsubscribe
    <http://[email protected]?subject:unsubscribe>
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to