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.ii...@gmail.com> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: Monday, September 19, 2016 at 2:05 AM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@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.opensou...@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.masah...@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.openst...@gmail.com >>>> >> <mailto:ekcs.openst...@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-requ...@lists.openstack.org?subject:unsubscribe >>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >>>> >> >>>> <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe >>>> <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe >>> <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev