Open Stack

Thanks, Anusha!

I agree with keeping both options, just using single proc as default.

Added a bug on it: https://bugs.launchpad.net/congress/+bug/1624172

From:  Anusha Ramineni <anusha.iiitm at gmail.com>
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Date:  Monday, September 19, 2016 at 2:05 AM
To:  "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [Congress] Default devstack deployment config

> Hi All,
> 
> I too agree from the development point of view, its easier if we have a single
> process.
> But I was wondering, tempest jobs we run on gate, isn't it better they run
> with 3 processes deployed, to make sure it works across processes too?
> 
> Just a thought, how about we keep both the options, so that developers can
> deploy as single process and on gate we can test it with different processes?
> 
> Best Regards,
> Anusha
> 
> On 13 September 2016 at 18:10, Aimee Ukasick <aimeeu.opensource at gmail.com>
> wrote:
>> 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://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://OpenStack-dev-request@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://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://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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160919/b1bfc731/attachment.html>