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