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]> 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://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
