<div dir="ltr">I'd agree with a single process version of Congress for devstack.  I'd say we should even do that for Newton.<div><br></div><div>Tim</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 12, 2016 at 6:34 PM Eric K <<a href="mailto:ekcs.openstack@gmail.com">ekcs.openstack@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><div>Hi all,</div><div><br></div><div>I want to get people’s thoughts regarding what we should set as default devstack deployment config for Ocata.</div><div>At the moment, it is set to deploy three processes: API, policy, and datasource-drivers.</div><div><br></div><div>I see some potential arguments against that:</div><ol><li>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)</li><li>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.</li></ol><div>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.</div><div><br></div><div>Our main options for devstack default are:</div><div>1. Single-process Congress (with in-mem transport).</div><div>2. Two-process Congress API+Policy, datasource-drivers. (other breakdowns between two processes are also possible)</div><div>3. Three-process Congress.</div><div><br></div><div>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?</div><div><br></div><div>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.</div></div>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>