<div dir="ltr">Hi All,<div><br></div><div>I too agree from the development point of view, its easier if we have a single process.</div><div>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?</div><div><br></div><div>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?<br></div><div><br></div><div class="gmail_extra"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Best Regards,</div><div>Anusha</div></div></div></div></div></div>
<br><div class="gmail_quote">On 13 September 2016 at 18:10, Aimee Ukasick <span dir="ltr"><<a href="mailto:aimeeu.opensource@gmail.com" target="_blank">aimeeu.opensource@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I completely agree with a single process deployment for DevStack. I<br>
ran into issues last week with the multiple process configuration<br>
while I trying to pinpoint an error. I was using the pdb command line<br>
debugger to step through Congress and Oslo Messaging, making a call<br>
from the CLI. More than once the Congress API couldn't find the<br>
Process Engine, which I'm sure was caused by uploading code and<br>
stopping/starting services in the wrong order. Deploying single<br>
process Congress to DevStack would have saved me a lot of time.<br>
<span class="HOEnZb"><font color="#888888"><br>
aimee<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Tue, Sep 13, 2016 at 1:42 AM, Masahito MUROI<br>
<<a href="mailto:muroi.masahito@lab.ntt.co.jp">muroi.masahito@lab.ntt.co.jp</a>> wrote:<br>
> Hi Congress folks,<br>
><br>
> I'm in favor of single process for devstack default. It's easy to check<br>
> logs and tests its feature.<br>
><br>
> best regards,<br>
> Masahito<br>
><br>
> On 2016/09/13 11:00, Tim Hinrichs wrote:<br>
>><br>
>> I'd agree with a single process version of Congress for devstack. I'd<br>
>> say we should even do that for Newton.<br>
>><br>
>> Tim<br>
>><br>
>> On Mon, Sep 12, 2016 at 6:34 PM Eric K <<a href="mailto:ekcs.openstack@gmail.com">ekcs.openstack@gmail.com</a><br>
>> <mailto:<a href="mailto:ekcs.openstack@gmail.com">ekcs.openstack@gmail.<wbr>com</a>>> wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> I want to get people’s thoughts regarding what we should set as<br>
>> default devstack deployment config for Ocata.<br>
>> At the moment, it is set to deploy three processes: API, policy, and<br>
>> datasource-drivers.<br>
>><br>
>> I see some potential arguments against that:<br>
>><br>
>> 1. For most users installing via devstack, running Congress in<br>
>> three processes bring little benefit, but rather a more complex<br>
>> and less stable user experience. (Even if our code is perfect,<br>
>> rabbitMQ will timeout every now and then)<br>
>> 2. It’s not clear that we want to officially support separating the<br>
>> API from the policy engine at this point. The supported<br>
>> deployment options for HAHT do not need it.<br>
>><br>
>> The main argument I see for deploying three processes by default is<br>
>> that we may get more bug reports regarding the multi-process<br>
>> deployment that way.<br>
>><br>
>> Our main options for devstack default are:<br>
>> 1. Single-process Congress (with in-mem transport).<br>
>> 2. Two-process Congress API+Policy, datasource-drivers. (other<br>
>> breakdowns between two processes are also possible)<br>
>> 3. Three-process Congress.<br>
>><br>
>> In the end, I think it’s a trade-off: potentially getting more bug<br>
>> reports from users, at the expense of a more complex and less<br>
>> polished user experience that could make a poor first impression.<br>
>> What does everyone think?<br>
>><br>
>> Personally, I slightly favor defaulting to single process Congress<br>
>> because from a typical devstack user’s perspective, there is little<br>
>> reason to run separate processes. In addition, because it is the<br>
>> first time we’re releasing our complete architecture overhaul to the<br>
>> wild, and it may be a good to default to the least complex<br>
>> deployment for the first cycle of the new architecture.<br>
>><br>
>> ______________________________<wbr>______________________________<wbr>______________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:<wbr>unsubscribe</a>><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>><br>
>><br>
>><br>
>> ______________________________<wbr>______________________________<wbr>______________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>><br>
><br>
><br>
> --<br>
> 室井 雅仁(Masahito MUROI)<br>
> Software Innovation Center, NTT<br>
> Tel: +81-422-59-4539<br>
><br>
><br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>