Open Stack

I completely agree with a single process deployment for DevStack. I
ran into issues last week with the multiple process configuration
while I trying to pinpoint an error.  I was using the pdb command line
debugger to step through Congress and Oslo Messaging, making a call
from the CLI. More than once the Congress API couldn't find the
Process Engine, which I'm sure was caused by uploading code and
stopping/starting services in the wrong order.  Deploying single
process Congress to DevStack would have saved me a lot of time.

aimee

On Tue, Sep 13, 2016 at 1:42 AM, Masahito MUROI
<muroi.masahito at lab.ntt.co.jp> wrote:
> 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
>
>
>
>
> __________________________________________________________________________
> 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