[openstack-dev] [Congress] Default devstack deployment config
Masahito MUROI
muroi.masahito at lab.ntt.co.jp
Tue Sep 13 06:42:41 UTC 2016
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://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
>
--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539
More information about the OpenStack-dev
mailing list