[openstack-dev] [Congress] Default devstack deployment config

Tim Hinrichs tim at styra.com
Tue Sep 13 02:00:29 UTC 2016


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> 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://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/20160913/f060f345/attachment.html>


More information about the OpenStack-dev mailing list